I wonder if Rust has enough momentum to sustain itself now.
That being said, I do think this will slow progress (even if for a short period), many of the engineers laid off were on the Rust core team and contributed a lot of commits and knowledge. Things like the Cranelift backend to speed up compilation for debug builds relied on the wasmtime team who have lost people.
So is Rust going anywhere? No, I'm not even worried about that. However new features and fixes might take longer than expected.
C++20 is a much more fun language than C++11 was, which was itself overwhelmingly more fun than C++98 or C. C++23 and C++26 will continue the trend. If you are not constrained to shoehorn yourself into a C or C++98 environment, all the memory-safety worries Rust was supposed to help with fall away.
Whatever the direct technical impact of the layoffs, the language's credibility has taken a huge blow. Its future was already uncertain, and is, being honest with ourselves, substantially moreso now.
There is a lot to like about Rust. I hope something survives.
A sequel--Dust?--could keep its strengths but focus at the outset on fast builds and better visibility into dependencies, to avoid NPM disease. There must be lots of ideas that it seemed too late for.
Maybe make it relatively easy to import old Rust code, to help get jumpstarted?
Rust's real reason to exist, to displace C, was not working, and may have been doomed from the outset. Rust has been taking users from Java, Go, and Python; and some C++, in places where coding has been hamstrung by archaic "style" restrictions. But very few C coders have moved. That may be just because any who might have jumped already had. (Some of those might have come over from a pause at Go.)
Rust is a far, far better language than Java and Go. It never had a chance against C++, which picks up more new users every single week than the total who have ever used Rust. If Rust or its sequel could give people on Java and Go a language with a future, that would be a seriously worthwhile achievement.
Making a borrow checker less strident would aid adoption; so you always know whether your code and each dependency are "clean", without being prevented from getting work done. The recent experience with that very fast GUI library with a few too many "unsafe" bits made a very deep impression. Nobody wants that experience, especially starting out. Code that is not borrow-clean would get clean soon enough if it is used; and, frankly, dead code never needs to be clean.
I also strongly disagree that Rust has any sort of an uncertain future. It appears to be a well run and stable project. Regularly putting out releases from a variety of contributors.
C++ in 1990, at 10 years, was very far from mature. Rust has come up fast, but maturity, by definition, takes time.
Look around at mature languages. They have shelves of books written about them, in numerous languages. More of their users are employed to write in them than not. They have conferences where most attendees are employed coding them. There are college courses on them. They are specified clearly enough to make a new implementation, and typically have multiple implementations. Multiple important products are written in them. Users get calls from recruiters inviting them to do it elsewhere.
Rust will get all this if it lasts.
This is a good question that like to get answered too.
It is reasonable to assume[0] that the language can keep its promises. However I look forward to seeing data on this in the future.
[0] https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...
What I'm more skeptical about is whether living up to those promises yields a tangible benefit. By skeptical I don't mean to imply that using Rust doesn't yield benefits, just that I would like the PL research world to be in a place where questions like this can be solved properly.