What i like:
- fast to compile
- C like syntax
- modules
- slices
- metaprogramming
- compile time type introspection
- independent devs
What i don't like:
- maintainers seems to run in circle, they are scared to improve the language therefore they do nothing to improve it
- no vision
- they no longer seem to view D as a system language
- lacks features to enjoy D as a true "betterC" language
D is nice if you like C but hate headers, they unfortunately chased high level languages for too long, and it shows (EH and GC), language became depend on the two too much, making them unable to capture the system programmers
What's sad is even the high-level languages managed to catch up, as you've mentioned with Go, C# NativeAOT and Java's GraalVM
Web Assembly for example, to target it you have to create a object.d and copy paste bunch of Type Info and hooks... it's been like that for years and they didn't bother improving it, how can you be taken seriously.. system side of things got neglected
Then you have the allocator API that still is marked 'experimental', you can't ignore Exception Handling for your errors
Years after years, whenever you try to mention those issues, they always find ways to either ignore or to remind you that you should fix things yourself
Overall D is a nice language, there are much better languages if you want to target system level stuff, and there are much better languages if you want to target high level stuff
The fact that people mention using D instead of Python is just sad.. relegated as a mere alternative to an interpreted language
The language lacks leadership, it needs a reboot, 3rd time is the charm, just like Python right? ;)
- the Dlang plugin for the JetBrain suite (Clion) is quite limited and requires the dmd compiler
- the dmd compiler is not in Debian...
- for dmd you have to manually download .debs and hoping to pick a compatible version
- dub, ldc and gdc are in Debian but then don't mix & match nicely with the external dmd
I know these are all just tiny issues, but they add up...
Something else is the organization of the standard library, which is a bit confusing. Why is std.complex not in std.math? Why std.ascii, std.utf not in std.encoding? curl is in std.net, but socket is toplevel? I don't understand this organization principles.
It's a fun language but very big. What I mean by a big language is that the syntax is very large.
Its very flexible, you can meta-program a lot in it and its easy to fall into that.
What I enjoyed the most with D was how easy it was to get started AND to prototype! Really, D could be treated as a scripting language to quickly test your ideas. And when you're ready, you can scale D into a large sized project.
I mentioned in a previous thread that the BetterC flag is a pretty cool feature that some C / C++ programmers might enjoy.
What did I not enjoy with D you might ask? The error logs or stacktrace could be too verbose and confusing, I was (and still am?) junior to writing low-level code. And last time I used D was like 4 years ago, and I remember back then when I stumbled upon issues or errors I could not figure out the cause of, it was fustrating.
- Much faster than Python (I use it in my day job).
- Not as flexible as Python (not much is) but its so flexible I've yet to be hindered by it.
- GC-based which has let me build complex libraries quickly without being buried in memory management.
- Large standard library with rich documentation.
- It's easy to build libraries and executables (programs are organized in directories).
- Works on macOS, Windows, and Linux.
- Supported by a plugin in IntelliJ IDEA.
- Welcoming, responsive, and active community forums.
- Write low- and high-level code in the same language.
What I don't like:
- The library ecosystem isn't as expansive as you'd find in languages like Python and C#.
- Sometimes feature additions get mired in community discussions.
I started using D after the move to D2 and only heard about the move in HN comments. Day-to-day it has never been an issue.
You can get many of the positives I list in languages like C#, F#, and Go. I think the community in D kept me from going elsewhere.
Edited for formatting.
However, the problem I have with it is lack of LTS (long term support) releases. DUB, its main package repository, has a number of decent libraries available. Sadly, each library are likely build/released on the latest version at that time. So each package can be built on different versions of the compiler. New compiler releases have been known to break something, so it is off putting to create a project in D that might, say, include a number of DUB packages.
^^ Please note that LTS has been addressed due to complaint about (another) breaking code changes from a user/poster.
This is why I have only used D for 'small projects' on my server that requires no DUB dependencies. I have tried component programming and other things but, in the end, just cannot get a handle that what I am doing really is "better" than just writing it in C. This is where I think DasBetterC peaks my interest. Of course, if you use D with no GC (which you can disable) - a lot of the features D has is no longer supported. This, to me, throws out DUB.. as it can be difficult to reason if this package is doing functional, or OOP, or whatever combination it is doing... and sometimes you might need to care about memory.
To backtrack, I have always been on the lookout for the "perfect" language... one that can be used for 97% of problems.. daemons, web, gui, etc. Personally, I just want a "Better C" language that covers these areas. It comes down to these:-
- DasBetterC - Rust - Zig - Odin
At time of writing, Odin is one I am keeping an eye on. It is not trying to cram "this cool feature" for the sake of doing so. They have set the grounds on what they will and wont do with the language. Ie No classes, not GC, no "Exception handling" etc.
I do like having the control, and yet Odin still seems enjoyable to code in - from my experience so far.- It's both fast for prototyping and also scales well for large applications.
- Compiles very fast with DMD and supports many platforms with LDC and GDC.
- CTFE (compile-time function execution) is a big win.
- standard library has enough of the common things (json, sql, csv, curl, sockets, etc.) that I need for my domain. Other stuff I can usually find a package or C library to read in if needed.
- most of the defaults seem right to me in the language versus C++ (variable initialization, struct as value type by default, explicit casting, module system, thread-local data, etc.)
Ecosystem does need a boost but I think that's actively developing, so code-d plugin for VSCode is a good place for most to start (I prefer VIM). Ecosystem seems to be slowly and steadily growing otherwise.
I can post links to more video tutorials if useful (disclaimer: I made them :) ).
But for an IOT prototype where the executable size and performance were very important we benchmarked D also along with Go and C#.NET Core.
I made the same prototype in Go, C#, Java(GraalVM Native Compile) and D-lang. The results were surprisingly positive for D-lang.
Best Peformance -> D-lang, next Go and then Java(GraalVM), C#.NET Core.
Executable Size -> D-lang:500kb, Go: 2.5 MB, C# : 11MB, Java(GraalVM):8MB.
Our major concern with D-lang was lack of dependable(tested) standard libraries.
The recordings are on YouTube with time stamps to each talk.
https://www.youtube.com/live/uzuKqiFVNZM?si=p4GEDK4xanGcw5rJ
These days, for system programming Rust is gaining much attention. And if you don't need such low-level control and can happily live in GC-land, probably Go/Nim suits you better.
Well, I'm not a C++ coder (mostly code in Java/Kotlin). Not sure how I'm going to use D these days...
D is what Go would have been, if its designers cared for programming language history.
Still use it occasionally on hobby projects.
What I don't like is the lack of direction, changing the next big thing that might bring people in, without fully stabilising the previous attempts.
Thus making D lose its edge over other alternatives.
but then i still consider java, c#, go, rust, haskell pointess badly designed and built clusterfucks, so what do i know?
The mess that were the competing stdlibs and the transition to D2 made me lose interest. I've looked at it again from time to time and it just feels too... big. It does too much.
I can get what I wanted from the D1 days with C# AoT now (it also has too many features but they have more obvious use cases and it has a much larger ecosystem).
I really don't see much use in a C++ but saner and with a GC. I'm sure someone has that use case, but not me particularly. And for the "statically typed high-level language with a GC" Java, C# and Go can do it with massively larger ecosystems backing them up.
There might be a future in the BetterC D subset or if they find a way to go after the Rust market with a more C++-like language but even for that I'm a lot more bullish on Herb Sutter's cppfront.
I honestly don't know what they can do to get a breakthrough. Walter Bright is appropriately named and there's a lot to like in D, it's just lacking a direction and an audience IMO.