Live data from Hacker News

D Programming Language

dlang.org

121–130 of 278 posts

Re: D Programming Language

#121

IMHO D just missed the mark with the GC in core. It was released in a time where a replacement for C++ was sorely needed, and it tried to position itself as that (obvious from the name). But by including the GC/runtime it went into a category with C# and Java which are much better options if you're fine with shipping a runtime and GC. Eventually Go showed up to crowd out this space even further. Meanwhile in the C/C+…

I'd rather say that the GC is the superpower of the language. It allows you to quickly prototype without focusing too much on performance, but it also allows you to come back to the exact same piece of code and rewrite it using malloc at any time. C# or Java don't have this, nor can they compile C code and seamlessly interoperate with it — but in D, this is effortless. Furthermore, if you dig deeper, you'll find that…

> C# or Java don't have this, nor can they compile C code and seamlessly interoperate with it — but in D, this is effortless.

C# C interop is pretty smooth, Java is a different story. The fact that C# is becoming the GC language in game dev is proving my point.

>Furthermore, if you dig deeper, you'll find that D offers far greater control over its garbage collector than any other high-level language, to the point that you can eagerly free chunks of allocated memory, minimizing or eliminating garbage collector stops where it matters.

Yes, and the no-gc stuff was just attempts to backpedal on the wrong initial decision to fit into the use-cases they should have targeted from the start in my opinion.

Look D was an OK language but it had no corporate backing and there was no case where it was "the only good solution". If it was an actual C++ modernization attempt that stayed C compatible it would have seen much better adoption.

Re: D Programming Language

#122
post #107

IMHO D just missed the mark with the GC in core. It was released in a time where a replacement for C++ was sorely needed, and it tried to position itself as that (obvious from the name). But by including the GC/runtime it went into a category with C# and Java which are much better options if you're fine with shipping a runtime and GC. Eventually Go showed up to crowd out this space even further. Meanwhile in the C/C+…

FIl-C, the new memory-safe C/C++ compiler actually achieved that through introducing a GC, with that in mind I'd say D was kind of a misunderstood prodigy in retrospect.

There's two classes of programs - stuff written in C for historic reasons that could have been written in higher level language but rewrite is too expensive - fill c. Stuff where you need low level - Rust/C++/Zig

Re: D Programming Language

#123

Earlier quoted context omitted.

Well, I would say it's more like glasses - you can't convince those who don't wear them, and you don't need to convince those who need them either.

What problem is D solving ?

One good case for it that I see is a viable basis for cross-platform desktop apps. Today, cross-platform desktop GUI apps are either just a snapshot of the website contained inside Electron, or a C/C++ code base with manual memory management. D can serve as a nice middle ground in that space.

Re: D Programming Language

#124

Earlier quoted context omitted.

One feature of D that i really wish other languages would adopt (not sure about Rust but i also think it lacks it, though if it has it to a similar extent as D it might be the reason i check it again more seriously) is the metaprogramming and compile-time code evaluation features it has (IIRC you can use most of the language during compile time as it runs in a bytecode VM), down to even having functions that generate…

Arguably, most of the metaprogramming in D is done with templates and it comes with all the flaws of templates in C++. The error messages are long and it's hard to decipher what exactly went wrong (static asserts help a lot for this, when they actually exist). IDE support is non-existent after a certain point because IDE can't reason about code that doesn't exist yet. And code gets less self-documenting because it's…

It is quite ridiculous to place C++ metaprogramming and D's. For one in D it's the same language and one can choose whether to execute compile time constant parts at compile time or run time. In C++ it's a completely different language that was bolted on. C++ did adopt compile time constant expressions from D though.

Re: D Programming Language

#125

Earlier quoted context omitted.

I'd rather say that the GC is the superpower of the language. It allows you to quickly prototype without focusing too much on performance, but it also allows you to come back to the exact same piece of code and rewrite it using malloc at any time. C# or Java don't have this, nor can they compile C code and seamlessly interoperate with it — but in D, this is effortless. Furthermore, if you dig deeper, you'll find that…

> C# or Java don't have this, nor can they compile C code and seamlessly interoperate with it — but in D, this is effortless. C# C interop is pretty smooth, Java is a different story. The fact that C# is becoming the GC language in game dev is proving my point. >Furthermore, if you dig deeper, you'll find that D offers far greater control over its garbage collector than any other high-level language, to the point tha…

> C# C interop is pretty smooth

True, but you still need to either generate or manually write the bindings. In D, you just import the C headers directly without depending on the bindings' maintainers.

> If it was an actual C++ modernization attempt that stayed C compatible it would have seen much better

Any D compiler is literally also a C compiler. I sincerely don't know how can one be more C compatible than that.

> Yes, and the no-gc stuff was just attempts to backpedal on the wrong initial decision

I think that it was more of an attempt to appease folks who won't use GC even with a gun to their head.

Re: D Programming Language

#126
Years ago I got interested in D. It's a great language, but at the time its garbage collector was leaky. There weren't any D entries on the Benchmarks Game back then, so I ported most of the programs to D and optimized them as best I could as a newcomer. Performance wise, D was in the C/Rust/C++ range and in many cases it even beat Rust and C++. I tried to get the community involved to help the language gain wider adoption, but nothing really happened. I think everything has its moment, and D's moment has passed. They didn't make the most of the window when D could have gone mainstream.

Re: D Programming Language

#127

Earlier quoted context omitted.

I'd rather say that the GC is the superpower of the language. It allows you to quickly prototype without focusing too much on performance, but it also allows you to come back to the exact same piece of code and rewrite it using malloc at any time. C# or Java don't have this, nor can they compile C code and seamlessly interoperate with it — but in D, this is effortless. Furthermore, if you dig deeper, you'll find that…

> C# or Java don't have this, nor can they compile C code and seamlessly interoperate with it — but in D, this is effortless. C# C interop is pretty smooth, Java is a different story. The fact that C# is becoming the GC language in game dev is proving my point. >Furthermore, if you dig deeper, you'll find that D offers far greater control over its garbage collector than any other high-level language, to the point tha…

> The fact that C# is becoming the GC language in game dev is proving my point.

Respectfully, it doesn't prove your point. Unity is a commercial product that employed C# because they could sell it easily, not because it's the best language for game dev.

Godot supports C# because Microsoft sponsored the maintainers precisely on that condition.

Re: D Programming Language

#128

Earlier quoted context omitted.

D and Rust are on the opposite sides at dealing with memory safety. Rust ensures safety by constantly making you think about memory with its highly sophisticated compile-time checks. D, on the other hand, offers you to either employ a GC and forget about (almost) all memory-safety concerns or a block scoped opt-out with cowboy-style manual memory management. D retains object-oriented programming but also allows funct…

> block scoped opt-out with cowboy-style manual memory management Is this a Walter Bright alt? I've seen him use the cowboy programmer term a few times on the forum before.

It makes sense for someone who has read about D to pick up on Bright phrasing.

Re: D Programming Language

#129

IMHO D just missed the mark with the GC in core. It was released in a time where a replacement for C++ was sorely needed, and it tried to position itself as that (obvious from the name). But by including the GC/runtime it went into a category with C# and Java which are much better options if you're fine with shipping a runtime and GC. Eventually Go showed up to crowd out this space even further. Meanwhile in the C/C+…

My (likely unfair) impression of D is that it feels a bit rudderless: It is trying to be too many things to too many people, and as a consequence it doesn't really stand out compared to the languages that commit to a paradigm.

Do you want GC? Great! Do not want GC? Well, you can turn it off, and lose access to most things. Do you want a borrow-checker? Great, D does that as well, though less wholeheartedly than Rust. Do you want a safer C/memory safety? There's the SafeD mode. And probably more that I forget.

I wonder if all these different (often incompatible) ways of using D ends up fragmenting the D ecosystem, and in turn make it that much harder for it to gain critical mass

Re: D Programming Language

#130

Earlier quoted context omitted.

> C# or Java don't have this, nor can they compile C code and seamlessly interoperate with it — but in D, this is effortless. C# C interop is pretty smooth, Java is a different story. The fact that C# is becoming the GC language in game dev is proving my point. >Furthermore, if you dig deeper, you'll find that D offers far greater control over its garbage collector than any other high-level language, to the point tha…

> C# C interop is pretty smooth True, but you still need to either generate or manually write the bindings. In D, you just import the C headers directly without depending on the bindings' maintainers. > If it was an actual C++ modernization attempt that stayed C compatible it would have seen much better Any D compiler is literally also a C compiler. I sincerely don't know how can one be more C compatible than that. >…

I'm not saying D didn't have nice features - but if D/C#/Java are valid options I'm never picking D - language benefits cannot outweigh the ecosystem/support behind those two. Go picked a niche with backend plumbing and got Google backing to push it through.

Meanwhile look at how popular Zig is getting 2 decades later. Why is that not D ? D also has comp-time and had it for over a decade I think ? Zig proves there's a need that D was in the perfect spot to fill if it did not make the GC decision - and we could have had 2 decades of software written in D instead of C++ :)

Post reply on HN