I worked on a D project 6 years ago in a large company. I loved the language, and enjoyed working with it. I still want to love it. Every time I used it, it felt like a much faster Python, with the power of C++, but without the hassle of C/C++. The whole argument around GC that floated around that time was valid for Games and other low-latency applications, but otherwise was a bit misguided and unfair to D. I felt positioning itself as a C++ alternative didn’t work well (due to GC), while it should have been positioned as Go/Python/etc alternative.
In the end, I gave up on D. Why? The ecosystem. The language features and design didn’t make up for the lack of a strong ecosystem. There were was just a bit too much a lack of libraries (e.g I had to develop my own Fuse wrapper), lack of editor integration, compiler (i had so many dmd crashes…) and library bugs (std.json used to be famously slow), that eventually I gave up and went back to Python and the likes. Nowadays, Rust covers most of what I need, albeit still feels slower to develop than in D.
std.json is still slow, but std_data_json (https://github.com/dlang-community/std_data_json) is excellent. (It’s a stream parser. Can confirm that it rocks- low GC use, high throughput, though we’re using a fork.) And I like to think that critical compiler bugs have gotten a bit under control, though there’s lots remaining.
I basically only use D and have for some time. It is an excellent language with at least some excellent libraries - especially the many ones I did myself :P
It is a nice mix of high and low level - one part of the code might look like Javascript, then a function or two in there look like C or inline assembly. It is a language that can meet you where you are and accompany you wherever you are going.
Every once in a whlie, I take a look again at D for my personal projects. It however always comes down to three problems:
I deal with quite a bit of XML. The state of std.xml has not changed in years: deprecated for poor quality, but no alternative in the standard library.
I want to use a library for something, and it turns out to be a C++ library. Using C++ libraries is not really doable from within D.
No promise for compatibility like Go has and C++ provides with the options to force any given version of the ISO standard. My personal projects tend to grow slowly, and I do not want to risk they will fall to language incompatibilities all of a sudden.
This has inspired me to give it a try. I learned Go last year, it’s a great language but some aspects of it are less than ideal for some use cases I have in mind (large binary size being one), and CGO is horribly slow.
Zig/rust have their own issues. And drew++ (whatever ddevault’s thing is called) is nowhere to be seen yet… so D seems like it might scratch some itches for me.
edit: I guess D is statically linked too, like Go. So I guess there’s less of a benefit for me using it.
I’ve played with Jonathan Blow’s new programming language and that looks very good also. Walter Bright had some good remarks about it at one point.
It has very good compile speed and resulting binary size (higher than zig, but way lower than Go) and it has first class introspection mechanisms that don’t introduce too much of an overhead.
It’s paradigm is not very OOP friendly, but it feels pretty close to Go in ease of writing ease and understandability.
edit: I guess D is statically linked too, like Go. So I guess there’s less of a benefit for me using it.
Well, it depends how you do your build. The default is static D parts for convenience but you can also do dynamic link builds, especially with ldc nowadays, even the runtime as a dll works on Windows now (it was buggy for ages, finally fixed in 2021!)
Once you’re willing to accept a global GC, you open up a much larger space of languages that you might use. .NET languages can be AOT compiled and statically linked with Mono (not sure what the status of this is in the MS implementations, it seems to come and go), Go supports only statically linking.
If you are happy with lower performance then embedded Lua or JavaScript implementations exist and with something like Sol3 it’s easy to expose a few performance-critical bits from C++ and write the application logic in Lua.
I had a look at D a while ago and it seems like it’s a better C++ than C++98 but it wasn’t clear that it was a better C++ than C++11.
I’ve used C++ professionally six years and D six too (have known both for the last 12 years..) and there is no contest, D is much simpler, more effective, and has much lower mental friction. I’m struggling to think about the kind of projects where I’d use C++, perhaps with some exotic hardware.
I think that’s the kind of dichotomy that I have a problem with for D. If I’m in a scenario where I need to be able to escape from the type system and write low-level code, for example writing a memory allocator, a scheduler, or a language runtime, I definitely don’t want a language with a global GC. If I don’t have these constraints, I have the option of languages like TypeScript, F# / C#, Go, Lua, and so on. From what I’ve read about D, I don’t think I’d be more productive in D than in TypeScript or C# (especially factoring in the ecosystems of those languages).
Well if you don’t need native, then of course you have more choices. In my field, it’s all native languages.
If I’m in a scenario where I need to be able to escape from the type system and write low-level code, for example writing a memory allocator, a scheduler, or a language runtime
GC killed it imho. With the improvements to C++, it is really hard to compete. STL, boost, valgrind and extensive use of auto& and const auto& is really great in modern C++ right now.
I worked on a D project 6 years ago in a large company. I loved the language, and enjoyed working with it. I still want to love it. Every time I used it, it felt like a much faster Python, with the power of C++, but without the hassle of C/C++. The whole argument around GC that floated around that time was valid for Games and other low-latency applications, but otherwise was a bit misguided and unfair to D. I felt positioning itself as a C++ alternative didn’t work well (due to GC), while it should have been positioned as Go/Python/etc alternative.
In the end, I gave up on D. Why? The ecosystem. The language features and design didn’t make up for the lack of a strong ecosystem. There were was just a bit too much a lack of libraries (e.g I had to develop my own Fuse wrapper), lack of editor integration, compiler (i had so many dmd crashes…) and library bugs (std.json used to be famously slow), that eventually I gave up and went back to Python and the likes. Nowadays, Rust covers most of what I need, albeit still feels slower to develop than in D.
std.json is still slow, but std_data_json (https://github.com/dlang-community/std_data_json) is excellent. (It’s a stream parser. Can confirm that it rocks- low GC use, high throughput, though we’re using a fork.) And I like to think that critical compiler bugs have gotten a bit under control, though there’s lots remaining.
I think the ecosystem has improved in 6 years.
I basically only use D and have for some time. It is an excellent language with at least some excellent libraries - especially the many ones I did myself :P
It is a nice mix of high and low level - one part of the code might look like Javascript, then a function or two in there look like C or inline assembly. It is a language that can meet you where you are and accompany you wherever you are going.
Every once in a whlie, I take a look again at D for my personal projects. It however always comes down to three problems:
I deal with quite a bit of XML. The state of std.xml has not changed in years: deprecated for poor quality, but no alternative in the standard library.
I want to use a library for something, and it turns out to be a C++ library. Using C++ libraries is not really doable from within D.
No promise for compatibility like Go has and C++ provides with the options to force any given version of the ISO standard. My personal projects tend to grow slowly, and I do not want to risk they will fall to language incompatibilities all of a sudden.
So, I continue using C++.
For XML my recommendation is to use arsd.dom https://p0nce.github.io/d-idioms/#DIID-#1---Parse-XML-file
This has inspired me to give it a try. I learned Go last year, it’s a great language but some aspects of it are less than ideal for some use cases I have in mind (large binary size being one), and CGO is horribly slow.
Zig/rust have their own issues. And drew++ (whatever ddevault’s thing is called) is nowhere to be seen yet… so D seems like it might scratch some itches for me.
edit: I guess D is statically linked too, like Go. So I guess there’s less of a benefit for me using it.
I’ve played with Jonathan Blow’s new programming language and that looks very good also. Walter Bright had some good remarks about it at one point.
It has very good compile speed and resulting binary size (higher than zig, but way lower than Go) and it has first class introspection mechanisms that don’t introduce too much of an overhead.
It’s paradigm is not very OOP friendly, but it feels pretty close to Go in ease of writing ease and understandability.
Well, it depends how you do your build. The default is static D parts for convenience but you can also do dynamic link builds, especially with ldc nowadays, even the runtime as a dll works on Windows now (it was buggy for ages, finally fixed in 2021!)
Both C and Go are not statically linked when compiling with
gccandgccgo, respectively.Go is statically linked by default when compiling with the
gocompiler, but it’s just the default setting.Once you’re willing to accept a global GC, you open up a much larger space of languages that you might use. .NET languages can be AOT compiled and statically linked with Mono (not sure what the status of this is in the MS implementations, it seems to come and go), Go supports only statically linking.
If you are happy with lower performance then embedded Lua or JavaScript implementations exist and with something like Sol3 it’s easy to expose a few performance-critical bits from C++ and write the application logic in Lua.
I had a look at D a while ago and it seems like it’s a better C++ than C++98 but it wasn’t clear that it was a better C++ than C++11.
I’ve used C++ professionally six years and D six too (have known both for the last 12 years..) and there is no contest, D is much simpler, more effective, and has much lower mental friction. I’m struggling to think about the kind of projects where I’d use C++, perhaps with some exotic hardware.
I think that’s the kind of dichotomy that I have a problem with for D. If I’m in a scenario where I need to be able to escape from the type system and write low-level code, for example writing a memory allocator, a scheduler, or a language runtime, I definitely don’t want a language with a global GC. If I don’t have these constraints, I have the option of languages like TypeScript, F# / C#, Go, Lua, and so on. From what I’ve read about D, I don’t think I’d be more productive in D than in TypeScript or C# (especially factoring in the ecosystems of those languages).
Well if you don’t need native, then of course you have more choices. In my field, it’s all native languages.
D can do all of those.
there is also AoT compilation for java
[Comment removed by author]
Both gccgo and the Go compiler from Google supports dynamic linking, and several other build modes:
Is the 2010 “D Programming Language” book from Alexandrescu still largely relevant or is now mostly obsolete?
Consider https://p0nce.github.io/d-idioms/#Which-book-should-I-read?
GC killed it imho. With the improvements to C++, it is really hard to compete. STL, boost, valgrind and extensive use of auto& and const auto& is really great in modern C++ right now.