I did some analysis on crates.io to find the top name squatters. Then I did some calculations and found that the top name squatter created their crates at a rate of about one ever 30 seconds for a period of a week straight.
I send the analysis to the crates.io team and pointed that they have a no-automation policy.
They told me that it was not sufficient proof that someone was squatting those names. That's my problem with crates.io is that they have a clear policy and they don't enforce it so all the short/easy to remember names for crates are already taken and there is nothing you can do to get it.
> Using an automated tool to claim ownership of a large number of package names is not permitted.
And
- Hey, I found that someone created crates at a rate of about one every 30 seconds for a period of a week straight.
- That's not sufficient proof of squatting.
Whoever answered that, was either supporting the squatter or explicitly in favor of the practice. I cannot conceive that someone would get that evidence in their hands, and in their right mind think that the claim is bogus. Hell, I'd even be willing to suppress the squatter with evidence of one new crate created every 30 seconds for one hour!
The only reasonable conclusion to make is that they didn't really care. But then don't save face and claim that you do. That's hypocrisy.
There's a secret effort in the Rust community to supplant Crates.io and create an entirely new package ecosystem with proper namespacing, security, and much better community.
Not naming names, but I know several people working to put Crates.io out to pasture.
There's a level of playing nice with them for the time being (eg. build reproducibility), but it's only KTLO.
Crates.io needs to die for Rust to thrive. They're a bungled, mismanaged liability. New code, new leadership.
Crates.io doesn't need to die necessarily. It needs some competition as a wake-up call.
Once a better alternative is out there, crates.io will either wither and die or improve. If it matches its competition in terms of quality and reliability, everyone is better off. If not, the alternative solution will take over.
I'm eager for this crates.io alternative to land, assuming they don't break too many projects in their improvements.
Drama avoidance and avoiding bikeshedding seem obvious. Much easier to present a working system than a design that will get nitpicked into irrelevancy.
That quite funny. Just like when some people formed a violent militant group to take down a violent tyranical dictatorship. Of course they would promise that they would absolutely de-arm right after the dictatorship has been overthrown, and immediately establish a peaceful democratic government with fair election. They absolutely would, would they? They would never turn into what they were formed to replace, would they?
This was my first thought too. And there are a lot of questions that will get asked, like, will all crate library names start being prefixed as well? So you end up with
use::bar; // changing to
use::foo::bar;
I assume the library names that can be overridden in cargo would still be accepted, and then it all gets a little messy. The transition would be very messy.
Write some automated analysis that looks up popular packages on npm, pub.dev, rubygems, nuget. "Rustify" the package names. Add to it frequently used words, maybe popular names, etc. Then, write a script that creates an empty package, registers a name on crates.io every thirty seconds, and then you have about 20k package names after a week that nobody can use.
Candle just released the Candle Cloud (https://cloud.candle.dev) with a generous free tier. This allows for anyone who knows basic SQL to create a backend api application and host the application on the Internet. This is made possible by our framework Wick (https://github.com/candlecorp/wick)
If anyone has any questions or wants any help getting your own idea deployed, I will be watching here or you can join our Discord (https://discord.gg/candle) and we can help you there.
The idea? Use Wick to build a low-code request enrichment HTTP proxy, and then harness that same functionality for a CLI app.
For those wary of low-code, we've got you covered. There's a dedicated section showcasing how to employ Rust to craft a WebAssembly component. This ensures you can seamlessly embed any intricate logic into the same workflow.
Well, you're almost certain to hit a hydrogen atom within a meter of travel in deep space. Larger objects will be less common, no doubt.
> That is how big and empty the universe is.
Indeed. The corrollary is that there's an awful lot of space to travel through in search of something to hit.
Regarding that 0%: I don't think it's possible for you to travel through space fast enough to catch up with the expansion of the Universe. It follows that your search for something to hit goes on forever, and the chance of eventually hitting something must be 100%.
Whoah! Not so fast, Denton! As you are travelling looking for something to hit, the Universe is expanding, and the distance between galaxies is growing. So the longer you travel, the less likely you are to find something to crash into.
I don't know how to work out the sums. I don't know how to multiply a 0% chance by a 100% chance. Or rather, I do; it just gives an answer that I don't like intuitively. It should be a 0% chance; I guess it probably is.
