Hacker News Reader

Comment by gavinray | Hacker News Reader

D is a bittersweet topic for me.

From a philosophical/language-design standpoint, it ticks so many boxes. It had the potential to be wildly popular, had a few things gone differently.

If the language tooling and library ecosystem were on par with the titans of today, like Rust/Go, it really would be a powerhouse language.

View on HN

Isn't D supported by the GNU compiler collection? I personally would prefer this type of tooling over what Rust and Go do (I can't even get their compilers to run on my old platform anymore; not to mention all this dependencies on remote resources typical Rust/Go projects seem to have: which seems to be enforced by the ecosystem?)

It is

It is, however keeping LDC and GCC up to date is a volunteer effort with not enough people, so they are always a bit behind dmd.

Still much better than GCCGO, kind of useless for anything beyond Go 1.18, no one is updating it any longer, and may as well join gcj.

Having written real code in D, I can say that the slight discrepancy between dmd, LDC, and gdc isn't a roadblock in practice.

Depends how creative you happen to be with some features.

For regular common code that is indeed not an issue.

LDC isn't regularly behind DMD lately. The issue lately has been more the release process with respect to DMD. People issues impacting that.

Which was my point, volunteer work without enough people.

It is supported. However on Windows GDC does not work. LDC based on LLVM needs Visual Studio but I maybe wrong since there are clang/llvm distributions based on mingw64. Other than that DMD works fine, a bit slower than the other compilers, but a charm to use.

Ldc like dmd ships lld and mingw import libraries and has for a few years now.

They both work out of the box without MSVC installed.

It's only ImportC feature that requires MSVC. The work required to get clang working in its place hasn't happened yet.

Yeah, the foundations of the language are incredible. It's just everything else around it that brings it down (and is unfortunately very hard to motivate people to solve).

D definitely missed a critical period, but I love it all the same.

So, I also write Go and I don't get the part about tooling. I don't need formatters or linters as I'm adult enough to know how to format my code (in fact I dislike tools doing it for me). D also has dub, which is fine, as far as package managers go. The ecosystem is the only issue and Go does arguably have a lot of very cool libraries for virtually anything, but outside of webdev, I can't see myself using them. This is why D works a lot better for projects where I don't need all those dependencies and would do better without them.

I freely admit to not being a Go or Rust expert, but from what I can tell using C from D is even easier than in either of these languages. The C++ interop is also decently usable.

IMO, the bigger issue is language tooling.

D really does work as a "Better C" C compiler. For example, D's Import C supports this:

    void abc() { def(1.0); }
    void def(double) { }

I.e. forward references "just work". (Forward references don't work in C++, either.)

Being able to use ImportC to "just include" all of LAPACKE was a high point for me with this! Thanks for adding this feature, it rocks.

... Now, get started on ImportC++!!! (Only joking... kind of. ;-) )

If it makes you feel better I have some projects that I'm working on in order to improve the tooling. Would you mind listing out all of the things you think are missing, so I can work on those once I get the other ones done?

Reply on news.ycombinator.com