3 ms·

I get the impression that some people think of crates.io as purely a place for distributing arbitrary Rust free software, while others think it's also a place w

I get the impression that some people think of crates.io as purely a place for distributing arbitrary Rust free software, while others think it's also a place where people are building something like a community-developed "batteries included" standard library for Rust. I think a fair amount of unpleasantness in recent years has come from this disconnect: some people think that by publishing on crates.io you're making some promises (that they might not assume simply for, say, having a repository on github). To me, using an extremely generic name like 'base64' does suggest that you're in the second camp, and so that you might expect to have a conversation that feels more like "we're equals building this project together" than "I'm the maintainer and my judgement is all that matters".

paulgb 3y ago
Great observation. This helps me reconcile the tension I feel between my “maintainers own us nothing” mentality and my disappointment with the way the base64 API issues have been handled.
almatabata 3y ago
Don't all languages, that have this kind of community developed packages, have the same problem? I expect golang, npm and python to have similar issues. Python has less issues because they have a bigger standard library but if you want to do anything advanced you need third party packages. I feel like most of these issues stem from the very young age of Rust (2015 -> v1.0). Give it a few years and these problems will stabilize as the long term crates will survive and the short term will grow stale.
- ithkuil 3y ago
  Golang doesn't because all packages are namespaces by domain name (and more often that not that domain namespace ja GitHub which has its own further "org" namespacing)
kaba0 3y ago
I think you are right. Though I think that one can have all the benefits of the “community-developed stdlib” with the namespaces approach as well — e.g. Java’s new Date/Time API actually comes from a third-party package called jodatime, it was just so good that it found itself implemented in the standard library of java, and then later on plenty other languages as well.
- steveklabnik 3y ago
  Rust has done this as well; hashbrown was an external package, but now powers HashMap and friends.

paulgb 3y ago

Great observation. This helps me reconcile the tension I feel between my “maintainers own us nothing” mentality and my disappointment with the way the base64 API issues have been handled.

almatabata 3y ago

Don't all languages, that have this kind of community developed packages, have the same problem? I expect golang, npm and python to have similar issues. Python has less issues because they have a bigger standard library but if you want to do anything advanced you need third party packages. I feel like most of these issues stem from the very young age of Rust (2015 -> v1.0). Give it a few years and these problems will stabilize as the long term crates will survive and the short term will grow stale.

ithkuil 3y ago
Golang doesn't because all packages are namespaces by domain name (and more often that not that domain namespace ja GitHub which has its own further "org" namespacing)

kaba0 3y ago

I think you are right. Though I think that one can have all the benefits of the “community-developed stdlib” with the namespaces approach as well — e.g. Java’s new Date/Time API actually comes from a third-party package called jodatime, it was just so good that it found itself implemented in the standard library of java, and then later on plenty other languages as well.

steveklabnik 3y ago
Rust has done this as well; hashbrown was an external package, but now powers HashMap and friends.