Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Credits
can have a nontrivial (or “thick”) runtime and doesn’t need to limit itself to “zero-cost” abstractions.
Wouldn't that be a bigger rust rather than a smaller one?
Not an area I'm particularly interested in, given that I do embedded and hard realtime development. Rust is the best language for that now, I just which allocations were fallible as well. And storage/allocator API was stabilised.
Not unless you consider Go a "bigger" language than Rust. The blog post means "smaller" in terms of what the user has to learn and think about, rather than smaller in implementation size or resulting binary.
I would indeed consider Go a bigger language, because I do indeed think in terms of the size of the runtime.
But your way of defining it also makes sense. Though in those terms I have no idea if Go is smaller or not (as I don't know Go).
But Rust is still a small language by this definition, compared to for example C++ (which my day job still involves to a large extent). It is also much smaller than Python (much smaller standard library to learn). Definitely smaller than Haskell. Smaller than C I would argue (since there are leas footguns to keep in mind), though C has a smaller standard library to learn.
What other languages do I know... Erlang, hm again the standard library is pretty big, so rust is smaller or similar size I would argue. Shell script? Well arguably all the Unix commands are the standard library, so that would make shell script pretty big.
So yeah, rust is still a pretty small language compared to all other languages I know. Unsafe rust probably isn't, but I have yet to need to write any (except one line to work around AsRawFd vs AsFd mismatch between two libraries).
If you want a high-level, convenient Rust, it's already there: It's Rust with liberal use of Arc and .clone() and Box<dyn Trait> and so on. If you want things to be convenient instead of efficient, Rust already has everything you need.