3 ms·

What makes the libraries blessed by the language designers so much better than a library blessed by any other trusted party? Rust is an open source language, an

What makes the libraries blessed by the language designers so much better than a library blessed by any other trusted party? Rust is an open source language, and only the core team works on it full time - even then, any one of them could leave at any time and the community at large would need to pick up the slack. This isn't any different than the situation around any of the amazing community libararies in the Rust ecosystem. Heck, libs blessed by the language designers aren't even always the best choice - just look at json manipulation in .NET; you get multiple different stdlib ways to work with json, yet the community still gathers around the much better JSON.NET package. In terms of value proposition, I think the author is just hankering for some .NET style support agreements in order to hedge his maintenance cost bets - and I'm sure there are or will be plenty of consultancies willing to provide this service, so long as the demand exists. That open source language users are entitled enough to expect this service for free from language maintainers... I'm not sure that's completely justifiable.

srssays 10y ago
If a library is supported and maintained by the language designers, then its lifetime will be at least as long as the lifetime of the programming language. Or if the library is replaced, then it will be done through some mechanism of deprecation, rather than sudden abandonment. I don't see the standard library and third-party packages as being in opposition. Far from it. A rich standard library encourages a rich ecosystem of third-party packages. Maintenance costs affect the authors of open source packages even more than they affect commercial users. They are working for free and in their spare time. A rich standard library makes a language attractive to people who want to write packages.
- bluejekyll 10y ago
  Omg. You just made me think about lifetime markers for crates... your project requires a minimum lifetime of stability in a crate or something. Kinda funny.
rmattes 10y ago
I don't think he's arguing that the language designers are the ones that need to be curating crates, he just brought up Python as an example of some sort of curation happening in a similar ecosystem. It's the community at large that needs to be more active about identifying and signaling which crates should be preferred to provide particular functionality. I don't think you even need to just pick one crate for a particular functionality - narrowing the field down from 23 to a handful with well-understood strengths and drawbacks would be a good start.

srssays 10y ago

If a library is supported and maintained by the language designers, then its lifetime will be at least as long as the lifetime of the programming language. Or if the library is replaced, then it will be done through some mechanism of deprecation, rather than sudden abandonment. I don't see the standard library and third-party packages as being in opposition. Far from it. A rich standard library encourages a rich ecosystem of third-party packages. Maintenance costs affect the authors of open source packages even more than they affect commercial users. They are working for free and in their spare time. A rich standard library makes a language attractive to people who want to write packages.

bluejekyll 10y ago
Omg. You just made me think about lifetime markers for crates... your project requires a minimum lifetime of stability in a crate or something. Kinda funny.

rmattes 10y ago

I don't think he's arguing that the language designers are the ones that need to be curating crates, he just brought up Python as an example of some sort of curation happening in a similar ecosystem. It's the community at large that needs to be more active about identifying and signaling which crates should be preferred to provide particular functionality. I don't think you even need to just pick one crate for a particular functionality - narrowing the field down from 23 to a handful with well-understood strengths and drawbacks would be a good start.