D Programming Language

Post by pron » Thu, Feb 12, 2026, 8:37 PM UTC

ceteia wrote: post #173

pron wrote: post #159

Earlier quoted context omitted.

> If you really want to call that a GC you should at least make a huge distinction that it works at compile time: the generated code will have drop calls inserted without any overhead at runtime. But no one calls that a GC. Except for the memory management literature, because it's interested in the actual tradeoffs of memory management. A compiler inferring lifetimes, either automatically for some objects or for most…

> A refcounting algorithm, like that found in Rust's (and C++'s) runtime is such a classic GC that not calling it a GC is just confusing. But is it not easy to opt out of in C, C++, Zig and Rust, by simply not using the types that use reference counting? And how does your performance analysis consider techniques like arenas and allocating at startup only?

Post by lossolo » Thu, Feb 12, 2026, 9:57 PM UTC

igouy wrote: post #190

lossolo wrote: post #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 ad…

> weren't any D entries fwiw nbody.dlang 2005 https://salsa.debian.org/benchmarksgame-team/archive-alioth-... Like 20 years ago: https://web.archive.org/web/20060525101747/http://shootout.a...

Post by debugnik » Thu, Feb 12, 2026, 10:57 PM UTC

cardanome wrote: post #164

rafaelmn wrote: post #121

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…

> 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 me…

Post by pron » Thu, Feb 12, 2026, 11:20 PM UTC

pron wrote: post #159

brabel wrote: post #154

Earlier quoted context omitted.

Op saying Rust has a kind of GC is absurd. Rust keeps track of the lifetime of variables and drops them at the end of their lifecycle. If you really want to call that a GC you should at least make a huge distinction that it works at compile time: the generated code will have drop calls inserted without any overhead at runtime. But no one calls that a GC. You see OP is trying to murk the waters when they claim C has a…

> If you really want to call that a GC you should at least make a huge distinction that it works at compile time: the generated code will have drop calls inserted without any overhead at runtime. But no one calls that a GC. Except for the memory management literature, because it's interested in the actual tradeoffs of memory management. A compiler inferring lifetimes, either automatically for some objects or for most…

Post by troad » Thu, Feb 12, 2026, 11:45 PM UTC

torginus wrote: post #53

arcadia_leak wrote: post #39

Earlier quoted context omitted.

On the flipside, with OOP is usually quite easy to put a debugger breakpoint on a particular line and see the full picture of what the program is doing. In diehard FP (e.g. Haskell) it's hard to even place a breakpoint, let alone see the complete state. In many cases, where implementing a piece of logic without carrying a lot of state is impossible, functional programming can also become very confusing. This is espec…

That is true, but on the flip-flip side, while procedural or FP programs are usually easy to run piecewise, with OOP, you have to run the entire app, and navigate to the statement in question to be even able to debug it. Imho, most FP languages have very serious human-interface issues. It's no accident that C likes statements (and not too complex ones at that). You can read and parse a statement atomically, which mak…

    def some_function(thing, doodad, doohickey) do
      thing
      |> foo(doodad)
      |> bar()
      |> baz(doohickey)
      |> quux()
    end