@kornel: do you mean there's a bug in the current version of std which won't be ever fixed ?
@yandros: I never meant to save one line in the Cargo.toml. It's the fact to shift essential features like regexes or rand to external crates I'm challenging.
They are not essential to everyone, and they aren't needed to build a vocabulary like Vec<_> is. They are also massively complicated, so having them in an external crate means that it is fine if there is mistake, because we can fix it. If we have a mistake in std, we may not be able to fix it. This is much worse than not having it in std.
@RustyYato This is your opinion, not mine. I think we can stop here this debate 
Bypassing the borrow checker for things like this is trivial; just use slice::as_ptr to get a raw pointer and do the sum the way you would do it in C. No need for external crates or Arc. You should, of course, be careful that you understand why it's safe to do so, though. You essentially need to manually enforce that the threads are scoped, or at least that their access to the shared memory is scoped.
Avoiding unsafe is admirable, but often overly complicated.
That is one reason why Rust is not a âbatteries includedâ language, because itâs almost impossible to replace defective batteries if they are in
std.
@dandyvica you seem to know about python, so I'd assume you know or at least have heard how much pain, work, and frustration upgrading from python 2 to python 3 has been. Fixing / replacing broken batteries in the Python standard library is not the main reason for that, but it is definitely partially responsible for it. You also seem to be familiar with D, which ran into this exact same problem and the fix wasn't easy. The D language had two incompatible standard libraries for a while, and this almost killed the language.
So I think everybody agrees with the part of your argument that argues that the current solution has downsides: discovering which crates you can rely on for important projects and how dependable these crates are isn't an easy thing to do.
On the other hand, having a "batteries included" standard library like Python and D, without a solution to the problem that split the Python ecosystem for a decade and almost killed the D programming language would be an irresponsible thing to do.
A "feature" of the current Rust solution is that, because it is so minimal, if someone were to discover a solution for this problem without downsides, chances are that we can just use it without breaking backward compatibility.
I am not aware of any good solutions to this problems - all the ones I've heard had downsides, but that's certainly an interesting topic. I think most of the work in the Rust side has gone into improving crate discoverability on crates.io, displaying statistics there about usage, maintenance, etc. so that project managers can evaluate how well maintained a crate is, how many stakeholders it has, etc., having documentation for all crates available in docs.rs, so that you can easily inspect it when assessing a crate, etc. There is certainly more that could be done about this, and people are working on that.
Thanks for your analysis. I agree with most of your arguments. As for Python 3 migration, it didn't prevent this language to be in the top 5.
I'm ok with your conclusion. Will it be enough for Rust to be used in the industry ? Only future will tell.
My fear is that Kotlin native, although still in beta and GC oriented, will take over Rust for non system programming projects.
That class of competition is good for all parties. Rust has led to improvements in Ada/SPARK, and there are Ada features that are desirable for Rust. Rust avoids almost all exposure to malware by construction (largely via Lifetimes and the much-maligned Borrow Checker). In the longer term, Rust will come out ahead of those other languages that do not deliver similar malware-avoidance by construction.
The problem is not in stdlib impl, but the api of std::sync::mpsc is far from ideal. We discovered it long after the v1.0 freeze, so we should maintain this api forever though we know it's bad. Crossbeam does not have this such strong back compat guarantee, so it can replace discovered-to-be-bad api by bumping major version.
@dandyvica
I haven't needed to use regex in my programs for several years. It isn't something I want in a std.
I have a problem with the the way you're thinking about dependencies. It's true that depending on libA which depends on libB creates a transitive dependency. This problem isn't solved by moving libA to std. libA depends on libB for a good reason. Unless libA is badly designed and has a coupling to other libs for no good reason. Moving them to std, you would have to also move libB into the std and everything it depends on.
I don't mean this in a snarky way, but std isn't a magical place of good code. It is at best a curated list of dependencies maintained by people who ought to just focus on the language. Otherwise, you start to get weird things like an independent std committee. And with each new addition to the std, the overhead increases and each independent component can no longer get any reasonable amount of attention. Worse, now that we have all these libs in the std, they each need tight coupling to each other because we can't have a std::regex that doesn't work with a std::string. Cohesion starts to drain from each component in the list and no one can be bothered to fix anything or change anything and rigidity sets in.
I agree with you in that we should try to do better here, but I just want to point out that many languages in Rust's space, like C or C++, have a tiny standard library, and they are widely-used in industry. A team / project might decide to use something other than Rust for a variety of reasons, and some teams might consider a lean standard library as a downside in their evaluation, but I doubt that any team will reject Rust exclusively due to this specific downside.
While there are many organization with complex bureaucratic processes about the third-party libraries that they allow, there are middle grounds between "not using any external library" and "using any library from crates.io". For example, some project like stdx bundle groups of crates together, such that an organization only has to approve stdx and its dependencies, and then you can use those.
If your organization is super averse to third party dependencies, then you can't use dependencies in C, C++, Javascript/Node.js, Python, ... either. If you are considering Rust, chances are that your alternatives are only C or C++, in which case a lean standard library doesn't really penalize Rust, since those languages standard libraries are tiny as well. If you are considering, e.g., a language with a big library like Python vs Rust, then many other tradeoffs apply. If Python suffices for a commercial project, choosing Rust instead is going to be hard to justify, but I doubt that the choice will come down to who has the largest standard library. Python without PIP is super-crippled, as in, sure, the Python standard library is much larger, but many parts of it are deprecated / discouraged to use, and the recommended packages are in PIP. So if your constraint is "no third-party libraries / std library only", then pretty much all languages are going to be significantly penalized.
In practice, chances are that your company allows you to use certain third-party libraries independently of which language you decide to use, and that these libraries have to go through an approval process. If this is the case, then Rust with cargo is already better-off than many of the alternatives where managing dependencies, their licenses, vendoring them, using alternative registries, etc. is often a pain.
@seph I have a problem with the way you think these dependencies too. I'm doubtful an industry IT manager will ever bet on Rust if this dependency complexity isn't ironed out. And regex is a basic feature and rand even a more basic one to the point it's in the C language.
@gnzlbg my company will not use Rust anytime soon. We're Java only and we're barely dabbling in NodeJS. We aren't into that market where Rust is needed. Rust is probably only known by a tiny part of my colleagues.
As I said we can debate for weeks using pros and cons. My opinion is crafted by several decades in the IT industry for large companies. I know how managers react, and what they ready to commit for.
There are tons of companies using Rust. I work at Cloudflare and I can tell you our "IT managers" are betting strongly on it. Use of crates-io requires different considerations, but overall it's a positive.
Thanks to the lean standard library and back-compat guarantee, we can upgrade Rust every 6 weeks without fear. For developers, that's so much nicer than "fat-std" environments like Java and PHP, which require major consideration before upgrades, and therefore deployment at large companies lags months or even years behind the latest release.
@kornel "Tons" is a little bit exaggerated. If you use "tons" for Rust, what will use for Java? Yotta-tons?
Sorry but I'm now tired of this thread and will stop responding on this particular subject.
If you know golang, it is probably a good example of this. Do you prefer to use the 3rd party fasthttp library which is 10x faster or use the http library that is baked into go but 10x slower?
As well, having the stuff it library is good for boosting the ecosystem quality by having more competition among themselves, though this might be bad for discovery.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.