12 ms·

> the virality of the GC makes it a non-starter for its primary audience (C/C++ developers) No. If you were to say you need the GC to use all features of the l

> the virality of the GC makes it a non-starter for its primary audience (C/C++ developers) No. If you were to say you need the GC to use all features of the language and standard library, of course, the GC does important things, but to claim a C developer wouldn't be comfortable with it because of the GC is nonsense. Just don't allocate with the GC and use the same mechanisms you'd use with C (and then build on top of them with things like @safe, reference counting, and unique pointers).

dataflow 1y ago
>> the virality of the GC > Just don't allocate with the GC "virality" is not just a word you can ignore.
- bachmeier 1y ago
  I don't understand. If you're a C programmer and want to avoid the GC, there's nothing to be viral.
  - dataflow 1y ago
    > If you're a C programmer and want to avoid the GC, there's nothing to be viral. What you're suggesting is the moral equivalent of "it's easy to avoid diseases, just avoid contact with those infected", or "it's easy to avoid allergens, just avoid foods you're allergic to", or "it's easy to avoid contamination, just set up a cleanroom", or "it's easy to write deterministic code, just avoid randomness", etc. Yes, there are things that are easy to achieve in the vacuum of outer space, but that's not where most people are interested in living.
    - brabel 1y ago
      Completely agree after trying it. Anything that may throw an Exception requires GC. There goes 80% of D code you could use. The rest becomes inaccessible for other, similar reasons quite often. Try writing D with @nogc and it takes 10 minutes to understand that. They want to make the situation better but there’s just not enough people to tackle the huge amount of work that requires (I.e. changing most of the stdlib)
      - dataflow 1y ago
        > Try writing D with @nogc and it takes 10 minutes to understand that. Thank you. Yes, exactly. The problems aren't even subtle; it's impossible to miss them if you actually try. I don't recall even finding a reasonable way to concatenate or split strings on the heap and return them without a GC, let alone anything more complicated. It boggles my mind that people repeat the talking point that it's somehow practical to program with @nogc when the most basic operations are so painful. Nobody is going to drool at the idea of spending days/weeks of their lives reinventing nonstandard second-class-citizen counterparts to basic types like strings just to use a new language. > They want to make the situation better but there’s just not enough people to tackle the huge amount of work that requires (I.e. changing most of the stdlib) I don't agree that it's lack of manpower that's the problem -- at least, not yet. I think it's primarily the unwillingness to even admit this is a problem (an existential problem for the language, I think) and confront it instead of denying the reality, and secondarily the inertia and ecosystem around the existing language outside the standard library. It's not like the problem is subtle (like you said, a few minutes of coding makes it painfully obvious) or novel. The language has been out there for over a decade and a half, and people have been asking for no-GC version nearly that long. Yet, at least to the extent I've had the energy to follow it, the response has always been the canned you-can-totally-program-D-without-a-GC denials you see repeated for the millionth time here, or (at best) silence. If this sentiment has changed and I'm unaware of it, that's already significant progress. Maybe the unwillingness to confront reality is due to the lack of manpower and how daunting the problem looks; I'm not sure. But it seems as bright as daylight that D is not going to be successful without solving this problem.
        WalterBright 1y ago
        I use: https://github.com/dlang/dmd/blob/master/compiler/src/dmd/backend/barray.d https://github.com/dlang/dmd/blob/master/compiler/src/dmd/ba... It's pretty minimalist on purpose. I don't much care for kitchen sink types. The BetterC is the no-gc version. Use the -betterC switch on the compiler. Or, if you want a string result, import core.stdc.stdlib; string concat(string s1, string s2) { const length = s1.length + s2.length; char* p = cast(char*)malloc(length); assert(p); p[0 .. s1.length] = s1; p[s1.length .. s1.length + s2.length] = s2; return cast(string)p[0 .. length]; } I tend to not use this sort of function because it doesn't manage its own memory. I use barray instead because it manages its memory using RAII. D provides enormous flexibility in managing memory. Or, you can just leave it to the gc to do it for you.
    - bmacho 1y ago
      According to them[0], D as better C is indeed just C with less footguns and some additional optional features like RAII (that one can use or not) or more comptime assumptions (again, that one can use or ignore). I don't think what hinders their adoption is their direction, everything they say they accomplished/plan to accomplish is ideal IMO. [0] : https://dlang.org/spec/betterc.html#retained https://dlang.org/spec/betterc.html#retained
      - dataflow 1y ago
        > D as better C is indeed just C with less footguns and some additional features like RAII (that one can use or not) or more comptime assumptions (again, that one can use, or ignore) Having strictly more features (if we even assume that, which I don't think is accurate) does not imply better. Javascript is just JSON with more features too. Is it a mystery that people don't ship Javascript code everywhere instead of JSON?
        WalterBright 1y ago
        What the "more features" do is replace the clumsy/inadequate/risky methods used in a less powerful language like C. For example, you don't need to use the C preprocessor to do metaprogramming. D offers a world class metaprogramming capability. Another example is D enables nested functions. Yes, there are ways in C to do the equivalent, but they are clumsy and indirect.
unclad5968 1y ago
If I'm just coding C except a new syntax, why wouldn't I just stick with C?
- dataflow 1y ago
  It's not just new syntax, you get other nice features too.

dataflow 1y ago

>> the virality of the GC > Just don't allocate with the GC "virality" is not just a word you can ignore.

bachmeier 1y ago
I don't understand. If you're a C programmer and want to avoid the GC, there's nothing to be viral.
- dataflow 1y ago
  > If you're a C programmer and want to avoid the GC, there's nothing to be viral. What you're suggesting is the moral equivalent of "it's easy to avoid diseases, just avoid contact with those infected", or "it's easy to avoid allergens, just avoid foods you're allergic to", or "it's easy to avoid contamination, just set up a cleanroom", or "it's easy to write deterministic code, just avoid randomness", etc. Yes, there are things that are easy to achieve in the vacuum of outer space, but that's not where most people are interested in living.
  - brabel 1y ago
    Completely agree after trying it. Anything that may throw an Exception requires GC. There goes 80% of D code you could use. The rest becomes inaccessible for other, similar reasons quite often. Try writing D with @nogc and it takes 10 minutes to understand that. They want to make the situation better but there’s just not enough people to tackle the huge amount of work that requires (I.e. changing most of the stdlib)
    - dataflow 1y ago
      > Try writing D with @nogc and it takes 10 minutes to understand that. Thank you. Yes, exactly. The problems aren't even subtle; it's impossible to miss them if you actually try. I don't recall even finding a reasonable way to concatenate or split strings on the heap and return them without a GC, let alone anything more complicated. It boggles my mind that people repeat the talking point that it's somehow practical to program with @nogc when the most basic operations are so painful. Nobody is going to drool at the idea of spending days/weeks of their lives reinventing nonstandard second-class-citizen counterparts to basic types like strings just to use a new language. > They want to make the situation better but there’s just not enough people to tackle the huge amount of work that requires (I.e. changing most of the stdlib) I don't agree that it's lack of manpower that's the problem -- at least, not yet. I think it's primarily the unwillingness to even admit this is a problem (an existential problem for the language, I think) and confront it instead of denying the reality, and secondarily the inertia and ecosystem around the existing language outside the standard library. It's not like the problem is subtle (like you said, a few minutes of coding makes it painfully obvious) or novel. The language has been out there for over a decade and a half, and people have been asking for no-GC version nearly that long. Yet, at least to the extent I've had the energy to follow it, the response has always been the canned you-can-totally-program-D-without-a-GC denials you see repeated for the millionth time here, or (at best) silence. If this sentiment has changed and I'm unaware of it, that's already significant progress. Maybe the unwillingness to confront reality is due to the lack of manpower and how daunting the problem looks; I'm not sure. But it seems as bright as daylight that D is not going to be successful without solving this problem.
      - WalterBright 1y ago
        I use: https://github.com/dlang/dmd/blob/master/compiler/src/dmd/backend/barray.d https://github.com/dlang/dmd/blob/master/compiler/src/dmd/ba... It's pretty minimalist on purpose. I don't much care for kitchen sink types. The BetterC is the no-gc version. Use the -betterC switch on the compiler. Or, if you want a string result, import core.stdc.stdlib; string concat(string s1, string s2) { const length = s1.length + s2.length; char* p = cast(char*)malloc(length); assert(p); p[0 .. s1.length] = s1; p[s1.length .. s1.length + s2.length] = s2; return cast(string)p[0 .. length]; } I tend to not use this sort of function because it doesn't manage its own memory. I use barray instead because it manages its memory using RAII. D provides enormous flexibility in managing memory. Or, you can just leave it to the gc to do it for you.
  - bmacho 1y ago
    According to them[0], D as better C is indeed just C with less footguns and some additional optional features like RAII (that one can use or not) or more comptime assumptions (again, that one can use or ignore). I don't think what hinders their adoption is their direction, everything they say they accomplished/plan to accomplish is ideal IMO. [0] : https://dlang.org/spec/betterc.html#retained https://dlang.org/spec/betterc.html#retained
    - dataflow 1y ago
      > D as better C is indeed just C with less footguns and some additional features like RAII (that one can use or not) or more comptime assumptions (again, that one can use, or ignore) Having strictly more features (if we even assume that, which I don't think is accurate) does not imply better. Javascript is just JSON with more features too. Is it a mystery that people don't ship Javascript code everywhere instead of JSON?
      - WalterBright 1y ago
        What the "more features" do is replace the clumsy/inadequate/risky methods used in a less powerful language like C. For example, you don't need to use the C preprocessor to do metaprogramming. D offers a world class metaprogramming capability. Another example is D enables nested functions. Yes, there are ways in C to do the equivalent, but they are clumsy and indirect.

unclad5968 1y ago

If I'm just coding C except a new syntax, why wouldn't I just stick with C?

dataflow 1y ago
It's not just new syntax, you get other nice features too.