If Go designers weren't so much anti-modern language design, in many scenarios where people are rushing to do RIIR, they would be better served with Go, if those modern features were part of the language.
Having said that, there are still OCaml (as you noted), Haskell, .NET languages with Native AOT, JVM languages with GraalVM/OpenJ9, D, Nim, Swift, ....
And if one wants to get fancy with type systems, Idris, Dafny, FStar,..
I think OPs general point, although maybe not what they stated is correct: it’s easy to write GC’d code. It’s “easy” to write code with manual memory management. It’s “easy” to write RC code. But it’s hard to write borrow checker code. And that will probably limit adoption, even though the goals of Rust are good.
> If GC is an option and you want all the nice parts of Rust, use OCaml
So are you saying it would be possible to use a hypothetical "non-GC-enabled" OCaml compiler that complains if GC'd code is invoked/generated, and it would be a similar experience as using Rust?
No, simply because GC isn't an optional part of ocaml's design. You can "disable" it only in the sense that you stop any frees from happening.
In order to do away with Garbage collection you'd need to completely change the type system, and while you might get a result which ends up looking a lot like ocaml, it won't be ocaml any more than ocaml is sml.
This is what Rust started out as, by the way. In my opinion, it should have stayed that way. Post-Mozilla Rust has been nothing but a gigantic disappointment.
Early versions of Rust "started out" with GC: the language was broadly similar to Golang, though with a lot of influence from Ocaml and functional languages more broadly. The comprehensive use of borrowck to avoid GC altogether was only implemented around 2014 or so, hence shortly before the Rust "1.0" release in 2015.
Yet another PoV: for some things with critical timing or so, GC might be a problem. But most of the time, it isn’t. The performance/predictability topic could also be reviewed…
I was talking with a colleague about that, he said “in C I know exactly where things are when” And I replied that under any OS with virtual memory, you have basically no clue where are things at any time, in the N levels of cache, and you cannot do accurate time predictions anyway… [1]
I’m convinced today GC is the way to go for almost all. And I was until 5 years ago or so, totally opposed to that view.
Even with critical timing, real time GCs exist for decades now, PTC and Aicas are two surviving companies selling software tooling for embedded markets, including their own JVM implementations, with AOT compilers, bare metal deployments and real time GC.
Many of their customers are factory processes and military deployments with weapons control, two scenarios where any kind of stall might produce deadly results.
Thank you so much! Now I have a more powerful argument, when at work somebody says a motor ECU cannot use GC, because of time constraints! Of course I assume there might be a catch from the cost PoV, where Mil may be ok, automotive consumer goods may be a problem (today)
The problem is that it is very easy to write non-GC'd code in a GC'd language, but the other way around it is much much harder.
Therefore, I think the fundamental choice of Rust to not support a GC is wrong.