So what are the alternatives for system programming?
Rust, Golang? Any other true contenders?
Rust, Golang? Any other true contenders?
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"
Having made this experience, I doubt that conservative GC can ever be declared safe, unlike completely precise GC.
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.
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.
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.
Does that have any affect on OpenJDK?
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.
https://en.wikipedia.org/wiki/List_of_Java_virtual_machines#...
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"
https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...
Meanwhile the other vendors listed above do care about supporting the JVM ecosystem at large, so no worries, OpenJDK is alright.
And if Oracle does get bored of it, it would be interesting to see if any of them actually cares a bit more than they did with Sun.