Even though it doesn't have the same theoretical rigour as Rust or Erlang (Go is a totally different beast), D is a really thoughtful, modern language which I - personally, of course - feel very productive in. Although I'm really behind the times on Rust, metaprogramming feels like a joke in other (Non ML-esque) languages compared to the facilities available in D
Walter Bright, the man who designed most of the language along with Andrei Alexandrescu, are both C++ heavyweights and it shows. Template syntax using template!type instead of template<type> is a great - surface level - example of this attention to detail: Easier on the eyes and orders of magnitude easier for the compiler
Yes. D metaprogramming is so fucking good that it's easy to do well.
It's really obvious, and even at it's worst it's no worse than C++ (Except much easier to debug due to D's much less fundamentalist type system).
I hate languages that deliberately take features away from the developer: This is why - although I respect the philosophy - I would never choose to use Go, for example.
> I hate languages that deliberately take features away from the developer: This is why - although I respect the philosophy - I would never choose to use Go, for example.
The don't really take the features away, they move the problem to a proper templating/code generation language. These are language neutral so you don't have to learn a different one for each language, they are often more powerful too. IME the code they generate is a lot easier to deal with than templated code.
I was really referring to the error messages, because you can write C++ style templates (e.g. SFINAE) in D but no one does because D was designed properly so it has proper traits etc. C++ style template messages are uncommon but possible, however D is much much easier to debug because the type system is working with you and basically available in the language - in the sense that you can use traits and reflection to work out what went wrong (as opposed to
stdin.
byLineCopy.array.sort!((a, b) => a >b).each!writeln;
This example is everyday code in D, but basically unthinkable in C++ (Possible but try getting it that short without writing your own library). It is also telling that the aesthetic style of the above code (UFCS) is a feature D has had for years but was rejected for inclusion into C++ despite BS backing it.
I have a hard time finding value in this. Mastering a language take years, so the tool better has some killer feature to make it worth the investment.
I can see why Go, if you want an easy to compiled yet middle level language with good concurrency.
I can see why erlang, if you want crazy concurrency, and reliability.
I can see why rust, if you want c/c++ power, with a modern touch and a safety net.
But what is the selling point in D ? Why should I choose D over those for a particular task, and take the time and energy on this on not something else ?
D only "competes" with rust in the list you gave, is what I was really trying to say. If you are working on something high-level enough to use erlang then I think you should. (I love erlang)
> D vs rust - D is 100% more familiar to anyone with C or C++ background
I had the opposite experience. I have a long history of C and C++ development, yet I found D pretty impenetrable (my team inherited some D code to maintain). Rust, however, was easy to use out of the box.
Java-style OO is a model where one can and should take the good, dispose of the bad, and improve on what falls in between. Go types and interfaces do a good job of this IMO--like Java classes, Go types can include a defined data structure and methods, but unlike Java classes, there's no inheritance. Like Java interfaces, Go interfaces let you type-check against multiple types that have the same outwards-facing behavior, but unlike Java interfaces, you don't have to actually declare that a type fulfills an interface as you define it. These are all pretty obvious improvements IMO.
If you so choose to D can have a relatively clean library implementation. The type inference isn't bidirectional (Or at least it pales in comparison to HM) so it wouldn't be as good as ML-like FP.
Pattern matching is a feature of pure functional code rather than a requirement (As useful as it is, every time I touch haskell for fun I always miss the mathematical approach to coding when I then write in C-land).
Enforced purity is a feature, however. That's what I was referring to. However, ..., there is no pure-IO so it would be like Haskell before Monadic IO was figured out (I assume).
That's hardly a selling point, a Java syntaxe is only nice if you have beeing doing Java all your life. Comming from a lot of other languages, it's not appealing.
What would you choose D for ? What kind of task, project ? And why D and not the competition, given the cost of learning it ?
Walter Bright, the man who designed most of the language along with Andrei Alexandrescu, are both C++ heavyweights and it shows. Template syntax using template!type instead of template<type> is a great - surface level - example of this attention to detail: Easier on the eyes and orders of magnitude easier for the compiler