>Well, that says it. Rust has pivoted to web stuff. For which Go is probably better suited. I think the focus should be entirely on this line: >The other doma

>Well, that says it. Rust has pivoted to web stuff. For which Go is probably better suited. I think the focus should be entirely on this line: >The other domains were - and are! - viable long term opportunities for Rust, but they were seen as not as quick to adopt new technology (embedded), depended on a new platform that had not yet seen widespread adoption itself (WebAssembly), or were not a particularly lucrative industrial application that could lead to funding for the language (CLIs) The problem is "web stuff" was the only domain that could realistically fund the development of Rust. This is further supported by Mozilla dropping the Rust project with all it's funding issues and the slack being largely picked up by companies like Amazon. The systems/game languages are still possible, but if the Rust team hadn't focused on serving the needs of an industry that could ensure it's longevity, there might not be any Rust today to say "Good-bye" to. And I think that's fair. It's unreasonable to expect a project to prioritize your needs when you are unable or unwilling to fund the project. The is also true of the 'crates.io' async problem - the companies that are ready to adopt Rust and pay developers to write Rust are companies in which async networking is a big deal. If there are other libraries that need to exist in any other domain, well someone needs to be paid to write them and it doesn't look like there are very many entities that exist to take up that challenge.