Nimrod, like D, does great things in terms of metaprogramming and static code generation whilst providing a GC that abstracts away from memory management. Rust on the other hand thrusts memory management into the programmers face, excelling at providing safe, deterministic control over allocation and a relatively advanced type system compared to the incumbent systems programming languages. Nimrod and D seem like worthy alternatives to Go and C#, where as Rust is providing a much needed alternative to the venerable C and C++ languages that have dominated systems progamming for the last forty years.
It seems to me like a marketing failure that Nimrod and D seem to be attempting to go after the low level systems programming domains when they should really be competing at a higher level of abstraction.
Agreed. The language defaults to safety and immutability, and linear types and regions are built into the type system. With the addition of mandatory RAII and unsafe blocks, safe allocation and concurrency primitives can be built as libraries rather than being baked into the language.
I don't know enough about Oberon and the Modulas as I should, but I'm guessing GC was the default and was required for safety? The libraries required GC too?
GC was originally intended to be the most common form of allocation in Rust, but once linear types and regions were properly implemented it turned out that GC wasn't nearly as necessary as was previously thought. It is definitely useful though for some use cases, which is why it will be built as a library, with language hooks to make it clean to use, but users definitely won't have to pay for it if they don't use it.
Ahh - your comments about Unix taking the wrong path in another story have more context now - I wasn't aware that GC had been integrated into an actual working kernel in the wild. Very interesting!
Afterwards, there were improved systems which provided a better experience, improved the programming language and had some parts moved from Assembly into proper Oberon. Namely EthOS and Active Oberon (AOS/Bluebottle).
If such systems had got industry support, who knows how mainstream computing would be now.
For example: realtime systems, rendering threads, embedded systems that require minimal runtimes. Smaller subroutines on the whole don't really need it, and those small performance gains can add up considerably in an intensive system. GC is mainly useful for things with undetermined lifetimes. Glue code essentially.
It seems to me like a marketing failure that Nimrod and D seem to be attempting to go after the low level systems programming domains when they should really be competing at a higher level of abstraction.