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"
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.
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.
> 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.
> 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.
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.
I'm pretty fond of Java (OpenJDK) since it also offers portability. Yes Java is much slower than Rust, but it's fine when high performance isn't necessary.
Neither Java nor Go for system programming. Java and its license is also controlled by one of the most evil companies, google at least pretend not to be evil...
Real Time Java proves otherwise. And then there is this pseudo-copy of Java running on phones and IoT as well, both support writing user space drivers in Java.
Fuchsia's IO volumne management and TCP/IP stack is written in Go.
ChromeOS hypervisor (gVisor) and Android GPU debugger (GAPI) are written in Go.
OpenJDK is GPL, you can take it and do whatever you want in spite the fact that that evil company does like 90% of the work and no one else has stepped up to pick Sun's remains, regardless how Oracle has managed the assets afterwards.
OpenJDK wasn't yet a thing when the other data collection evil company decided they didn't want to pay for licenses like everyone else.
None of the companies described there had any issue either with Sun nor with Oracle.
Nor the ones repacking Oracle's work (some of them do contribute a bit to OpenJDK as well to be fair, although usually not JEPs) with their own additional features, https://adoptopenjdk.net/sponsors.html
"James Gosling Triangulation's Interview on Google vs. Sun"
ATS looks interesting. It continues to boggle my mind that Ada/SPARK isn't given more attention in conversations like this. It seems to do everything Rust promises while being simpler (SPARK anyway) and more powerful, and with 40 years of history and experience behind it.
Ada doesn't use a garbage collector, so it appears that understanding isn't right. I think it had one as part of the standard in the 80s, but maybe such problems made it go away.