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…
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.
I find it ridiculous that they started with github in the first place, but who am I to judge. It is ironic that in order to contribute a non-github solution, you still need to create a github account to make a PR.
@onlinepersona I’m quite certain that if you have a working solution, visible somewhere on internet, you can ping them on zulip/discourse to ask someone to pull your code.
Oh really? 🤔 Every project on Github that I’ve tried to contribute to from outside has been resistant to it. But maybe I could give cargo.io a try. Zulip you say? Interesting choice… requires creating yet another account since it doesn’t seem to be federated…
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).
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…
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.
@onlinepersona @Miaou for github they said for years that they would welcome patches but so far nobody came, nor payed someone to do it for them.
I find it ridiculous that they started with github in the first place, but who am I to judge. It is ironic that in order to contribute a non-github solution, you still need to create a github account to make a PR.
@onlinepersona I’m quite certain that if you have a working solution, visible somewhere on internet, you can ping them on zulip/discourse to ask someone to pull your code.
Oh really? 🤔 Every project on Github that I’ve tried to contribute to from outside has been resistant to it. But maybe I could give cargo.io a try. Zulip you say? Interesting choice… requires creating yet another account since it doesn’t seem to be federated…
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).