[masklinn]

It really depends what you mean by "system programming".

If you mean things like foundational libraries & network stacks, then go is not a contender[0]. If you mean system daemons and the like, then languages like ocaml, D, … should also work (and that's assuming you want / need the performance of a native binary, if you don't then the world's your oyster).

[0] to my understanding — and I may be completely mistaken here — memory-safe ADA with dynamic allocation and without GC is pretty much an active research field so fails either "memory safe" or "suitable for going fast"

[gmueckl]

D with its conservative GC may run into random issues on 32 bit platforms. I have seen this effect in some rather trivial programs that should have used only a few MB of memory, but ended up eating up their whole address space and crashing. Not all D programs are affected all the time, mind you. But it's a bummer if it happens.

Having made this experience, I doubt that conservative GC can ever be declared safe, unlike completely precise GC.

[skocznymroczny]

D 2.085 added support for precise garbage collector.

[gmueckl]

It is still not enabled by default, though. I would suspect that you need to audit your code for pointers stored in integers amd other shenanigans before enabling it in production.

[titzer]

> then go is not a contender[0] > [0] ... memory-safe ADA with dynamic allocation and without GC is pretty much an active research field so fails either "memory safe" or "suitable for going fast"

Why would D with a conservative collector be "more efficient"? How does being conservative (with stack roots, presumably) fundamentally make a GC better?

Why would OCaml be better than Go? OCaml is garbage-collected, no opting out.

[masklinn]

> Why would D with a conservative collector be "more efficient"? How does being conservative (with stack roots, presumably) fundamentally make a GC better?

It wouldn't? The footnote was for Ada's applicability in the context of "foundational libraries & network stacks" (as it's often advertised as a very safe yet low-level language), because in my understanding (and again I could be wrong here) it's either GC'd and memory-safe or neither, so same as e.g. D, making it unsuitable for that layer.

> Why would OCaml be better than Go? OCaml is garbage-collected, no opting out.

It wouldn't either? The "also" is the second clause indicates that Go would be suitable for "systems daemons and the like", and so would pretty much any other memory-safe language, possibly restricted to the more efficient ones (non-interpreted / JITed) depending on the specific use-case.

[pjmlp]

Real Time Java on bare metal, Oberon on bare metal (Astrobe), System C#, Modula-3,...

[simiones]

I think the idea was: if by systems programming we mean OS-level or similar, then Go is not a contender, only Rust (from the initial list). However, if by systems programming we mean daemons or other user-space programs, then the list can be extended, from Go and Rust to Go, Rust, D, OCaml etc.

[pjmlp]

Real Time Java on bare metal, Oberon on bare metal (Astrobe), System C#, Modula-3,...

[pjmlp]

Guess in what language Fuchsia IO volume management and TCP/IP stack is written on.