It feels like Rust is two languages in one: a high performance zero cost abstraction language that tracks pointer ownership, and a package rich and hyper explicit application language build atop all the guts. That's why I say high-level application use cases, because most high-level applications are not concerned with raw performance but rather with functionality and user experience. The parts that are concerned with throughput can be implemented using tooling where those knobs are available. I have enjoyed writing a cli and api server and various libraries in Rust. But every so often I am left wondering when Swift might be able to replace it for my higher level concerns. Alternatively, it would be neat to see some effort put behind a "convenient rust" type of compile mode for modules where you could compile with things like implied clones, unified owned vs reference types, auto-arc/box, etc.
Personally I'd love to see a forked flavor of TypeScript with static compilation and multithreading (which implies a lot more immutability, etc). Maybe I should give Swift a try…
Just about GC language has similar tradeoffs. The question here would be why Swift over Go/C#/Java/Python/Typescript?
1. Much more expressive and featureful than Go
2. More concise and modern than C# (debatable maybe?)
3. Less JVM than Kotlin (the apples-to-apples; Java is a much worse language)
4. Way, way faster and more typesafe than Python
5. Better support for parallel execution (and probably fine-tuning other performance knobs) than TypeScript
2. I think the C# team has done very well modernizing. The runtime is a bit of a bother though.
3. There's Kotlin/Native and Kotlin/JS.
4. Python has dev speed and ML benefits.
5. If you're going this way, performance probably isn't your main goal?
All-in-all, Swift is interesting, but (IMHO) lackluster crossplatform support and toolchain is a problem.
If you can come up with a precise transform from "convenient/sloppy rust" to the underlying language, it can already be implemented via proc macros and the #[attributes] syntax. This is how async programming was prototyped in Rust before it became part of the language proper.
Though I'm not sure it's fair to describe Rc, Arc, Cow etc. as "library bloat". It certainly adds some boilerplate, but it's designed to stay manageable.
(Arguably, good coding practice should also informally document why the Rc, etc. is needed and can't be refactored away, i.e. what parts of the program are controlling the lifetime of each Rc'd object.)
Maybe it was a mistake to conflate lifetimes and generics. It wouldn't be so bad to deal with references in Rust if you didn't have to include lifetime parameters when building APIs. It seems silly that (in my experience) people gravitate toward structs with owned fields just to avoid specifying the lifetime of a borrowed field.