4 ms·

> Even if I were to pick one that works now, who's to know that it wasn't written by some university student only to be dropped on the floor and become unmainta

> Even if I were to pick one that works now, who's to know that it wasn't written by some university student only to be dropped on the floor and become unmaintained when he gets a Real Job? You do the same thing you would do in any language where you depend on third party code: you do your due diligence. If no XML library meets your needs, then write your own. If that's not an option, then the Rust ecosystem isn't ready for your use case. Pretty simple. But it's ready for a lot of other use cases.

jiggawatts 7y ago
> you do your due diligence Why do I have to though? This is my point, and I know it sounds absurd, but think of it in terms of a business deal, or a product, or any "transaction". If you have two "individual entities" making a roughly equal transaction, such as a business merger, then I would agree: if one of the two parties is concerned with something, it's up to them to do their own due diligence. But if you have a 1-to-many deal going on, this then becomes unbalanced. Imagine the "1" is Visa, or Mastercard, and the many are their millions of credit card users. Imagine for a second Visa or MC saying: "It's up to the credit card holder to verify the cryptographic security of any POS devices, as well as the security of the merchant's banking IT system." That's insane, right? It's an extreme example, but it's the same concept as a language's standard library. Not every developer is in a position to evaluate the quality of a bazillion crates, their transitive dependencies, and all possible future interactions between them. If some developer starts using "xml-rs" or whatever, and 3 years later the diesel crate uses "rust-xml", then he's in for a rewrite through no fault of his own. There is literally nothing he could have done to protect himself from this eventuality. Now take this a step further. If I'm a consumer of "some developer's" app, which I run on my PC, how do I as an end-user have any confidence at all that it's using secure, maintained crates? What if I use multiple rust apps? Do I have to check every one, every month, and all their crates, and all their dependencies? With something like .NET or Java, even in a sysadmin role, I can be reasonably confident that a) it's a secure framework, b) all parts of it, c) I can patch it myself it isn't, d) and I only have to check one framework for many apps. This is like the most fundamental theory of the efficiency of transactions. M:N is inefficient, M:1:N is vastly more efficient.[1] That's why we have Uber, and governments, and Ebay, and Amazon. That's why we have banks. Because instead of standing on a city street corner asking random people for loans, there are institutions that take responsibility of verification for all parties and provides a guarantee of future safety. With languages like Java or C# I have to trust only Oracle or Microsoft. Literally just two evaluations, and I'm done. I pass on Oracle and accept the risk of Microsoft, and then get on with my programming task. Easy as pie. Languages like Rust and JavaScript are passing the buck. They're the BitCoins of banking, and about as popular or effective. For every transaction it's "you have to do your own research", but that's literally impossible for most users, so they get their wallets drained. Ooops. They should have known better, right? Or they should have just used a bank. [1] Consider that for popular languages, the ratios of the language designers : programmers : users is roughly 100:100K:5B, or 1:1K:50K, give or take an order of magnitude depending on the language. The "1" on the left passing the buck to the "1K" in the middle is one thousand times less efficient than having that work being done on the left. So every time I hear something like "Rust shouldn't include X, use a crate", it makes me grind my teeth a little.
- burntsushi 7y ago
  You've spent a lot of words ranting, but you're not telling me anything I don't know. I specifically did not engage with most of your rant in your initial comment because it seemed like you weren't interested in discussing trade offs. It seems like you still aren't. For example, I don't see anywhere in your comments where you acknowledge the benefits of a small standard library. Instead, all you do is lament the costs. Which is fair, and is why I answered your question matter-of-factly. > If some developer starts using "xml-rs" or whatever, and 3 years later the diesel crate uses "rust-xml", then he's in for a rewrite through no fault of his own. There is literally nothing he could have done to protect himself from this eventuality. This kind of thing happens regardless of who builds the libraries. > With languages like Java or C# I have to trust only Oracle or Microsoft. Literally just two evaluations, and I'm done. I pass on Oracle and accept the risk of Microsoft, and then get on with my programming task. Easy as pie. Last time I checked, both Java and C# have rich open source ecosystems. So yeah, if you don't use anything from that ecosystem other than what is developed by Oracle or Microsoft themselves, then sure, you'll do a lot less due diligence there. You don't really need to write hundreds of words to make that point. If that's what's important to you, then sure, there's a lot of stuff in the open source ecosystem (including probably Rust, depending on what you're doing) that you just won't be able to take advantage of. Which is fine, not everyone has the same risk profile. Technology like Rust doesn't have to be All Things to All People at All Times. In order to hit your use case, it probably needs a company or an established/respected organization to start taking responsibility for maintaining a lot of code. I don't see that happening any time soon, but it's not like it's fundamentally impossible for it to happen. I think it's more likely that others will figure out how to adapt their risk profiles, personally. But that's just speculation.
  - jiggawatts 7y ago
    > 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 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 https://crates.io/crates/vkxml

jiggawatts 7y ago

> you do your due diligence Why do I have to though? This is my point, and I know it sounds absurd, but think of it in terms of a business deal, or a product, or any "transaction". If you have two "individual entities" making a roughly equal transaction, such as a business merger, then I would agree: if one of the two parties is concerned with something, it's up to them to do their own due diligence. But if you have a 1-to-many deal going on, this then becomes unbalanced. Imagine the "1" is Visa, or Mastercard, and the many are their millions of credit card users. Imagine for a second Visa or MC saying: "It's up to the credit card holder to verify the cryptographic security of any POS devices, as well as the security of the merchant's banking IT system." That's insane, right? It's an extreme example, but it's the same concept as a language's standard library. Not every developer is in a position to evaluate the quality of a bazillion crates, their transitive dependencies, and all possible future interactions between them. If some developer starts using "xml-rs" or whatever, and 3 years later the diesel crate uses "rust-xml", then he's in for a rewrite through no fault of his own. There is literally nothing he could have done to protect himself from this eventuality. Now take this a step further. If I'm a consumer of "some developer's" app, which I run on my PC, how do I as an end-user have any confidence at all that it's using secure, maintained crates? What if I use multiple rust apps? Do I have to check every one, every month, and all their crates, and all their dependencies? With something like .NET or Java, even in a sysadmin role, I can be reasonably confident that a) it's a secure framework, b) all parts of it, c) I can patch it myself it isn't, d) and I only have to check one framework for many apps. This is like the most fundamental theory of the efficiency of transactions. M:N is inefficient, M:1:N is vastly more efficient.[1] That's why we have Uber, and governments, and Ebay, and Amazon. That's why we have banks. Because instead of standing on a city street corner asking random people for loans, there are institutions that take responsibility of verification for all parties and provides a guarantee of future safety. With languages like Java or C# I have to trust only Oracle or Microsoft. Literally just two evaluations, and I'm done. I pass on Oracle and accept the risk of Microsoft, and then get on with my programming task. Easy as pie. Languages like Rust and JavaScript are passing the buck. They're the BitCoins of banking, and about as popular or effective. For every transaction it's "you have to do your own research", but that's literally impossible for most users, so they get their wallets drained. Ooops. They should have known better, right? Or they should have just used a bank. [1] Consider that for popular languages, the ratios of the language designers : programmers : users is roughly 100:100K:5B, or 1:1K:50K, give or take an order of magnitude depending on the language. The "1" on the left passing the buck to the "1K" in the middle is one thousand times less efficient than having that work being done on the left. So every time I hear something like "Rust shouldn't include X, use a crate", it makes me grind my teeth a little.

burntsushi 7y ago
You've spent a lot of words ranting, but you're not telling me anything I don't know. I specifically did not engage with most of your rant in your initial comment because it seemed like you weren't interested in discussing trade offs. It seems like you still aren't. For example, I don't see anywhere in your comments where you acknowledge the benefits of a small standard library. Instead, all you do is lament the costs. Which is fair, and is why I answered your question matter-of-factly. > If some developer starts using "xml-rs" or whatever, and 3 years later the diesel crate uses "rust-xml", then he's in for a rewrite through no fault of his own. There is literally nothing he could have done to protect himself from this eventuality. This kind of thing happens regardless of who builds the libraries. > With languages like Java or C# I have to trust only Oracle or Microsoft. Literally just two evaluations, and I'm done. I pass on Oracle and accept the risk of Microsoft, and then get on with my programming task. Easy as pie. Last time I checked, both Java and C# have rich open source ecosystems. So yeah, if you don't use anything from that ecosystem other than what is developed by Oracle or Microsoft themselves, then sure, you'll do a lot less due diligence there. You don't really need to write hundreds of words to make that point. If that's what's important to you, then sure, there's a lot of stuff in the open source ecosystem (including probably Rust, depending on what you're doing) that you just won't be able to take advantage of. Which is fine, not everyone has the same risk profile. Technology like Rust doesn't have to be All Things to All People at All Times. In order to hit your use case, it probably needs a company or an established/respected organization to start taking responsibility for maintaining a lot of code. I don't see that happening any time soon, but it's not like it's fundamentally impossible for it to happen. I think it's more likely that others will figure out how to adapt their risk profiles, personally. But that's just speculation.
- jiggawatts 7y ago
  > 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 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 https://crates.io/crates/vkxml