4 ms·
> Many call for adding more to the rust standard library much like Go This is the way.
by demarq 1y ago
> Many call for adding more to the rust standard library much like Go
This is the way.
- dralley 1y agoThere should be a second stdlib with relaxed stability guarantees. Don't fill the normal stdlib full of cruft that can never be changed again.
- demarq 1y agoYeah, I agree. Something like the Boost lib for C++
- jerf 1y agoA strong advantage of that approach is that you don't need to be the core Rust team to do it. Anyone who wants to do this can just start doing it now.
- shepmaster 1y agoI agree. Unfortunately, I think that a lot of the people who ask for a bigger standard library really just want (a) someone else to do the work (b) someone they can trust. The people working on Rust are a finite (probably overextended!) set of people and you can't just add more work to their plate. "Just" making the standard library bigger is probably a non-starter. I think it'd be great if some group of people took up the very hard work to curate a set of crates that everyone would use and provide a nice façade to them, completely outside of the Rust team umbrella. Then people can start using this Katamari crate to prove out the usefulness of it. However, many people wouldn't use it. I wouldn't because I simply don't care and am happy adding my dependencies one-by-one with minimal feature sets. Others wouldn't because it doesn't have the mystical blessing/seal-of-approval of the Rust team.
- demarq 1y agolets put a price on it
- imtringued 1y agoThis is only an advantage if the core Rust team is uncooperative, which is sad rather than something to be happy about.
- jerf 1y agoThe "Rust core team" should be working on the "Rust core", not every little thing that someone somewhere thinks should go in a standard library. It is part of the job of a "core team" to say "no". A lot. Like, a lot a lot a lot. Browse through any programming language that has an open issue tracker for all the closed proposals sometime. Individually, perhaps a whole bunch of good ideas. The union of them? Not so much.
- wofo 1y agoActually, a proposal for exactly this was published yesterday: https://github.com/rust-lang/rfcs/pull/3810 https://github.com/rust-lang/rfcs/pull/3810 It's unfortunate that the response so far hasn't been very positive
- tadfisher 1y agoThat proposal is not exactly this; that seems to propose a "blessed crates" namespace which includes popular open-source libraries. I read this proposal as a Python-style batteries-included stdlib.
- wofo 1y agoWhat the OP proposes is not exactly a bigger stdlib, because they mention it should have "relaxed stability guarantees". Or is python allowed to change their stdlib in backwards-incompatible ways?
- hmry 1y agoYeah, they do so regularly. Every version removes several old stdlib features (after the last version in which they were not deprecated goes EOL)
- zahlman 1y agoIt does happen - after a deprecation period, usually small changes, but frequently (i.e. in every minor version there will surely be someone directly affected). More recently there were entire swaths of modules removed - still a conservative change, because we're talking mainly about support for obscure file formats and protocols that hardly anyone has used this century (see https://peps.python.org/pep-0594/ https://peps.python.org/pep-0594/ for details - I may be exaggerating, but not by a lot). Historically this process has been mostly informal; going forward they're trying to make sure that things get removed at a specific point after their deprecation. Python has also now adopted an annual release cadence; the combination of that with the deprecation policy effectively makes their versioning into a pseudo-calver.
- deleted 1y ago[deleted]
- zanecodes 1y agoThe non-standard library, if you will.
- infogulch 1y agoThis is obviously the best solution for Rust. A 'metalibrary' library type would add a lot of value to the ecosystem as a nexus: - All included crates can be tested for inter-compatibility - Release all included crates under a single version, simplifying upgrades - Sample projects as living documentation to demo integrations and upgrades - Breaking changes can be held until all affected crates are fixed, then bump all at once - An achievable, valuable, local goal for code review / crev coverage metrics There could be general "everything and the kitchen sink" metalibraries, metalibraries targeted at particular domains or industries, metalibraries with different standards for stability or code review, etc. It might even be valuable enough to sell support and consulting...
- Alupis 1y agoSo we reinvent Java's bloated SDK again, with all of the "javax" packages. What's old is new?
- izacus 1y agoThere's a reason why "Java's bloated SDK" is the most popular way of writing critical software in the world right now. Perhaps because it's a good idea.
- int_19h 1y agoWell, it turned out that the alternative is even worse, so... let's chalk it down to learning experience.
- Alupis 1y agoI'm outside of the Rust community, so my two cents are worthless - but in this thread it seems a lot of people are actually wanting a defacto app framework, not necessarily a bloated "kitchen sink" style stdlib. The stdlib probably should remain simple, in my opinion. The complexity should be optional.
- int_19h 1y agoNo, we specifically want stdlib and not an app framework. The problem with third party frameworks is that by definition (of being third party) there's no single standard one to use, so libraries use different ones, and then you end up with a mess of dependencies, or else multiple incompatible ecosystems, each duplicating the same functionality around a different framework. The beauty of stdlib is that it's guaranteed to be there, meaning that any library can use it as needed. It also improves interop between libraries because the same concepts are represented by the same standard types. And even when parts of stdlib are optional - which by necessity they must be for any "batteries included" stdlib because e.g. embedded is a thing - it's still beneficial to library authors because they know that, for any given feature, all supported platforms that do have it have stdlib expose it in the same way.
- deleted 1y ago[deleted]
- SkiFire13 1y agoThe issue with that is how to get everyone to agree on how that would work, e.g. what the criteria for this extension would be, what's the policy for future changes, who will maintain all of this, etc etc.
- echelon 1y agoNo way. I'd much prefer we have a constellation of core companion libraries like Google's Guava. We do not need to saddle Rust with garbage that will feel dated like Python's standard library. Cargo does the job just fine. We just need some high quality optional batteries. Embedded projects are unlikely to need standard library bloat. No_std should be top of mind for everyone. Something that might make additional libraries feel more first class: if cargo finally got namespaces and if the Rust project took on "@rust/" as the org name to launch officially sanctioned and maintained packages.
- pjmlp 1y agoPython's garbage works everywhere there is a full CPython implementation, I see that as an advantage.
- echelon 1y agoI develop for Linux, Mac, and Windows. Multiple architectures and OSes. I rarely see platform issues with Rust. It's typically only stuff at the edge, like CUDA libraries, that trip up cross-platform builds. Rust, as a systems language, is quite good at working on a variety of systems.
- pjmlp 1y agoStarts already that Rust won't support architectures not available on LLVM, but on GCC, otherwise having a Rust frontend project for GCC wouldn't be a thing. And the systems language remark, I am still looking forward when sorting ABI issues for binary libraries is finally something that doesn't need to go through solutions designed for C and C++.
- dezgeg 1y agoWhat architectures that are missing from LLVM are commercially relevant today and not on well-earned retirement?
- bigstrat2003 1y ago
- pjmlp 1y agoIndeed, yes sometimes this brings cruft into the mix. However I rather have cruft that works everywhere the toolchain is fully implemented, instead of playing whack-a-mole with third party libraries when only some platforms are supported.
- bigstrat2003 1y agoI think that the bare bones stdlib is a huge mistake in Rust. I would love to see that rectified. Unfortunately, approximately 5 other people share that view. The Rust community as a whole is very opposed to adding functionality to std.
- simonask 1y agoI mean, the case against it is pretty strong. Many languages with maximalist standard libraries have tons of vestigial code that nobody uses because the ecosystem found better solutions. Yet that code has to be maintained in perpetuity. The C++ standard library even has this problem for something as basic as formatting (iostreams), and now it has two solutions for the same problem.
- morganherlocker 1y agoNow instead of seeing millions of lines of inscrutable code in your program bloating binary sizes, you can see it in every program (that doesn't disable stdlib).
- lantastic 1y agoIn every program that uses a particular feature from the stdlib. Given the same feature, I tend to trust stdlib more than some rando project. And if you don't trust the stdlib, why would you trust the compiler?
- constantcrying 1y agoThat is a serious burden on the maintainers, it creates all kinds of different problems, especially if the functionality of the libraries assumes a certain execution environment. Rust doesn't just target x86 desktops.
- kgeist 1y agoGo doesn't just target x86 desktops either
- constantcrying 1y agoAnd? Not every project had the same amount of resources. There is a tradeoff here. Having a large, but badly maintained, standard library with varying platform support is worse than having a smaller, but well maintained, one.
- kgeist 1y agoIf you look at the numbers, Golang has 2000+ contributors, while Rust has 5000+ Golang's core dev team is something like 30 people. So Rust does have the resources.
- constantcrying 1y agoThe amount of contributors is a totally meaningless metric. 1. Not every contributor contributes equally. Some contributors work full time on the project, some work a few hours a month. 2. The amount of contributors says nothing about what resources are actually required. Rust is, no doubt, a more complex language than go and is also evolving faster. 3. The amount of contributors says nothing about the amount of contributors maintaining very niche parts of the ecosystem.
- deleted 1y ago[deleted]