4 ms·

>At the moment, I’m only targetting a tiny subset of the D programming language. The language comes with a runtime, featuring a garbage collector. It’s my first

>At the moment, I’m only targetting a tiny subset of the D programming language. The language comes with a runtime, featuring a garbage collector. It’s my first journey to the land of D-asm.js, and there’s no way I’m bringing the D runtime with me – especially if I need to port it to Javascript first. This is basically why D is not a good systems programming language. Theoretical GC performance aside, barring a miracle, they will never have the resources to develop a high quality GC and even less chance to maintain high quality ports across relevant platforms (heck they couldn't even compile on mobile platforms until recently).

duaneb 10y ago
It's really hard to make a case for GC and systems (constrained latency, memory, embedded, realtime) being compatible at all. I've had some success using my own allocation pools just to avoid latency slowdowns in critical loops—functionally disabling GC for that call tree. And I know that you can disable the GC in D, but it's hard coming up with a good use case for the language that wouldn't be fit better with another smaller, tailored language.
Ace17 10y ago
That's more a question of entanglement between the runtime and the language, than a question of GC performance. Most of our projects, at work, are in D, and we never wished for a "higher quality GC" (except at the very start, when we started to use D, and were lured into thinking that "now that we have a GC, we don't need to be cautious with our allocations anymore"). Bare-metal in C and C++ is relatively easy, because the compiler doesn't insert runtime-dependent code to implement language constructions. Avoiding this in D is a lot more subtle, as you have to know which language features require the runtime. For example, array copy (dest[0 .. 8] = src[0 .. 8]) will generate a call to the runtime. Almost every operation on associative arrays will also generate such calls. Class declaration will also generate references to the runtime (for dynamic type information). However, there are lots of non-runtime things already making D a better C, like array slices and CTFE. Which means that D is a good systems language, you just have to use it as a better C, and restrict yourself to language features not requiring the runtime.
p0nce 10y ago
> This is basically why D is not a good systems programming language The ability to run without its runtime is certainly a feature of good system programming languages.

duaneb 10y ago

It's really hard to make a case for GC and systems (constrained latency, memory, embedded, realtime) being compatible at all. I've had some success using my own allocation pools just to avoid latency slowdowns in critical loops—functionally disabling GC for that call tree. And I know that you can disable the GC in D, but it's hard coming up with a good use case for the language that wouldn't be fit better with another smaller, tailored language.

Ace17 10y ago

That's more a question of entanglement between the runtime and the language, than a question of GC performance. Most of our projects, at work, are in D, and we never wished for a "higher quality GC" (except at the very start, when we started to use D, and were lured into thinking that "now that we have a GC, we don't need to be cautious with our allocations anymore"). Bare-metal in C and C++ is relatively easy, because the compiler doesn't insert runtime-dependent code to implement language constructions. Avoiding this in D is a lot more subtle, as you have to know which language features require the runtime. For example, array copy (dest[0 .. 8] = src[0 .. 8]) will generate a call to the runtime. Almost every operation on associative arrays will also generate such calls. Class declaration will also generate references to the runtime (for dynamic type information). However, there are lots of non-runtime things already making D a better C, like array slices and CTFE. Which means that D is a good systems language, you just have to use it as a better C, and restrict yourself to language features not requiring the runtime.

p0nce 10y ago

> This is basically why D is not a good systems programming language The ability to run without its runtime is certainly a feature of good system programming languages.