Hypothesis: maybe this guy would have been better off learning SystemJava instead of Rust? Given that he already knows Java. SystemJava is a very odd animal. I

Hypothesis: maybe this guy would have been better off learning SystemJava instead of Rust? Given that he already knows Java. SystemJava is a very odd animal. It's a Java superset that is sort of hidden away inside the Graal project and not really advertised. SystemJava is Java for systems programming, proven out by its use to write a full JVM (with garbage collector etc, all in Java). SystemJava is syntactically identical to Java, so all existing tools and IDEs can work with it. However the semantics are quite different: 1. It's always compiled ahead of time to a standard platform native binary (exe or lib). 2. You can do both GCd and manual memory allocation, pointer arithmetic, stack allocation, calling in and out of C without JNI and so on. 3. Some objects are "magic" and not compiled as objects at all like CWordPointer which lets you do raw ptr derefs. Tutorial example file: https://github.com/oracle/graal/blob/14d366284d137415f3defb23a7eb2b72d44953f3/substratevm/src/com.oracle.svm.tutorial/src/com/oracle/svm/tutorial/CInterfaceTutorial.java#L86 https://github.com/oracle/graal/blob/14d366284d137415f3defb2... With this you can do things like make what appears to be a C library on the outside, but write it with Java on the inside. The parts of the runtime needed will be compiled into the binary. You can rely on the GC for anything that isn't performance sensitive, and use manual memory management for the rest. Or you can use the GraalEE version which has the G1 GC that is these days very fast and powerful, without needing much tuning. SystemJava doesn't have anything like the Rust type system, so it won't catch data races or double frees (when working with manually managed memory). But it might have been a better tradeoff given the skills profile of this team.