As already stated, one of Rust’s explicit goals is not to have a runtime of any kind. If your program happens to require a garbage collector, and you want to write it in Rust, then you can simply depend on a garbage collector provided by a crate. No need to have it built in when 90% of programs don’t need it. And since you can just include one when you do need it, there can easily be multiple options to choose from. As engineering is all about managing tradeoffs, you want to be able to choose the crate that best matches your particular needs. A single option buried in the standard library and forced upon you may not be the best choice.
That said, most programs should not be written in Rust. They should be written in a language that, like Rust, is memory safe, but it is best if they are written in a language which makes the developers more productive than Rust does. Languages with garbage collectors built in are at the top of that list. Common Lisp, Javascript, Python, Raku, etc; there are plenty of choices. These languages are ideal for exploration and productivity. Even Java or C#, if you can stomach it. Save Rust for later when you have to squeeze every drop of performance out of your program, you’ve already written it once so that you already know exactly what you need, and you can justify the expense of the rewrite using operational savings. Optimal performance will probably happen once you can drop the garbage collection entirely, and Rust truly shines when used that way.
> it is best if they are written in a language which makes the developers more productive than Rust does.
AIUI, recent assessments (including by Google) have found that Rust developers' productivity is competitive with GC languages such as Go.
There's also plenty of reasons to think that a program that's first written in Rust will have fewer defects in the long run than the other languages you mentioned. Of course alternative languages may still have a role to play for quick-and-dirty, purely exploratory coding, but that's about it.
True, but it is my understanding that in those cases they were reimplementing existing services, where the precise requirements are already known. Exploration isn’t for quick-and-dirty programs, but for finding the right solution in a wide space of possibilities where you don’t even know what all the requirements are yet.
For example, consider programming a game. If your only concern is putting triangles on the screen, then there are some well-known solutions that you can adopt that will work great and you can do that in any language you want. But gameplay mechanics are a different beast entirely; inventing (or discovering) something new and fun is exploratory. You’ll benefit most from a dynamic language where you can change your code rapidly, and features like strict typing and lifetimes are not so helpful. For this a language like Common Lisp, with garbage collection, a REPL, gradual typing, just-in-time compilation, and support for multiple programming paradigms is ideal. Or Javascript, or whatever.
That said, most programs should not be written in Rust. They should be written in a language that, like Rust, is memory safe, but it is best if they are written in a language which makes the developers more productive than Rust does. Languages with garbage collectors built in are at the top of that list. Common Lisp, Javascript, Python, Raku, etc; there are plenty of choices. These languages are ideal for exploration and productivity. Even Java or C#, if you can stomach it. Save Rust for later when you have to squeeze every drop of performance out of your program, you’ve already written it once so that you already know exactly what you need, and you can justify the expense of the rewrite using operational savings. Optimal performance will probably happen once you can drop the garbage collection entirely, and Rust truly shines when used that way.