I've only toyed with D a bit. IMHO, if you come from a typical OO programming language background (which to me includes C++, Java, Python...), the majority of D will immediately feel familiar, and to a great extent, obvious.
The syntax is familiar and the ideas are familiar. You don't have to learn anything new (not immediately anyway) like you do in Rust (where you basically need to learn EVERYTHING new).
Where this idyllic scenario starts falling apart with when you start actually using it for anything half-serious. Some of the bits feel extremely unintuitive and the documentation is difficult to navigate. There are few examples and the tutorial is a bit spartan. For example, I needed a deque-like container (double-ended queue), but it took me ages to figure out that a) the language actually has one and b) how to use the bloody thing.
There is also a bit of schizophrenia going on, with the "new" ideas and the "old" ideas clashing in some places. For example, they claim that you can run D without a GC (the new), but apparently a good chunk of the stdlib requires the GC (the old), so you're stuck.
I find this all to be unfortunate because D, to me, feels like it could be a better, saner C++.
> There is also a bit of schizophrenia going on, with the "new" ideas and the "old" ideas clashing in some places. For example, they claim that you can run D without a GC (the new), but apparently a good chunk of the stdlib requires the GC (the old), so you're stuck.
AFAIK this is somewhat intentional; they don't want to make any hard compatibility breaks, so there's a long deprecation period for any 'old' idea. There's also a lack of manpower to renovate libraries; e.g. there's no good xml library.
Regarding GC, it's IMO not a huge problem. The GC is really not a problem for most applications, and for those where it is, you can simply avoid GC allocations in inner loops (GC only runs when you allocate from it).
> they claim that you can run D without a GC (the new), but apparently a good chunk of the stdlib requires the GC (the old), so you're stuck.
The intent isn't to turn off the GC completely (though GC-averse folks assume that it is). The `@nogc` function attribute is intended to be applied where you need it. Then you can guarantee that in that function's call stack, no language features that require the GC will be used.
The standard library has been retrofitted to eliminate use of the GC where it isn't needed and provide alternatives where possible (such as a function that takes a buffer as an argument alongside one that allocates). There may still be places where it can be trimmed down even more, but it will never be fully `@nogc` compatible.
D is meant to be used with the GC, but provides the means to avoid allocations, turn collections on/off (`GC.disable/enable`) and command line options for profiling GC usage and affecting its behavior. Anyone who wants to turn off the GC completely is going beyond the primary intended use case and is of course going to run into bumps with the standard library. Much of it is still usable, though.
I feel the same way too. It's fairly easy to translate Python into D, and you get all of that compile-time goodness to go with it (static type checking and compile-time function execution). And it's pretty fast! I bet we could optimise this D wc to match GNU's wc without too many crazy tricks.
This is a bit perplexing. Libraries don't need to be installed, you simply put them in a directory, add a path to it in the command to the compiler, and list the library on the command to the compiler.
Just as you would for C and C++.
Other languages may need libraries to be installed, but not D.
My only issue is that it's far more complicated than Java and for a language that fills that same niche it's hard for me to justify putting my resources into learning it even though I do like a lot of the features.
It's certainly possible to write more complicated code in a language like D than in Java. I personally find the verbosity of Java combined with jamming everything into a single approach makes Java hard to read.
Java is indeed a simpler language, much simpler. Unfortunately, my experience with Java is it is too simple - I had to write way too much boilerplate over and over.
D is designed to be able to do 100% of everything C++ can do. "Alias this" is intended to replace C++'s implicit conversion through multiple inheritance pattern and its "function that returns a value with implicit conversion" pattern. "Mixin templates" are a way to do CRTP.
well, java isn't really complicated. it's just verbose. but my understanding is that d has many of the features of c and modern cpp. that alone makes it more complicated than java...
The syntax is familiar and the ideas are familiar. You don't have to learn anything new (not immediately anyway) like you do in Rust (where you basically need to learn EVERYTHING new).
Where this idyllic scenario starts falling apart with when you start actually using it for anything half-serious. Some of the bits feel extremely unintuitive and the documentation is difficult to navigate. There are few examples and the tutorial is a bit spartan. For example, I needed a deque-like container (double-ended queue), but it took me ages to figure out that a) the language actually has one and b) how to use the bloody thing.
There is also a bit of schizophrenia going on, with the "new" ideas and the "old" ideas clashing in some places. For example, they claim that you can run D without a GC (the new), but apparently a good chunk of the stdlib requires the GC (the old), so you're stuck.
I find this all to be unfortunate because D, to me, feels like it could be a better, saner C++.