Ask HN: Who is using the D language and likes/doesn't like it? Why? | Hacker News Reader

Ask HN: Who is using the D language and likes/doesn't like it? Why?

89 pointsfuzztester72 comments

dlang.org

I haven't used it in awhile. I was quite positive on it during the D1 days when it was basically C#/Java but AoT. (I don't think Go even existed at that time).

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.

This matches my experience and perception. It's a language with no real core identity - every time some new language feature becomes trendy D tries to find a way to shoehorn it in. When everyone in C++-land got a little too excited about template metaprogramming and Boost, suddenly D became a language fixated on template metaprogramming. When everyone on HN got excited about Haskell, suddenly D went hard on functional programming and enforcing immutability. When Rust started picking up steam, suddenly D began rallying around BetterC, nogc, memory-safety, ownership and borrowing.

Speaking personally: I tend to work best in languages which imply a particular mental schema for expression and structuring. Not that Python is always a poster-child for this, but as the Zen of Python says, "there should be one and preferably only one obvious way to do it". Ironically, by being limited a good language can get out of your way by allowing you to focus on your problem rather than exploring a massive solution space of how best to express it. For me, anyway.

D isn't a language like that; it seemingly operates under the assumption that any feature must be good - if D has all the features of C++ AND D has all the features of Rust AND D has all the features of Java AND D has all the features of Haskell AND...why use all those other languages when you could just use D? It's guaranteed to have what you need! And there's certainly room in this world for languages like that - and there's plenty of them - but they're not for me.

D isn't wrong in turning itself into everything including a kitchen sink, because that seems to be the fate of every language that ends up popular.

Python is a poster-child for this, getting more and more features and complexity as it grows, while it used to be very simple in the early days.

The problem is that becoming a kitchen sink language is a result of becoming popular, and not the path there. With the exception of languages with an ecosystem tied to them (like C/C#/Swift/JavaScript, even PHP with Apache), nearly every language that got popular had a strong message behind it and focus.

Even C++ started as C+Classes with zero-cost abstractions. Java was write once run everywhere. Rust was memory safety without GC. Haskell was functional programming taken to the limit.

D is just a pile of features at the moment, and that's just not enough. I have the same issue with Nim to be fair to Walter.

I love python, it's my favorite language by far, but the changes I see coming through the pipeline make me feel hesitant. The language is getting more and more complicated. Having written a lot of c++ (mostly c++14/17) professionally I have suffered the consequences of what a couple decades of brilliant, well meaning people can create.

Same here. Back when D had little competition, D1/D2/tango/phobos/dmd/gccd fragmentation decimated an already small ecosystem.

D sees optional GC as the best of both worlds, but IMHO this is only another axis on which the language is fragmented, and casts doubt whether the language and ecosystem is fully committed to supporting absolutely-no-GC users.

Golang has probably taken over D's GC niche, and Zig is competing with -betterC.

Both of which will be winning, because regardless of our opinions on them, I always criticized Go's lackluster type system, and Zig being a Modula-2 reborn with a C inspired syntax and metaprogramming, both of the communities do one thing remarkly great.

They know where they want to go, and stand by their decisions no matter what.

I really don't see much use in a C++ but saner and with a GC.

Isn't that what Nim kind of is?

Yes, and I have the same opinion of Nim.

I use D for a game

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? ;)

> C# NativeAOT and Java's GraalVM

I’m not sure these are really a competition or a threat to anything. Go is eating C# and Java’s lunch precisely because these 2 solutions are no where near good enough in the real world.

Go has its niche and C# and Java have theirs. I don't know any emulator written in Go but C# has Ryujinx. Same with some impressive desktop apps like Icons8 Lunacy. C# AoT works fine for them.

Choco one of the best constraint solvers around now compiles with GraalVM and exposes a C-API callable from Python. Try that in Go.

They overlap in a small niche that is server side services/microservices. Pluse I’m not sure emulator startup time is a relevant metric. Jitted C# or Java are faster than AOT in most scenarios other than startup time and initial memory consumption.

Startup time is definitely relevant for any kind of user-facing application. I'm sure the JIT versions are actually faster since both languages (specially Java) have features that benefit greatly from it.

But if I'm loading a constraint solver into my Python app I don't want it to drag a massive JVM around and take 3 seconds to load up. Same with an emulator, most emulators load up in milliseconds.

> Jitted C# or Java are faster than AOT in most scenarios other than startup time and initial memory consumption.

Why are is so many people saying this, as it doesn't seem to be true. At lest from what I have seen so far. I know that theoretically jitted can be faster, in in practice it's almost never. From C# benchmarks I have seen, in case jitted is faster than AOT, it's only by minuscule few percent. But when AOT is faster it is often a lot faster. And I am not talking about startup time.

Startup time is very important

Some apps get poorly reviewed due to slow startup time

Also 3sec on your dev machine = 10sec on regular machines

Don't be like Microsoft, don't pretend 9 seconds is fast startup time :)

https://www.youtube.com/watch?v=CT7nnXej2K4

"10MinuteMail shared how they used GraalVM and Spring Boot 3 to reduce their startup time from ~30 s down to about 3 ms, and memory usage from 6.6 GB down to 1 GB, with the same throughput and CPU utilization."

https://medium.com/graalvm/graalvm-for-jdk-21-is-here-ee0117...

I agree with you, Go is ahead, but as I said, they are catching up quite fast

Outside Kubernetes and DevOps, hardly anyone cares Go exists.

Why do so many people say that dlang compilation is fast? Does it not use llvm? If it supports features like generics, then I assumed compile times must be slow just like rust or cpp. Why is dlang different?

D has its own backend (or it used to at least) which is lightning fast. No comparison what so ever to C++ or Rust, much much faster. And that's with D having much more powerful metaprogramming than either.

Zig is similar in that regard, if you don't use the LLVM backend it is stupidly fast despite the insane amount of metaprogramming it supports.

D is one of the very few languages that maintain its own backend, they have full control, and it is very fast, that's why I still use D, despite its problems

I did an unscientific comparison more than 1 decade ago... yep D was pretty fast (at least compared to g++). Of course FPC was faster.

BTW, there are several D compilers:

- DMD (the de-facto compiler written by Walter). Previously written in C++, now is self-hosted. It has it's own code codegen.

- LDC (using LLVM)

- GDC (using GCC)

I guess Walter still hangs around here to comment on this, I hope.

He tends to not comment on postings that are directly about D. You can make what you will of that.

He does, at times.

HN Algolia search should find some.

Where do you get the notion that D's leadership no longer see it as a systems language? Some of D's proposed features have been blocked to protect its use as a systems language e.g. @safe by default.

Also are NativeAOT and GraalVM replacements for a language like D when they limit access to their respective languages' library ecosystems?

I think comparison to Python is a plus. Python is loved because of its flexibility and ease of use. One of D's strengths is the degree of flexibility and ease of use it maintains while offering much greater performance than Python.

I do agree that language improvements can be slow but I don't believe it is because maintainers are afraid. I believe it is because of the degree to which D involves its wider community in improvements.

Edited for grammar.

By using the language, when you step away from phobos/gc/eh to embrace esoteric targets (wasm), you start to notice how the language is just not made for that kind of things, wherewas the highlevel stuff are nailed

Or rather, it doesn't provide enough to justify the downsides

I wanted to play around with Dlang a couple of times. But the few times I've tried, it was quite a hassle to setup a dev environment to start with my preferred tooling. Some concrete points:

- 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.

I think your concerns are correct. I realize expecting everything to fit into a favorite IDE is a bit much, but anecdotally it helps me a lot in a new or rarely used language. Assists, muscle memory finding things, autocomplete, etc. really add up in potential benefits to both productivity and correctness of what you write. This is even better when libraries are standardized.

I know I lean on Pycharm hard these days, as I don't use python as much as I used to. It really helps to guide me along and spend less time getting caught in details. Everything, including the interpreter, just works.

I've previously used it a couple of times, I've used it to build webapps (using vibe.d) and plain binaries.

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.

Pretty much the same experience. It is an awesome language, probably still my favourite. What i did not like is the inconsistent apis and missing basic protocol implementations in the standard library.

Someone should write an heavily opinionated standard library like go has, with basic http,mail, dns etc support. Then D would really be a superpower

Yeah, sometimes when I've felt like Phobos is lacking (https://dlang.org/phobos) I turned to the community made packages (https://code.dlang.org)

But things might have changed a lot since I used it last time.

The problem with such a small community, is that users from community made packages are expected to fix them when they no longer work with latest compilers.

I use D and like it. For me its positives are:

- 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.

I have tried to keep up with Dlang, and even wrote some projects on my home server in the last number of years. I do like Dlang and see potential behind it.

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.

I like it, use it, and teach it.

- 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 :) ).

Please do, I am interested.

Here is my playlist: https://youtube.com/playlist?list=PLvv0ScY6vfd9Fso-3cB4CGnSl...

Some more upcoming videos will include some tools for D's ecosystem.

I can also recommend Ali's book here as a reference to the language: http://ddili.org/ders/d.en/

Thanks.

I never used D-lang in any production application.

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.

Question: does D-lang use LLVM under the hood?

D has 3 main compiler implementations. One, LDC, is based on LLVM: https://github.com/ldc-developers/ldc

GDC is based on GCC: https://github.com/D-Programming-GDC/gdc

DMD is stand-alone: https://github.com/dlang/dmd

AOT size footprint of C# is now smaller than Go (as of .NET 8). Also performance is much better, just write code in a Rust-ish way (struct generics).

If each language is used correctly, Go should come last on the benchmarks.

Struct generic C# is where it’s at

C# AOT is down to 1 - 2 MB? Are any tricks required? Is it compressed? Does it have runtime dependencies? How is start up time?

Last time I tried C# AOT (not sure what version, but it was in March of this year) I ended up with a 67 MB (static) executable.

Edit: the docs mention a web app at 8.5 MB (static) on Linux: https://learn.microsoft.com/en-us/aspnet/core/release-notes/...

Go's 2MB is just a hello world executable. Same for C# (it's about 1.4ish MB now).

Once you start referencing heavy dependencies like networking stack or bits of async runtime, the binary will get larger. 8.5 MB while very optimistic (it will be usually larger for back-end applications, which is different to parent comment's IoT scenario), it is actually not far off what you'd get with Rust's Tokio + Axum + Serde + Reqwest and auxiliary crates to replicate the functionality that base ASP.NET Core offers.

Good point, I was thinking of Hello World.

Regardless, < 10 MB for a nontrivial program is a huge improvement. Maybe I need to revisit C#…

It doesn’t really answer your question, but DConf was a fews ago and there are a lot of interesting talks there: https://dconf.org/2023/index.html

The recordings are on YouTube with time stamps to each talk.

https://www.youtube.com/live/uzuKqiFVNZM?si=p4GEDK4xanGcw5rJ

If someone is intrested in D's metaprograming this is a good overview https://www.youtube.com/watch?v=0lo-FOeWecA

D accompanies you from prototype to production (with graduate enforceble constraints) so I find it very flexible and practical, and the highlights of my programming career tend to be in D. If you want native with a joyful creative process, D is a good match.

I absolutely love D’s contracts with pre and postconditions. These I can simulate in other languages however. The invariant is where D really shines imo. Also the fact that you can overwrite the r value constructor, move constructor and cooy constructor are great ideas and the static function support is also good!

I learnt D (D1 to be precise) out of curiosity in... 2005 or 2006. At that time, there's only 1 compiler: DMD (no GDC/LDC yet), and there was the tango/phobos fragmentation. I think my intention at that time was looking for a "better C++" alternative.

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...

I am a big fan of systems languages with automatic memory management, and love how expressive D happens to be.

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.

When I went looking to ditch java after learning about ptrs and cpu caches, D won out over C/C++ for being multi paradiam and having a GC (wasnt in the mood to learn manual memory mangment yet). It has kept its primarlly used language status however due to its meta programing capablities(mixins std.traits, staticif staticforeach, CTFE..). The only other systems langague I'm aware of that can beat D in this regard is JAI. So if anyone knows of any others I'd be intrested to hear.

I've tried it every so often over the years because I love what it was trying to do. Tragically, I think it might have been really successful if it just had optional GC/runtime from the beginning so it could stick to displacing C++ instead of competing with all the other fancy managed languages. Ultimately, C++ got a lot of ameliorating features to make it feel more like D and D had a lot of half-baked additions that made it feel more like C++.

I love D; unfortunately, since I use Qt, I'm mainly limited to C++ for a lot of personal projects. With that being said, I strive to use D where I can, and my most recent project is making use of some neat D features (like C++ interop).

I use it at work. It's pretty nice! If you write in a functional style, it's very high-level while still retaining that C-like comfort of familiarity. And the metaprogramming is top-tier.

cant make a fully static build:

https://github.com/ldc-developers/ldc/issues/4499

The link you added directly contradicts you. It says static builds on windows require the Visual++ tools. They aren't that hard to install. This one is on you.

If I remember correctly, for certain things rust also needs the visual C++ tools if you're on windows. You might think that installing an additional tool is a mild inconvenience, but "cant make a fully static build" is just wrong.

the difference is Rust has a GNU option for Windows, D does not.

Any serious system programming will use the OS vendor tooling.

nope. I am not using visual C++ until they distribute a zip file with the tools, or come up with an installer that doesn't result in 10 GB being dumped on my system. no thanks.

It turns out compiled binary libraries take space, go figure.

not 10 GB though. especially when similar options can do it in less than 200 MB:

https://github.com/mstorsjo/llvm-mingw/releases

I would be eager to hear actual data in further replies, rather than guesses.

It isn't similar, does not offer support for all kinds of Windows development.

right, I dont want that. If I am using Python with a C plugin, or just compiling a command line C/C++ too, I dont want or need the full Visual Studio experience. and even with the Visual C++ tools or whatever its called, you still end up installing gigabytes of nonsense.

It is not nonsence for doing systems programming in Windows.

Apple and Google development SDKs, or any commercial OS, have similar sizes for the SDKs.

Doing Python with a C plugin, or just compiling a command line C/C++ isn't really systems programming.

> Doing Python with a C plugin, or just compiling a command line C/C++ isn't really systems programming.

I care about a minimal set of tools in order to compile C/C++ programs. thats offered by:

https://github.com/mstorsjo/llvm-mingw/releases

and also MSYS2, and even the Zig C compiler. all less than 200 MB. meanwhile Visual Studio installing about 10 GB worth. If Microsoft can offer a similar experience then I am interested.

Yeah, but that isn't systems programming on Windows.

what I want is to have tools to compile C/C++ programs. until microsoft offers a minimal package like this, visual C++ is generally a poor choice for any compilation of C/C++ programs, because of the bloated nature of the current offerings.

Thanks to all who replied, guys. Interesting points made.

i used it years ago. it solved nothing for me despite being cool. i've not seen any interesting developments in that direction.

but then i still consider java, c#, go, rust, haskell pointess badly designed and built clusterfucks, so what do i know?

Is there a language you like? If so, which and why?

Reply on news.ycombinator.com