[ezy]

I didn't want to put down the effort of the OP, because even they admit it's an interesting experiment, not something they recommend that anyone use, and I do think it's an interesting experiment. But I have exactly this feeling in general.

I like the idea of Rust, but I feel it has, unfortunately, been taken over by the seductive idea that abstraction is the purpose of a programming language (e.g the C++ crowd, among others). I can say from long experience, that while it probably won't impede its popularity, this isn't real progress in programming language design. These abstractions just create their own problems to solve on top of solving the original problem you wanted to solve by writing a program in the first place.

Inevitably, that means that you end up having to limit yourself to some particular "idiom" or subset of the language in production, so that you can get anything constructive done without the code being inscrutable or unmaintainable or just overblown for the task that's being performed.

I knew it was over when they started debating adding more and more meta-language type system features, and then added async/await -- which is the very definition of creating a problem to solve a problem.

So, as much as I appreciate Rust, I am looking forward a newer systems language with more discipline in its design and direction.

Go isn't perfect, but it definitely trends to the right flavor of simplicity and design discipline.

[KingOfCoders]

I like Rust a lot, enjoyed working with it for a year, I'd just wish the borrow checker would be easier with structs that have data from different sources - so I also didn't want to put down the effort and quite frankly might take a look.

"been taken over by the seductive idea that abstraction is the purpose of a programming language"

This downed Scala.