.NET vs D: overall experiences

Having spent a fair bit of time with both D and .NET, I’d like to blather about how they stack up against each other.

Community

D has a community. It’s small and centralized on the newsgroups. You can rather easily see what’s going on with the language just by following digitalmars.D.announce.

.NET has a community. It’s large and spread out. A lot more is happening, and it takes more work to figure out what’s going on. On .NET’s side, it’s easier to find information on specific topics. There are more blog articles and stackoverflow questions about it.

Small advantage to .NET here.

Library base

Isn’t it annoying when you have to roll your own solution for things?

A few weeks ago, I needed to create epub documents. I checked about half a dozen libraries available in Nuget. None of them could produce valid epubs! Calibre wouldn’t open them, or FBReader wouldn’t open them, or they’d crash instead of giving me documents. So I had to roll my own.

Problem: the epub specification says that you must include a mimetype file, that it must be the first element in the archive, not compressed, and with no additional fields. I had to go through four different zip archive libraries to find one that almost worked. (It added metadata fields to the file.)

D? I still had to write my own epub output, but the standard library’s zip implementation actually did what I needed.

The general theme I’ve found is, what I can find in D is higher quality on average, and it’s easier to predict the quality in advance. Coverage is better in C#, but there are surprising gaps.

Performance

D has superior performance, hands down. It’s varied in my experience between a factor of four and a factor of fifty. And that’s with ahead-of-time compilation, which does improve performance by a decent margin in C#.

D just offers better tools for avoiding allocations, and that’s huge. (Turns out? Allocating 5MB of memory total is a lot more efficient than allocating 4GB, most of which is duplicate data.) Plus the default backend has a good thirty years of improvements by one of the best minds from the C++ compiler community.

Tooling

.NET wins at IDEs. Resharper is nearly impossible to beat.

If you’re working from the command line, .NET is almost impossible not to beat. And D does a lot better than that. Want to write a script in D? Just put #!/usr/bin/env rdmd at the top of the file and mark it executable. Want to link in a library? The compiler passes flags to the linker. Have a project that depends on other D projects? Dub is miles ahead of dotnet for describing your project. Even though its format isn’t as cleanly documented as I might wish, it’s still easier for me to find documentation on it than on the dotnet-core project format.

dfmt is an awesome tool, and I don’t have an equivalent for .NET. (I use Mono. MonoDevelop is a bit reluctant to reformat text.)

The advantage here is mostly in D’s favor.

Metaprogramming

C# metaprogramming is possible, and it does almost everything most people personally need it to. Taking place at runtime is on rare occasions an advantage.

D metaprogramming is easy, and it does almost everything you can think of.

For instance, someone created a scientific units library in D. You can get compile-time checking to ensure that you aren’t accidentally confusing a length for a speed. You could do that in C# by repeating a lot of code, or with less repeated code using classes…except you’d have separate types for Length, Time, Velocity, Acceleration, etc. Did you remember to add a Density type? Do you have a type that can represent the ideal gas constant? What do you even call it? The units-d library can represent it, despite the author not having designed a compatible type.

On the other hand, you can more easily enumerate types in a program and do useful things with them in .NET.

This puts D in the lead by a small margin.