6 ms·

I keep saying this and having the exact same argument with everyone every single time I mention it (and I'm sure here we'll go again), but D's fundamental probl

I keep saying this and having the exact same argument with everyone every single time I mention it (and I'm sure here we'll go again), but D's fundamental problem was its GC. Its mere presence colors the code that uses it, and once your dependencies use the GC, you have no recourse. It's impossible to abstract away. I fail to see how such a language could ever substitute for C++.

badsectoracula 3y ago
According to the followup a week later[0] it seems OpenD is doubling down on GC: > One of the guiding principles of this fork is to embrace the GC as a successful design rather than to shun and avoid it. [...] I have harshly criticized @nogc in the past as putting a disproportionate burden on library authors while being the wrong answer to what can be a perfectly fair question. [0] https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.html https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.h...
- petre 3y ago
  The GC works fine. Why waste energy to duplicate the functionality that requires it? Programmers who don't want the GC are already using C++ or Rust instead. The GC is one of those tools that makes programming in D productive. The lack of libraries and modern tooling is the part that ruins it. That's why you get software written in Go and Java instead of D. I'd love to use it for embedded work instead of C and C++, even in the current state. Embeded meaning 32bit MCUs running some kind of RTOS, not ARM SBCs powerful enough to run Linux. If not D, then maybe Zig. For this it needs to be able to link against and build upon existing C/C++ libraries.
  - badsectoracula 3y ago
    > Programmers who don't want the GC are already using C++ Sure, but this was in a response about D substituting C++.
  - hashmash 3y ago
    Unfortunately, the D garbage collector is a simple design that doesn't offer the performance and scalability of a modern collector. Someone switching over to D from Java/C#/Go might be surprised to see GC pauses reminiscent of 1998. Hopefully the maintainers of the D fork will address this.
jimbob45 3y ago
I don’t disagree. Add in the GC and you’re competing with C#, which is an unwinnable battle considering the resources of MS. Dump the GC and you’re competing in a much more winnable battle with C++, Rust, and that’s it (when the decision was made anyway).
- pjmlp 3y ago
  And Java, with GC implementations being able to manage TB sized heaps in pauseless server implementations, or tiny heaps with real time GC in embedded bare metal deployments. D's GC problem is being a very old approach on how to design one.
CJefferson 3y ago
I think the worst thing was making GC optional. I’ve never seen any language end up with good optional GC.
WalterBright 3y ago
GC makes CTFE (Compile Time Function Execution) simple and very easy. It's quite normal for projects to use GC for CTFE and other management methods for runtime.
pjmlp 3y ago
Easy, see the use of Oberon, Java, .NET in bare metal IoT deployments. PTC, Aicas, microEJ, Astrobe, Meadow,... The problem isn't having a GC, is its poor implementation.
- masklinn 3y ago
  > The problem isn't having a GC, is its poor implementation. OTOH Java and .Net exist and have large investment (D is younger than C#), so for people who are fine with GC, there are already plenty of "C++ alternatives". What's left is people who can't or won't use a GC, and for them a GC'd language can not be an alternative.
  - TylerE 3y ago
    There is a substantial… feel… difference in using a well gced language that isn’t tied to a monolithic runtime. A big part of that is having zero perceptible startup overhead, since it isn’t parsing a class path or trying to load a bunch of dlls or anything beyond what your code explicitly doe + a much more minimalistic than you might expect GC runtime. Often only 20-30kb of machine code. While it hasn’t really taken off yet, I’ll point to nim, specifically with its very recently stable arc GC, as a very compelling local (at least) maximum in this space.
Shorel 3y ago
I think this is the case of a few noisy people putting too much importance in a single feature, and ruining the whole for everyone else. If that argument were solid, Golang would not be more successful than Dlang, but reality is, Golang numbers are just so much bigger.
- dataflow 3y ago
  > If that argument were solid, Golang would not be more successful than Dlang I never said anything about being "successful". I said something about substituting for C++. Go isn't any closer to that than D.
- lolinder 3y ago
  A garbage collector may be right for Golang but wrong for D.

badsectoracula 3y ago

According to the followup a week later[0] it seems OpenD is doubling down on GC: > One of the guiding principles of this fork is to embrace the GC as a successful design rather than to shun and avoid it. [...] I have harshly criticized @nogc in the past as putting a disproportionate burden on library authors while being the wrong answer to what can be a perfectly fair question. [0] https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.html https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.h...

petre 3y ago
The GC works fine. Why waste energy to duplicate the functionality that requires it? Programmers who don't want the GC are already using C++ or Rust instead. The GC is one of those tools that makes programming in D productive. The lack of libraries and modern tooling is the part that ruins it. That's why you get software written in Go and Java instead of D. I'd love to use it for embedded work instead of C and C++, even in the current state. Embeded meaning 32bit MCUs running some kind of RTOS, not ARM SBCs powerful enough to run Linux. If not D, then maybe Zig. For this it needs to be able to link against and build upon existing C/C++ libraries.
- badsectoracula 3y ago
  > Programmers who don't want the GC are already using C++ Sure, but this was in a response about D substituting C++.
- hashmash 3y ago
  Unfortunately, the D garbage collector is a simple design that doesn't offer the performance and scalability of a modern collector. Someone switching over to D from Java/C#/Go might be surprised to see GC pauses reminiscent of 1998. Hopefully the maintainers of the D fork will address this.

jimbob45 3y ago

I don’t disagree. Add in the GC and you’re competing with C#, which is an unwinnable battle considering the resources of MS. Dump the GC and you’re competing in a much more winnable battle with C++, Rust, and that’s it (when the decision was made anyway).

pjmlp 3y ago
And Java, with GC implementations being able to manage TB sized heaps in pauseless server implementations, or tiny heaps with real time GC in embedded bare metal deployments. D's GC problem is being a very old approach on how to design one.

CJefferson 3y ago

I think the worst thing was making GC optional. I’ve never seen any language end up with good optional GC.

WalterBright 3y ago

GC makes CTFE (Compile Time Function Execution) simple and very easy. It's quite normal for projects to use GC for CTFE and other management methods for runtime.

pjmlp 3y ago

Easy, see the use of Oberon, Java, .NET in bare metal IoT deployments. PTC, Aicas, microEJ, Astrobe, Meadow,... The problem isn't having a GC, is its poor implementation.

masklinn 3y ago
> The problem isn't having a GC, is its poor implementation. OTOH Java and .Net exist and have large investment (D is younger than C#), so for people who are fine with GC, there are already plenty of "C++ alternatives". What's left is people who can't or won't use a GC, and for them a GC'd language can not be an alternative.
- TylerE 3y ago
  There is a substantial… feel… difference in using a well gced language that isn’t tied to a monolithic runtime. A big part of that is having zero perceptible startup overhead, since it isn’t parsing a class path or trying to load a bunch of dlls or anything beyond what your code explicitly doe + a much more minimalistic than you might expect GC runtime. Often only 20-30kb of machine code. While it hasn’t really taken off yet, I’ll point to nim, specifically with its very recently stable arc GC, as a very compelling local (at least) maximum in this space.

Shorel 3y ago

I think this is the case of a few noisy people putting too much importance in a single feature, and ruining the whole for everyone else. If that argument were solid, Golang would not be more successful than Dlang, but reality is, Golang numbers are just so much bigger.

dataflow 3y ago
> If that argument were solid, Golang would not be more successful than Dlang I never said anything about being "successful". I said something about substituting for C++. Go isn't any closer to that than D.
lolinder 3y ago
A garbage collector may be right for Golang but wrong for D.