3 ms·

D never took off IMO because you can't abstract away a GC. The moment your callees rely on a GC, you have no choice but to have one in your program. The idea th

D never took off IMO because you can't abstract away a GC. The moment your callees rely on a GC, you have no choice but to have one in your program. The idea that you can avoid it in practice just because the language doesn't mandate it is therefore an illusion, and so it's not surprising at all that it isn't replacing C++.

layer8 4y ago
I mean, the same is true for C++. If some C++ library you use employs GC, you can’t abstract that away either. The actual difference is how frequent such libraries are in the respective ecosystem.
- dataflow 4y ago
  I basically said as much https://news.ycombinator.com/item?id=34850130 https://news.ycombinator.com/item?id=34850130 Though, I'm not sure you could even have a precise GC for C++ even if you wanted to, given the way most C++ is written.
- masklinn 4y ago
  > The actual difference is how frequent such libraries are in the respective ecosystem. That’s a difference without a distinction: people will use the defaults unless they can’t. So in C++ libraries will avoid GCs unless their work basically requires it, whereas in D they’ll require it unless the author is constrained to a nogc requirement.
suby 4y ago
This is the logic I personally used in deciding not to use D.
- dataflow 4y ago
  Yeah, I'm pretty sure it's the reason many C++ folks reject it. It's kind of ironic that having the "wrong" useful feature can hurt you, but that seems to be what's happening here. I feel like they might actually have a shot at solving it by literally dropping GC support, but it's hard to say at this point. I don't know if the standard library still has anything that needs a GC, but making sure that's not the case might be a good first step if they're ever interested in going in this direction.
  - funnymony 4y ago
    Conveniences like closures depend on gc
    - dataflow 4y ago
      C++ has had closures without a GC for over a decade now.
      - pjmlp 4y ago
        As syntactic sugar for how C++ functors used to be implemented, and they also bring their own set of issues when interoperating with co-routines.
        dataflow 4y ago
        If anything that's a statement about coroutines, not closures. And even then, not every coroutine has problems. I don't see a logical implication from that to a GC requirement.
    - Kukumber 4y ago
      That's not true https://dlang.org/spec/function.html#function-pointers-delegates https://dlang.org/spec/function.html#function-pointers-deleg...
- Simon_O_Rourke 4y ago
  > This is the logic I personally used in deciding not to use D. Good call - I was unfortunate enough that I had to use it professionally for a few years. As comic book guy in the Simpsons would say "Worst language ever!".
  - keldaris 4y ago
    Can you elaborate on your experience? There's a lot of negative D opinions from people who've barely used it and, for obvious self-selection reasons, a lot of positive ones from long term true believers. It would be interesting to see a negative experience from someone who used it extensively nonetheless.
  - christophilus 4y ago
    I’m interested in hearing more. Also, I’m curious what language you use as a your daily driver?
gavinray 4y ago
I'm not sure I follow Is this about D code that interops with C/C++? You have "extern (C++)" and @nogc for that
- dataflow 4y ago
  No, it's about pure D code. Some (many) people just don't want a GC in their program and that's why they use C++. If they switch to D, they'll have to put up with a GC if any of their dependencies needs one, and the probability of that being the case is... high.
  - mhh__ 4y ago
    @nogc eliminates that risk. The GC also doesn't run if you don't call it so mitigating it's downsides while keeping the good aspects isn't all that hard.
    - dataflow 4y ago
      You disable GC for the whole program? And what do you do when one of your dependencies relies on it? Just live with a memory leak? Bear in mind you're simply not going to convince anti-GC folks that you can have the "good aspects" of a GC without the bad ones, and they're the folks you're trying to market to. To many C++ programmers the only good GC is one that is absent. You can tell them they're wrong all you want, but regardless of who's right, it's always been a losing battle.
      - mhh__ 4y ago
        It won't compile. You can also make it so it will compile but won't collect unless you ask it to explicitly. We don't exclusively market to C++ developers. D replaced PHP and Java for quite a few D users.
        dataflow 4y ago
        It won't compile, and... how is that a solution? You've basically told some users they can't use your language in that case. That's problem solved? If you see PHP and Java replacement as taking off, that's awesome. I was addressing those who want to see it replace C++.

layer8 4y ago

I mean, the same is true for C++. If some C++ library you use employs GC, you can’t abstract that away either. The actual difference is how frequent such libraries are in the respective ecosystem.

dataflow 4y ago
I basically said as much https://news.ycombinator.com/item?id=34850130 https://news.ycombinator.com/item?id=34850130 Though, I'm not sure you could even have a precise GC for C++ even if you wanted to, given the way most C++ is written.
masklinn 4y ago
> The actual difference is how frequent such libraries are in the respective ecosystem. That’s a difference without a distinction: people will use the defaults unless they can’t. So in C++ libraries will avoid GCs unless their work basically requires it, whereas in D they’ll require it unless the author is constrained to a nogc requirement.

suby 4y ago

This is the logic I personally used in deciding not to use D.

dataflow 4y ago
Yeah, I'm pretty sure it's the reason many C++ folks reject it. It's kind of ironic that having the "wrong" useful feature can hurt you, but that seems to be what's happening here. I feel like they might actually have a shot at solving it by literally dropping GC support, but it's hard to say at this point. I don't know if the standard library still has anything that needs a GC, but making sure that's not the case might be a good first step if they're ever interested in going in this direction.
- funnymony 4y ago
  Conveniences like closures depend on gc
  - dataflow 4y ago
    C++ has had closures without a GC for over a decade now.
    - pjmlp 4y ago
      As syntactic sugar for how C++ functors used to be implemented, and they also bring their own set of issues when interoperating with co-routines.
      - dataflow 4y ago
        If anything that's a statement about coroutines, not closures. And even then, not every coroutine has problems. I don't see a logical implication from that to a GC requirement.
  - Kukumber 4y ago
    That's not true https://dlang.org/spec/function.html#function-pointers-delegates https://dlang.org/spec/function.html#function-pointers-deleg...
Simon_O_Rourke 4y ago
> This is the logic I personally used in deciding not to use D. Good call - I was unfortunate enough that I had to use it professionally for a few years. As comic book guy in the Simpsons would say "Worst language ever!".
- keldaris 4y ago
  Can you elaborate on your experience? There's a lot of negative D opinions from people who've barely used it and, for obvious self-selection reasons, a lot of positive ones from long term true believers. It would be interesting to see a negative experience from someone who used it extensively nonetheless.
- christophilus 4y ago
  I’m interested in hearing more. Also, I’m curious what language you use as a your daily driver?

gavinray 4y ago

I'm not sure I follow Is this about D code that interops with C/C++? You have "extern (C++)" and @nogc for that

dataflow 4y ago
No, it's about pure D code. Some (many) people just don't want a GC in their program and that's why they use C++. If they switch to D, they'll have to put up with a GC if any of their dependencies needs one, and the probability of that being the case is... high.
- mhh__ 4y ago
  @nogc eliminates that risk. The GC also doesn't run if you don't call it so mitigating it's downsides while keeping the good aspects isn't all that hard.
  - dataflow 4y ago
    You disable GC for the whole program? And what do you do when one of your dependencies relies on it? Just live with a memory leak? Bear in mind you're simply not going to convince anti-GC folks that you can have the "good aspects" of a GC without the bad ones, and they're the folks you're trying to market to. To many C++ programmers the only good GC is one that is absent. You can tell them they're wrong all you want, but regardless of who's right, it's always been a losing battle.
    - mhh__ 4y ago
      It won't compile. You can also make it so it will compile but won't collect unless you ask it to explicitly. We don't exclusively market to C++ developers. D replaced PHP and Java for quite a few D users.
      - dataflow 4y ago
        It won't compile, and... how is that a solution? You've basically told some users they can't use your language in that case. That's problem solved? If you see PHP and Java replacement as taking off, that's awesome. I was addressing those who want to see it replace C++.