7 ms·

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 yo

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 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.

rafaelmn 7mo ago
> 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.
- arcadia_leak 7mo ago
  > 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.
  - rafaelmn 7mo ago
    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++ :)
    - arcadia_leak 7mo ago
      > D/C#/Java are valid options I'm never picking D This is perfectly fair. > D was in the perfect spot to fill if it did not make the GC decision I just find it hard to believe that the GC is the one big wart that pushed everyone away from the language. To me, the GC combined with the full power of a systems language are the killer features that made me stick to D. The language is not perfect and has bad parts too, but I really don't see the GC as one of them.
      - zem 7mo ago
        go had a similar early trajectory where c++ programmers rejected it due to the gc. it gained traction among python/ruby/javascript programmers who appreciated the speed boost and being able to ship a single static binary.
      - Cloudef 7mo ago
        Its not the GC, its that D has no direction. Its kitchen sink of features and the optionality just fragments the ecosystem (betterC, gc) etc, making reusing code hard.
        thezipcreator 7mo ago
        this is the main issue I think with D, yeah. regarding kitchen-sink-ness it's at least nowhere near as bad as C++, but that bar is basically below the ground anyway so it's not much to write home about.
- arcadia_leak 7mo ago
  > 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.
- xigoi 7mo ago
  > The fact that C# is becoming the GC language in game dev is proving my point. Popularity is not proof of anything. C# is popular because it’s made by Microsoft and rode the OOP hype.
- cardanome 7mo ago
  > The fact that C# is becoming the GC language in game dev is proving my point. That is just the Unity effect. Godot adopted C# because they get paid to do so by Microsoft. C# allows for far lees control over the garbage collection compared to D. The decision to use C# is partly responsible for the bad reputation of Unity games as it causes a lot of stutters when people are not very careful about how to manage the memory. The creator of the Mono runtime actually calls using C# his Multi-million dollar mistake and instead works on swift bindings for Godot: https://www.youtube.com/watch?v=tzt36EGKEZo https://www.youtube.com/watch?v=tzt36EGKEZo
  - debugnik 7mo ago
    C# wouldn't be a problem for Unity if they hadn't mapped most engine abstractions to class hierarchies with reflection-based dispatch instead of value-type handles and the seldom interface, and had dropped the Boehm GC. .NET has actually got a lot of features to avoid allocations on the hot paths.
    - pjmlp 7mo ago
      The problem is called Mono, and Unity's refusal to pay for an update.
      - thezipcreator 7mo ago
        instead they made (or funded? not exactly sure) il2cpp which is a batshit compiler that compiles IL to C++ for better performance, I guess. sidenote, I wonder how many other low-level to high-level compilers exist out there. can't be many.
        debugnik 7mo ago
        AFAIK, the original reason to build IL2CPP was to appease console certification and leave behind Mono's quirky AOT on iOS. Capcom is also using their own C# implementation targeting C++ for console certification. Allegedly some games are now managing to ship on console with ports of .NET NativeAOT.
ceteia 7mo ago
[dead]
- arcadia_leak 7mo ago
  D by definition meets the FFmpeg's criteria because it's also a C compiler. Because of that I never wondered how D performs in the benchmarks, as I know for sure that it can give me the performance of C where I need it.
  - ceteia 7mo ago
    But then, to use D for performance, would I then have to master both D, C and their interaction? That doesn't seem great. It's like having to learn 2 languages and also how they interact.
    - atilaneves 7mo ago
      No, you can just write D. It'll have the same performance as C, if you write C-like code. It might have better performance than C if you use templates (just like in C++).
      - ceteia 7mo ago
        But why then did arcadia_leak imply as far as I understood him that C is needed for performance in D? But D is not included in the benchmarks game at debian.net, which isn't fair to D either as far as I can tell.
        petre 7mo ago
        Not necessarily, you can just call the functions in the C library from D as you'd call them from C or C++ with the added benefit of being able to leverage the D GC, RAII, macros etc. https://dlang.org/spec/interfaceToC.html https://dlang.org/spec/interfaceToC.html Dunno about the Debian benchmarks game or their build environment. I did my own benchmarks and it was quite easy to write working D code compared to C, C++ or Rust. I used LDC, the LLVM D compliler as opposed to DMD. Dub is not that seamless compared to Cargo but given that you have to set things up manually, it doesn't encourage dependency hell. If you're writing networking code, Go is probably a better choice than vibe.d.

rafaelmn 7mo ago

> 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.

arcadia_leak 7mo ago
> 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.
- rafaelmn 7mo ago
  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++ :)
  - arcadia_leak 7mo ago
    > D/C#/Java are valid options I'm never picking D This is perfectly fair. > D was in the perfect spot to fill if it did not make the GC decision I just find it hard to believe that the GC is the one big wart that pushed everyone away from the language. To me, the GC combined with the full power of a systems language are the killer features that made me stick to D. The language is not perfect and has bad parts too, but I really don't see the GC as one of them.
    - zem 7mo ago
      go had a similar early trajectory where c++ programmers rejected it due to the gc. it gained traction among python/ruby/javascript programmers who appreciated the speed boost and being able to ship a single static binary.
    - Cloudef 7mo ago
      Its not the GC, its that D has no direction. Its kitchen sink of features and the optionality just fragments the ecosystem (betterC, gc) etc, making reusing code hard.
      - thezipcreator 7mo ago
        this is the main issue I think with D, yeah. regarding kitchen-sink-ness it's at least nowhere near as bad as C++, but that bar is basically below the ground anyway so it's not much to write home about.
arcadia_leak 7mo ago
> 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.
xigoi 7mo ago
> The fact that C# is becoming the GC language in game dev is proving my point. Popularity is not proof of anything. C# is popular because it’s made by Microsoft and rode the OOP hype.
cardanome 7mo ago
> The fact that C# is becoming the GC language in game dev is proving my point. That is just the Unity effect. Godot adopted C# because they get paid to do so by Microsoft. C# allows for far lees control over the garbage collection compared to D. The decision to use C# is partly responsible for the bad reputation of Unity games as it causes a lot of stutters when people are not very careful about how to manage the memory. The creator of the Mono runtime actually calls using C# his Multi-million dollar mistake and instead works on swift bindings for Godot: https://www.youtube.com/watch?v=tzt36EGKEZo https://www.youtube.com/watch?v=tzt36EGKEZo
- debugnik 7mo ago
  C# wouldn't be a problem for Unity if they hadn't mapped most engine abstractions to class hierarchies with reflection-based dispatch instead of value-type handles and the seldom interface, and had dropped the Boehm GC. .NET has actually got a lot of features to avoid allocations on the hot paths.
  - pjmlp 7mo ago
    The problem is called Mono, and Unity's refusal to pay for an update.
    - thezipcreator 7mo ago
      instead they made (or funded? not exactly sure) il2cpp which is a batshit compiler that compiles IL to C++ for better performance, I guess. sidenote, I wonder how many other low-level to high-level compilers exist out there. can't be many.
      - debugnik 7mo ago
        AFAIK, the original reason to build IL2CPP was to appease console certification and leave behind Mono's quirky AOT on iOS. Capcom is also using their own C# implementation targeting C++ for console certification. Allegedly some games are now managing to ship on console with ports of .NET NativeAOT.

ceteia 7mo ago

[dead]

arcadia_leak 7mo ago
D by definition meets the FFmpeg's criteria because it's also a C compiler. Because of that I never wondered how D performs in the benchmarks, as I know for sure that it can give me the performance of C where I need it.
- ceteia 7mo ago
  But then, to use D for performance, would I then have to master both D, C and their interaction? That doesn't seem great. It's like having to learn 2 languages and also how they interact.
  - atilaneves 7mo ago
    No, you can just write D. It'll have the same performance as C, if you write C-like code. It might have better performance than C if you use templates (just like in C++).
    - ceteia 7mo ago
      But why then did arcadia_leak imply as far as I understood him that C is needed for performance in D? But D is not included in the benchmarks game at debian.net, which isn't fair to D either as far as I can tell.
      - petre 7mo ago
        Not necessarily, you can just call the functions in the C library from D as you'd call them from C or C++ with the added benefit of being able to leverage the D GC, RAII, macros etc. https://dlang.org/spec/interfaceToC.html https://dlang.org/spec/interfaceToC.html Dunno about the Debian benchmarks game or their build environment. I did my own benchmarks and it was quite easy to write working D code compared to C, C++ or Rust. I used LDC, the LLVM D compliler as opposed to DMD. Dub is not that seamless compared to Cargo but given that you have to set things up manually, it doesn't encourage dependency hell. If you're writing networking code, Go is probably a better choice than vibe.d.