borrow checker barely ever uses the term “borrowed” and I have to relesen it every time I pick up rust
async is absurdly complicated, there are so many gotchas. Streams are actual hell
crates are github only and have no namespacing. Java has the best solution IMO with their reverse domains for example com.github.myuser.myproject.somepackage
It’s good to know I’m not alone. But I’ll never choose C/C++ over Rust. If I need speed and typing, it’s Rust, no questions asked. For everything else, there’s Python. I just wish Rust has better GUI frameworks…
Your second point has been a focus area for them for years, and we’ve seen it improve with async fn in trait, async closures, etc. Hopefully we see that continue to improve over time.
The third point has a solution in the works already (at least for crates.io). The accepted (I believe) proposal is that crates themselves act as “namespaces” and you can publish crates like bevy::render or hyper::utils that get loaded under some parent module by the compiler. Publishing crates with names containing :: would be constrained to those who maintain the parent crate (so bevy or hyper in that case).
Domains are, sure but the space is much much larger. With namespaces the space is for example namespace x crate instead of just crate. With domains it’s impossibly large. And if you introduce some kind verification with domains e.g putting something in the DNS TEXT entry, or calling a well-known path, or or or, you basically can’t squat anything well-known anymore.
As for github, you must have a github account to create a crate on crates.io. to my knowledge there is no alternative crates registry. Point me to one if you do, because I’d be grateful and willing to publish my crates there.
My biggest issues with rust are
It’s good to know I’m not alone. But I’ll never choose C/C++ over Rust. If I need speed and typing, it’s Rust, no questions asked. For everything else, there’s Python. I just wish Rust has better GUI frameworks…
Your second point has been a focus area for them for years, and we’ve seen it improve with async fn in trait, async closures, etc. Hopefully we see that continue to improve over time.
The third point has a solution in the works already (at least for crates.io). The accepted (I believe) proposal is that crates themselves act as “namespaces” and you can publish crates like
bevy::renderorhyper::utilsthat get loaded under some parent module by the compiler. Publishing crates with names containing::would be constrained to those who maintain the parent crate (sobevyorhyperin that case).Domain are also susceptible to being hijacked, unfortunately.
Also what do you mean by github only?
Domains are, sure but the space is much much larger. With namespaces the space is for example
namespace x crateinstead of justcrate. With domains it’s impossibly large. And if you introduce some kind verification with domains e.g putting something in the DNS TEXT entry, or calling a well-known path, or or or, you basically can’t squat anything well-known anymore.As for github, you must have a github account to create a crate on crates.io. to my knowledge there is no alternative crates registry. Point me to one if you do, because I’d be grateful and willing to publish my crates there.