> acknowledge the benefits of a small standard library.
I don't though. The perceived benefits of a small standard library exist only in circumstances that then cause the language ecosystem to fail to meet my requirements. These are also the requirements of many similar people in similar shoes, and also include the requirements of specialist usage such as avionics and the like.
The advantage of a small standard library is that it keeps the workload for the language designers manageable when they don't have the manpower to keep a large library properly maintained. The failures of Python's batteries included was IMHO caused by the Python team not having corporate backing and proper funding, not an inherent issue with a large std lib per se.
Rust is a low-investment language like Python: they're not investing sufficiently on the "left hand side" of the transaction. The advantage of a lean std lib is only to them, a small number of people. This is not an advantage to me, the consumer of the language.
Now, I get it, Rust was born out of Mozilla, and they're not Apple or Microsoft or Google. But that's the problem. They need to be picked up by a mega corp like, say, Amazon's AWS team to get the funding they need to do things properly.
> Last time I checked, both Java and C# have rich open source ecosystems.
They didn't for the first decade or two of their existence, and they both owe their large, cohesive standard libraries to that era.
I lament the open sourcing of the .NET framework, because the quality and cohesiveness has plummeted. There are glaring inconsistencies and bugs being thrown over the fence that would have never have made it past the kind of formal code review that occurs at only at corporations.
> This kind of thing happens regardless of who builds the libraries.
That's just not true. If a central, organised, well-funded body writes the standard library, then there is a consistency and cohesion that can never be achieved with an open source community. This is literally the Cathedral vs The Bazaar.
If I use System.Data.SqlClient then I can be confident that it will use System.Xml to return XML fields stored in a database. It'll never use BobsXmlLib or something random like that. That's the benefit to me of an architecture versus an evolution.
> Technology like Rust doesn't have to be All Things to All People at All Times.
Right now, it's not much to not many people. Its popularity is growing, sure, but it has enormous gaps that normally would be filled by the core language team. Some gaps might be filled by the community, but it's going to take a long, long time. These gaps stop many people using the language for production development.
I'm not making up that XML library scenario as some sort of exercise. This is a real problem that I have, in Rust, right now. I wanted to translate a pure C# XLSX parser I write for PowerShell into a Rust library and tool vaguely like "xsv". Something fun to do while on the coronavirus break.
I got bogged down just trying to find an XML library that can handle OOXML in a standards compliant fashion, and is popular enough to be maintained going forward, and is consumable downstream.
In C# this was trivial, even using the API that dates back to the v1.1 days. It would have been trivial in Java and C++ as well. In Rust... ugh. I'll revisit this next year, see if the XML crates have grown some features, performance, and stabilised a bit.
When step #1 is to ponder over comparison tables like this where the only full-featured crate is written in C, not Rust, I lose interest, and this is for something that's just a hobby: https://github.com/RazrFalcon/roxmltree#alternatives
PS: I see comments in crates like this all the time: "vkxml has been made for use with serde-xml-rs and, because of some quirky attributes required by serde-xml-rs, most likely will not work with any other serde xml parser." From: https://crates.io/crates/vkxml
> These gaps stop many people using the language for production development.
Every language has gaps. Rust had a lot more gaps two years ago than it does now. It's called progress. I personally don't see your particular use case being addressed any time soon. Oodles of people don't need everything developed by a single entity. The success of the Javascript ecosystem should at least make that clear. I freely recognize that some do though.
> I'm not making up that XML library scenario as some sort of exercise.
I didn't say you were? Your comments are so bloated and you keep rehashing every single point.
> I got bogged down just trying to find an XML library that can handle OOXML in a standards compliant fashion, and is popular enough to be maintained going forward, and is consumable downstream
We already covered this. Why do you keep repeating it? I literally addressed this in my very first comment to you. And you're still complaining about it. Why?
I already told you: Rust doesn't have to be All Things to All People at All Times. Maybe instead of focusing on responding to that with some quip you think is clever, you could recognize it for what it is: an acknowledgment that Rust may not be ready for your use case. Why in the world is that so hard for you to accept? Like, this isn't rocket science. If you need a high quality XML parser, and Rust doesn't have one and you can't write one yourself, then the answer is pretty simple. The thousands of words you've had to write to express this point---and then repeat over and over---is just absolutely baffling.
If instead you needed, say, a high quality JSON parser, then we wouldn't be having this conversation at all. You probably would have used `serde_json` and you would have been as happy as a pig in shit.
> The advantage of a lean std lib is only to them, a small number of people.
Definitely not true. In the Python ecosystem, the mindshare split between things like the standard library HTTP client and more popular third party projects like `requests` impacts everyone.
> This is not an advantage to me, the consumer of the language.
Of course it is. As a member of the Rust library team, I can tell you with absolute confidence that we had three choices given our timeline: 1) build a small high quality standard library that serves as a substrate on which high quality third party crates could be built, 2) build a large but low quality standard library that would likely have large pieces of it deprecated in the future as better third party options became available or 3) don't ship at all. Neither (2) nor (3) would be good for users.
Now we could reverse course at this point and start bringing more into the standard library. I personally don't see that happening because our current strategy is working pretty well (bloviating HN commenters not withstanding). But sure, it could happen. You may be bloviating, but as I already acknowledged, having a big standard library definitely has its own benefits. You're right about that. Being able to trust one (or fewer) entities is a worthwhile proposition. But at this point of time, if that's what you need, then Rust isn't a good fit. I said this before too, and I don't know why you're still giving me shit about it. Why can't we be two reasonable people that accept reality and understand trade offs? "Oh yeah, that makes sense. I'll check back on Rust in a couple years then" would be a great reply. But no, instead I get speculation, rehashing previous points, more complaints and snide back-handed quips. I don't know why. Maybe you just needed an outlet to rant. Well, I'm not your personal punching bag, buddy. Back off.
I don't though. The perceived benefits of a small standard library exist only in circumstances that then cause the language ecosystem to fail to meet my requirements. These are also the requirements of many similar people in similar shoes, and also include the requirements of specialist usage such as avionics and the like.
The advantage of a small standard library is that it keeps the workload for the language designers manageable when they don't have the manpower to keep a large library properly maintained. The failures of Python's batteries included was IMHO caused by the Python team not having corporate backing and proper funding, not an inherent issue with a large std lib per se.
Rust is a low-investment language like Python: they're not investing sufficiently on the "left hand side" of the transaction. The advantage of a lean std lib is only to them, a small number of people. This is not an advantage to me, the consumer of the language.
Now, I get it, Rust was born out of Mozilla, and they're not Apple or Microsoft or Google. But that's the problem. They need to be picked up by a mega corp like, say, Amazon's AWS team to get the funding they need to do things properly.
> Last time I checked, both Java and C# have rich open source ecosystems.
They didn't for the first decade or two of their existence, and they both owe their large, cohesive standard libraries to that era.
I lament the open sourcing of the .NET framework, because the quality and cohesiveness has plummeted. There are glaring inconsistencies and bugs being thrown over the fence that would have never have made it past the kind of formal code review that occurs at only at corporations.
> This kind of thing happens regardless of who builds the libraries.
That's just not true. If a central, organised, well-funded body writes the standard library, then there is a consistency and cohesion that can never be achieved with an open source community. This is literally the Cathedral vs The Bazaar.
If I use System.Data.SqlClient then I can be confident that it will use System.Xml to return XML fields stored in a database. It'll never use BobsXmlLib or something random like that. That's the benefit to me of an architecture versus an evolution.
> Technology like Rust doesn't have to be All Things to All People at All Times.
Right now, it's not much to not many people. Its popularity is growing, sure, but it has enormous gaps that normally would be filled by the core language team. Some gaps might be filled by the community, but it's going to take a long, long time. These gaps stop many people using the language for production development.
I'm not making up that XML library scenario as some sort of exercise. This is a real problem that I have, in Rust, right now. I wanted to translate a pure C# XLSX parser I write for PowerShell into a Rust library and tool vaguely like "xsv". Something fun to do while on the coronavirus break.
I got bogged down just trying to find an XML library that can handle OOXML in a standards compliant fashion, and is popular enough to be maintained going forward, and is consumable downstream.
In C# this was trivial, even using the API that dates back to the v1.1 days. It would have been trivial in Java and C++ as well. In Rust... ugh. I'll revisit this next year, see if the XML crates have grown some features, performance, and stabilised a bit.
When step #1 is to ponder over comparison tables like this where the only full-featured crate is written in C, not Rust, I lose interest, and this is for something that's just a hobby: https://github.com/RazrFalcon/roxmltree#alternatives
PS: I see comments in crates like this all the time: "vkxml has been made for use with serde-xml-rs and, because of some quirky attributes required by serde-xml-rs, most likely will not work with any other serde xml parser." From: https://crates.io/crates/vkxml