7 ms·

I think we should be taking a more “batteries included” approach to language and library design. The entire reason we’re in this mess is because we’ve decided i

I think we should be taking a more “batteries included” approach to language and library design. The entire reason we’re in this mess is because we’ve decided it’s ok or maybe even preferable if stdlibs are rail thin, rendering base languages near-unusable. I can very easily build a highly functional, pleasant to use Apple platform app with 5 or fewer top level dependencies. In many cases, I reach for between 0-2 total. There’s no reason why this can’t be replicated elsewhere. The key is to make the programming language reasonably robust with at least 80% of common non-UI dev needs built in and put the remaining 20% and UI bits into a small family of well-supported, community-embraced, preferably first party libraries. That would make it unnecessary to pull in foreign dependencies in the overwhelming majority of projects. What few do get pulled in becomes lightweight, easily verifiable syntactic sugar or libraries with purposes too niche to be worth targeting. Of course this approach can go wrong too. You could easily end up with a monster like Boost, but that comes down to project administration keeping creep under control and proper modular design.

yoyohello13 2mo ago
This was actually the main thing that put me off of Rust. I get the argument for a small std lib. I just also don’t agree it’s worth it. Go seems to handle having a batteries included standard lib just fine.
- 0cf8612b2e1e 2mo ago
  On the other hand, there are some bad Go standard libraries that are frozen in time.
  - rirze 2mo ago
    which, as painful as it may be, is ok. Better to have a safe functional stdlib library than a exposed external crate (which then asks the question; what's the replacement...)
    - lesuorac 2mo ago
      Those aren't the only two choices. We also have the classic example of PHP with numerous not safe stdlib ways to use mysql. To me the answer is still to vendor your dependencies and don't be on the bleeding edge of updates unless you're willing to invest the time into validating them.
      - kergonath 2mo ago
        > We also have the classic example of PHP with numerous not safe stdlib ways to use mysql. I think it goes without saying that emulating PHP is rarely a good decision.
        VorpalWay 2mo ago
        Don't forget C++ where large parts of the standard library are unusable (regex is slow and unfixable) or soft deprecated (dont use iostreams for formatting, use std::format, etc). No, I prefer what rust is doing. It suits a system programming language. Which is what Rust is.
        pjmlp 2mo ago
        Regex does the job for most business software, iostreams is alright, using them since 1993, std::format is cool provided one has control over their compiler version,...
        VorpalWay 2mo ago
        Regex is absolutely not suitable for most use cases that I have come across. Iostreams formatting is awful, especially if you care about internationalization (which is very common). Not sure what the issue with std::format would be here, you would have to elaborate. Obviously you need to specify a minimum version to have support for it at all.
        pjmlp 2mo ago
  - bigstrat2003 2mo ago
    Which isn't actually a problem. You can ignore the bad standard library and use something different.
  - pjmlp 2mo ago
    Yeah, but I will take a not great library that works everywhere the compiler does, than be at the whims of which platforms are supported by 3rd party libraries. I can use most of the clunky Python, Java, .NET and if it must be, Go, standard libraries, than hunting down for dependencies with platform tier support and such.
    - pie_flavor 2mo ago
      Platform support is a non-issue for every library being discussed. This is an array construction macro, it has nothing to do with what operating system you're running on.
      - pjmlp 2mo ago
        Just because some trees have a specific trait, it doesn't mean the whole forest is the same.
        imtringued 2mo ago
        Your argument only works for no_std crates, but the std exists and allows the vast majority of crates to be cross platform out of the box.
        pjmlp 2mo ago
        I bet there are plenty of them that don't work on IBM i, while Java does fine there. Just to quote a possible scenario among others.
    - dwattttt 2mo ago
      Add more and more to a standard library, and you're going to start losing your "works everywhere".
      - pjmlp 2mo ago
        Naturally there is a balance, still I think Java, .NET, Python, Go, Smalltalk, manage quite well, while having subsets to slim down when needed for specific deployment scenarios like embedded devices.
- afdbcreid 2mo ago
  People confuse what they want. They do not want a big stdlib. The downsides are real (the stdlib cannot make breaking changes), and there are no upsides (except, maybe, for faster compilation, since std comes precompiled). They want more official crates (e.g. `regex` and `libc` are official crates, maintained by the Rust project). And the Rust project does not oppose to that, it just doesn't have the funding.
  - Pannoniae 2mo ago
    Who said a standard library can't make breaking changes? That used to be a norm some time ago. There are upsides, your program is smaller, better security because a random kid can't pwn your deps, quality and interoperability. What's not to love?
    - afdbcreid 2mo ago
      > Who said a standard library can't make breaking changes? The std making a breaking change is the language making a breaking change. Most mainstream languages guarantee stability, certainly Rust. > your program is smaller How so? It doesn't matter if the code is in std or a crate. > better security because a random kid can't pwn your deps, quality and interoperability That's exactly what I said: you don't need bigger std, you just need more official crates.
      - Pannoniae 2mo ago
        >Most mainstream languages guarantee stability, certainly Rust. That's their mistake, right there... When you're upgrading software, you presumably want a better version. You can't have something better without changing it. It's a logical contradiction. >It doesn't matter if the code is in std or a crate. It very much does because you don't need 95% of the random stuff in the crates. Even for something like rand, you need an xorshift and that's roughly it. 25 lines of code, sorted. You can even write it as a copypaste "dependency" without much fuss in practically any language. That, versus importing a whole rand library with lots of different algorithms, deps on crypto, tests, OS random-based seeding, customisability, etc. >you just need more official crates I guess that's one solution but it would probably just be a better idea to split std in two SLAs, one is guaranteed for core stuff i.e. the status quo, one is YMMV.
leecommamichael 2mo ago
The Odin programming language does this! It has also decided not to provide a package manager.
- Ygg2 2mo ago
  Spoiler alert! JavaScript has no language provided package manager. If Odin gets moderately successful someone will probably reinvent it.
  - leecommamichael 2mo ago
    NPM came along in 2010, Javascript was huge before that. It was only when people wanted a common approach to shipping both in browser and "native" that this glitch happened. I believe a standard library and "batteries" would have abated it entirely or resulted in a slightly less-bad situation. I do think Cargo is a slightly less-bad situation in many ways, and that it can be done better.
    - Ygg2 2mo ago
      Sure. Maybe threshold is bit higher than moderately. But unless your language tries to sabotage itself by making code artifacts uncomposable (a la C/C++ where best way to compose libraries is through shell commands) some package manager will be inevitable. Batteries also don't help if dependencies don't replace them. Arrayref functionality has been part of Rust std lib for a while now.
    - josephg 2mo ago
      > It was only when people wanted a common approach to shipping both in browser and "native" that this glitch happened. Nah. Npm was invented because node had its node_modules directory. But it was tricky to find and download modules you wanted to use. Until npm, you had to add libraries to node_modules by hand. And check them in to git or something. And keep them up to date somehow. Npm added a searchable index and a tool to automatically install all your modules. Npm was only bundled alongside Nodejs many years later. Bundling was separate. I can’t remember if browserify predated npm or not. But it was a wild idea at the time to make node modules build for the browser too. Browserify - and later webpack and friends - work with or without npm.
mightyham 2mo ago
Rust has a sizable and well featured standard library at this point. I think it would be absurd to claim that the base language is "near-unusable" if you are using it for system programming, which is its intended use case. Huge standard libraries make sense for Java, Go, Apple platform etc. because they are developed by giant enterprises that can manage the overhead. Thinner modular systems are a more natural fit for open source development.
- cosmic_cheese 2mo ago
  It’s being used for a wide variety of other purposes however, and so perhaps it’s time to adapt to that reality. While overhead is a real concern, I think it’s often blown out of proportion. Once a language achieves a certain baseline of stability and isn’t in constant flux and the standard library matures, changes become infrequent and maintenance load is low. The work is heavily front-loaded.
  - VorpalWay 2mo ago
    Not at all true, look at the large parts of Python's standard library that are effectively unusable or irrelevant. And they even allow some breaking changes over time (unlike Rust). This is especially true when it comes to anything related to internet protocols or file formats, but there are other modules that have far better replacements on PyPi too (re vs regex for example).
  - kelnos 2mo ago
    > It’s being used for a wide variety of other purposes however, and so perhaps it’s time to adapt to that reality. Who is going to pay for the resources to make that happen, though? The reality is that the bulk of Rust contributions come from a fairly small group of people, many of whom are volunteers. Some are Mozilla employees, and they don't have all the funding in the world. Yes, it would be great if every open source project could magically be able to meet the needs of all its users, but that just isn't how it works.
- josephg 2mo ago
  True. And the rust standard library is pretty good. But I really wish we had a good, fast, small futures executor in std. And accompanying async variants of File and Socket and so on. Async rust is a jungle of weird compatibility questions. People treat async runtimes like sports teams. (I know I do). I wish it were more like Nodejs where async is just built in.
segphault 2mo ago
This is spot on. I am extremely uncomfortable with the large number of transitive dependencies that end up in pretty much any non-trivial rust application. No amount of memory safety will save us if a tiny, ubiquitous library that nobody scrutinizes because it’s nested eight layers down the dependency graph gets compromised. I think Go apps tend to have better dependency hygiene because the language has a better standard library, which results in better culture around dependencies. I also think it’s frustrating that both cargo and npm totally ignore the decades of prior art from Linux distributions that have figured out good ways to improve dependency management. We’d be in better shape if there was a community curated subset of known-good dependencies that are release-managed together that the broader ecosystem could build on, sort of like Ubuntu having “main” and “universe”.
- __david__ 2mo ago
  I think Go ends up with fewer dependencies mostly because there is more friction in finding them. With rust (and npm) you just "cargo search xxx", then "cargo add xxx". Go makes you web search and poke around github looking for something. It's not onerous or anything, but just that extra step slows things down just a bit. C projects tend to have the least because it's even more annoying to add them and you have to create build commands that deal with slightly different distributions (and learn makefile+pkg-config or cmake, or autoconf). Certainly having a larger stdlib helps Go projects keep their deps down, but I don't think it's the real reason.
  - teach 2mo ago
    Actually I think this is more of a culture thing. Or maybe "is also" a culture thing. One of the core tenets of early Go was the maxim "a little copying is better than a little dependency". Probably because of this stance, they didn't even HAVE a dependency-management solution for years I strongly agree the fewer dependencies the better, on average.
    - cogman10 2mo ago
      I agree. Java has the same ability to quickly add deps, and in some case they can be sprawling, but it's still perfectly possible to develop complex apps without a lot of deps coming in. Culture has a lot to do with it.
nemothekid 2mo ago
>There’s no reason why this can’t be replicated elsewhere. The key is to make the programming language reasonably robust with at least 80% of common non-UI dev needs built in and put the remaining 20% and UI bits into a small family of well-supported, community-embraced, preferably first party libraries. The big reason is money & time. Maybe less so today if you are happy with an AI generated stdlib, but I don't think it's fair to compare Rust (built by Mozilla, who's primary product is an open source web browser) to Swift/AppKit (built by Apple, 4.6T marketcap at the time of writing). When Go was released it had an amazing stdlib, but that was because Google was funding it.
- echelon 2mo ago
  Python is batteries included, but all the batteries have corroded. Look at C++'s long in the tooth STL. You don't want to marry a language to fast aging libraries you have to support for eternity. Better libraries always naturally emerge. Rust's decision here is fine. The only thing I'd like to see is the ability to programmatically limit transitive dependency count or depth in Cargo. I'd also like crates to specify whether they limit their own deps and whether they have panick-y behavior or not.
  - smw 2mo ago
    I think maybe the right answer is to have a standardized, curated group of libraries pegged at some sort of LTS release that only backports security fixes. However, someone would need to pay for creating and maintaining this -- and then you wonder where the money would come from?
    - cogman10 2mo ago
      That or potentially fast tracking merging popular libraries into the standard library. Or at least concepts from popular libraries. Basically all the "most downloaded" crates on the Crates.io front page should be candidates for merging into the standard library. https://crates.io/ https://crates.io/
      - 2mo ago
TZubiri 2mo ago
>I think we should be taking a more “batteries included” approach https://www.youtube.com/watch?v=GZOuz-SG7-g https://www.youtube.com/watch?v=GZOuz-SG7-g Funny how you skipped "I should build my own batteries" and when straight to "increasing and centralizing the duties of your main gratis 'vendor'".
- cosmic_cheese 2mo ago
  I don't like the "bring your own" approach because unless one happens to be an absolute tour de force 10x engineer unstoppable god of a programmer (which most of us, myself included, are not), whatever you build is never going to be as well-rounded, fleshed out, and complete as something built by a larger organization, especially when it comes to UI libraries (which are monstrous projects if done right, e.g. meeting accessibility requirements). I'm happy to contribute to a larger effort but anything I can build on my own is going to be a thin, flimsy happy meal toy compared to something with the backing of a company or well organized FOSS project.
  - TZubiri 2mo ago
    I agree that building your own is hard and something that can be done by exceptional engineers, but software is famously a winner-take-all industry, even if the optimal strategy for lower percentile programmers and median programmers to import generic modules, as long as building your own results in the best product (which it does, whether importing frontend or backend modules, if you hand code something, it's going to be the optimal strategy for building a winner product. Even programmers that are median or below average probably have an incentive to aim for being exceptional, because the best value of median and below average programmers is not building median or low value software, but having a shot at building exceptional software. Also the challenge of building a generic module is much larger than building your own. A generic module needs to have flexibility for many different options and integrations, when you build your own you build just what you need and tightly integrate it with the product
    - cosmic_cheese 2mo ago
cpill 2mo ago
with LLMs it's becoming more common to just vibe up anything you need that might be missing. even if there is an available package you can pull in. the most secure option as well
rfgplk 2mo ago
> I can very easily build a highly functional, pleasant to use Apple platform app with 5 or fewer top level dependencies. In many cases, I reach for between 0-2 total. > There’s no reason why this can’t be replicated elsewhere. The key is to make the programming language reasonably robust with at least 80% of common non-UI dev needs built in and put the remaining 20% and UI bits into a small family of well-supported, community-embraced, preferably first party libraries. I wholeheartedly agree. Most standard libraries out there (when I say most I easily mean of 99% languages that I know) have pitifully tiny implementations. They at most provide for string parsing, io, a bare networking layer (that's at best a wrapper around the POSIX syscalls), threading and that's it. If you want to do anything more complex, you either have to roll it yourself or use an assortment of the "blessed libs" for any given language, that may or may not work properly, and may or may not even work well with each other. I got pissed off by this at some point so I decided to go ahead and roll my own standard lib that would actually have everything I need to.. actually develop apps. Now I know most people probably aren't going to be using it (mainly because its functional API isn't what most C++ devs want) but for me it's actually been brilliant.
fc417fc802 2mo ago
I don't see the problem with boost? Isn't that a perfect example of your well supported, community embraced option? I certainly feel much safer pulling something in from boost via the official debian repos than I do pulling a random package with npm or cargo or etc. Primarily I think the underlying concern has to do with the pathway for authoring code. When you have contributors whose submissions are gated with a rigid third party process and where that third party is the one responsible for curating the code (as opposed to the author also being the curator as well as the publisher) then you have the possibility to catch a lot of wrongdoing before it succeeds.
- cosmic_cheese 2mo ago
  > I don't see the problem with boost? There are many issues that I've seen taken up with Boost, but my personal peeve is how it can make building projects that incorporate it a pain, both because of its sheer size but also because it can sometimes be difficult to appease with its own dependencies.
  - peesem 2mo ago
    that seems unrelated to the security problem to me
lelanthran 2mo ago
> I can very easily build a highly functional, pleasant to use Apple platform app with 5 or fewer top level dependencies. In many cases, I reach for between 0-2 total. > There’s no reason why this can’t be replicated elsewhere. It is replicated elsewhere and is not limited to Apple; I can do the same using a tech stack of perhaps 2x techs and very limited (manually added) deps. I'm thinking Lazarus, which comes with most things I'd need for most apps.
VorpalWay 2mo ago
> I think we should be taking a more “batteries included” approach to language and library design. The entire reason we’re in this mess is because we’ve decided it’s ok or maybe even preferable if stdlibs are rail thin, rendering base languages near-unusable. Nobody can agree on what those common things are in a general purpose langusge though. It works for something like Go, because it is largely used for servers and command line tools from what I can tell. For Rust, well I would like to prioritise features for embedded development, someone else might want game dev features (geometry and physics stuff), yet another person wants data science things. And so on. And even if did put some of those things in std, that is stable forever. That is how C++ ended up with an unusably slow regex implementation in the standard library. And it isn't fixable. Everyone just ignores it and uses a third party library like PCRE, RE2, etc instead (depending on their specific needs). I would not expect web or GUI things in the standard library for this reason, those standards change too frequently for that to be stable forever. And even something like Python, which is known for data science and machine learning, doesn't have core libraries for those activities in the standard library. Numpy, Pandas, Scipy, Pytorch etc are all third party projects.
- ksbd-pls-finish 2mo ago
  Well I use python daily for the past 10 years and I never did data science. Data science? Everyone knows python is the language of cyber security.
- piker 2mo ago
  Maybe that’s a good place to make the cut. One Rust crate for game dev, one for data science, etc. Then their deps are pinned and monitored by the crate maintainers.
- barnabee 2mo ago
  I wrote this on another thread recently, but my line for exclusion from standard library is a library that’s any one of: - not obviously/generally useful (i.e. useless or too specific/should be a program not a library) - obviously trivial (code it yourself when you need it/compose from other primitives) - already available (open source) elsewhere by a credible team that supports and maintains it Anything else… put it in the stdlib
mattrighetti 2mo ago
> I can very easily build a highly functional, pleasant to use Apple platform app with 5 or fewer top level dependencies. In many cases, I reach for between 0-2 total. Most of the things I wrote in Rust have less than 5 dependencies. Those 5 dependencies then depend on 20 other dependencies each. Those 20 dependencies have 2-3 other dependencies. And so on…
- kibwen 2mo ago
  Counting the number of crates in the dependency graph in order to gauge exposure is a misunderstanding of how Rust works. In Rust the crate is the unit of compilation. Unlike in Javascript, the fact that a crate has dependencies on other crates does not mean the author pulled in random code written by someone else, it often just means that the author wanted to leverage crate-level compilation parallelism by splitting a large compilation unit out into several smaller ones.
wmedrano 2mo ago
Ok in theory, but I don't think it applies here. Maybe it does in a cultural way. Arrayref seems somewhat niche, but its kind of in the standard library as of Jan 2026 as std::slice::as_array https://doc.rust-lang.org/std/primitive.slice.html#method.as_array https://doc.rust-lang.org/std/primitive.slice.html#method.as...
- kibwen 2mo ago
  For the example given in the arrayref docs, I'd say you should be using std::slice::as_chunks, stabilized in 1.88: https://doc.rust-lang.org/std/primitive.slice.html#method.as_chunks https://doc.rust-lang.org/std/primitive.slice.html#method.as...
raincole 2mo ago
> There’s no reason why this can’t be replicated elsewhere. There are plenty reasons. Just not technical reasons. At the end of the day, people like to feel useful. The ecosystem that attracted communities are those ones where everyone can feel they're contributing back to the communities. That's why the most successful languages, save those backed by big companies, are filled with very small libraries. No body gets excited making C#/nuget packages.
waterTanuki 2mo ago
> I think we should be taking a more “batteries included” approach to language and library design. The entire reason we’re in this mess is because we’ve decided it’s ok or maybe even preferable if stdlibs are rail thin, rendering base languages near-unusable. Rust is one of the better languages when it comes to batteries included in it's stdlib. Even then, it's impossible to have a 100% coverage batteries included language because nearly everyone on planet earth has some different/unique use case for their code that doesn't fit a stdlib.
deepsun 2mo ago
A big selling point of Java also was a very strong built-in library, e.g. with red-black trees (TreeMap) and concurrent lock-free zero-mutex queues (ConcurrentLinkedQueue). No wonder competitive coding champions sometimes preferred Java as they don't had to spend time coding it from scratch.
FacelessJim 2mo ago
I really like the approach Julia is taking. The std libs are their own packages with their own versions. You can then build your own “standard library” by compiling a sysimage that freezes the versions (you can add third party packages as well). Practically speaking the standard library is just meant as “what’s included in the default sysimage”. This allows to have different standard libs for different use cases. Think of Linux distributions in a sense. There are already a couple of alternative “stdlibs” out there for different focuses.
chiffaa 2mo ago
> we should be taking a more “batteries included” approach to language and library design. Okay, but how do we decide which approach to a problem should be standardised? Rust's approach of "provide a minimal core to build libraries on top of" provides a fairly significant benefit - flexibility. A prominent example is async: Rust has three fairly prominent async runtimes (being Tokio for general server-side use, smol for a simple non-work-stealing approach and embassy for embedded). Which one do you make the default? Tokio is very complex and work-stealing is arguably a very bad default in terms of development complexity. smol doesn't fit some workloads because of a simpler execution model. Embassy is way lower level and much more constrained than most applications need. Standardising over one implementation instead of the current (even if still messy due to early portability woes) standardisation around traits and general async semantics would make switching runtimes more problematic, even though the general case is solved with the same approach as Python's Database access is also a complicated topic. Rust has multiple fairly popular DB libraries. The first two that come to mind are SQLx and Diesel. Both are too complex to be a part of the standard library, both required a fair bit of breaking changes, and if you wanted a raw core to build on top of - you can't really build SQLx on the type of core e.g. Go's database/sql has, you'd be basically forced to implement it all from scratch to handle the compile time type checks anyway RNG sounds simple, except there are good reasons behind both rand and fastrand existing, and behind rand not being stabilised at 1.0. DateTime handling is notoriously complicated, has multiple competing implementations (chrono, time, jiff) with various trade offs Where do you draw the line? What do you standardise and which implementation do you standardise against? I've seen golang exemplified a lot in adjacent threads, but golang's standard library both has fairly significant issues (json, no set type, very limited CLI flag parsing, UUID took until 1.28) and is standardised around a relatively specific goal (unix server usage) Dunno, I'm not entirely sold on the whole "extend the standard library" idea for a language meant to run both high level applications and embedded stuff. If anything, recommending blessed.rs more is a better way IMO
pseudony 2mo ago
You can never please everyone , and some stdlibs can age like milk (see ocaml). Having libraries allow the community to explore rather than saddling it with a bad default. See the number of http server frameworks etc. The real solution here is not for the stdlib to become a black hole, swallowing up every half-way popular library a but rather for “rustaceans” to adopt a more security-conscious approach to writing programs- C programs typically have few and well-chosen dependencies. Some languages, like Odin, completely eschew package managers because they see the very real issues stemming from writing a program with scores or hundreds of dependencies.
- a-french-anon 2mo ago
  You seem to be ignoring that most people who want off the infernal npm/cargo hamster wheel are conscious that it implies a bit of spoilt milk or moldy bread in exchange for stability and that they're fine with it. The gains are just too numerous and important to reject the few rust spots on a "good enough" stdlib. But well, the kind of people who nod a bit too much while reading https://boringtechnology.club/ https://boringtechnology.club/ aren't using Rust. They're on C99, ANSI CL, Ada, maybe Python, Perl or Tcl.

yoyohello13 2mo ago

This was actually the main thing that put me off of Rust. I get the argument for a small std lib. I just also don’t agree it’s worth it. Go seems to handle having a batteries included standard lib just fine.

0cf8612b2e1e 2mo ago
On the other hand, there are some bad Go standard libraries that are frozen in time.
- rirze 2mo ago
  which, as painful as it may be, is ok. Better to have a safe functional stdlib library than a exposed external crate (which then asks the question; what's the replacement...)
  - lesuorac 2mo ago
    Those aren't the only two choices. We also have the classic example of PHP with numerous not safe stdlib ways to use mysql. To me the answer is still to vendor your dependencies and don't be on the bleeding edge of updates unless you're willing to invest the time into validating them.
    - kergonath 2mo ago
      > We also have the classic example of PHP with numerous not safe stdlib ways to use mysql. I think it goes without saying that emulating PHP is rarely a good decision.
      - VorpalWay 2mo ago
        Don't forget C++ where large parts of the standard library are unusable (regex is slow and unfixable) or soft deprecated (dont use iostreams for formatting, use std::format, etc). No, I prefer what rust is doing. It suits a system programming language. Which is what Rust is.
        pjmlp 2mo ago
        Regex does the job for most business software, iostreams is alright, using them since 1993, std::format is cool provided one has control over their compiler version,...
        VorpalWay 2mo ago
        Regex is absolutely not suitable for most use cases that I have come across. Iostreams formatting is awful, especially if you care about internationalization (which is very common). Not sure what the issue with std::format would be here, you would have to elaborate. Obviously you need to specify a minimum version to have support for it at all.
        pjmlp 2mo ago
- bigstrat2003 2mo ago
  Which isn't actually a problem. You can ignore the bad standard library and use something different.
- pjmlp 2mo ago
  Yeah, but I will take a not great library that works everywhere the compiler does, than be at the whims of which platforms are supported by 3rd party libraries. I can use most of the clunky Python, Java, .NET and if it must be, Go, standard libraries, than hunting down for dependencies with platform tier support and such.
  - pie_flavor 2mo ago
    Platform support is a non-issue for every library being discussed. This is an array construction macro, it has nothing to do with what operating system you're running on.
    - pjmlp 2mo ago
      Just because some trees have a specific trait, it doesn't mean the whole forest is the same.
      - imtringued 2mo ago
        Your argument only works for no_std crates, but the std exists and allows the vast majority of crates to be cross platform out of the box.
        pjmlp 2mo ago
        I bet there are plenty of them that don't work on IBM i, while Java does fine there. Just to quote a possible scenario among others.
  - dwattttt 2mo ago
    Add more and more to a standard library, and you're going to start losing your "works everywhere".
    - pjmlp 2mo ago
      Naturally there is a balance, still I think Java, .NET, Python, Go, Smalltalk, manage quite well, while having subsets to slim down when needed for specific deployment scenarios like embedded devices.
afdbcreid 2mo ago
People confuse what they want. They do not want a big stdlib. The downsides are real (the stdlib cannot make breaking changes), and there are no upsides (except, maybe, for faster compilation, since std comes precompiled). They want more official crates (e.g. `regex` and `libc` are official crates, maintained by the Rust project). And the Rust project does not oppose to that, it just doesn't have the funding.
- Pannoniae 2mo ago
  Who said a standard library can't make breaking changes? That used to be a norm some time ago. There are upsides, your program is smaller, better security because a random kid can't pwn your deps, quality and interoperability. What's not to love?
  - afdbcreid 2mo ago
    > Who said a standard library can't make breaking changes? The std making a breaking change is the language making a breaking change. Most mainstream languages guarantee stability, certainly Rust. > your program is smaller How so? It doesn't matter if the code is in std or a crate. > better security because a random kid can't pwn your deps, quality and interoperability That's exactly what I said: you don't need bigger std, you just need more official crates.
    - Pannoniae 2mo ago
      >Most mainstream languages guarantee stability, certainly Rust. That's their mistake, right there... When you're upgrading software, you presumably want a better version. You can't have something better without changing it. It's a logical contradiction. >It doesn't matter if the code is in std or a crate. It very much does because you don't need 95% of the random stuff in the crates. Even for something like rand, you need an xorshift and that's roughly it. 25 lines of code, sorted. You can even write it as a copypaste "dependency" without much fuss in practically any language. That, versus importing a whole rand library with lots of different algorithms, deps on crypto, tests, OS random-based seeding, customisability, etc. >you just need more official crates I guess that's one solution but it would probably just be a better idea to split std in two SLAs, one is guaranteed for core stuff i.e. the status quo, one is YMMV.

leecommamichael 2mo ago

The Odin programming language does this! It has also decided not to provide a package manager.

Ygg2 2mo ago
Spoiler alert! JavaScript has no language provided package manager. If Odin gets moderately successful someone will probably reinvent it.
- leecommamichael 2mo ago
  NPM came along in 2010, Javascript was huge before that. It was only when people wanted a common approach to shipping both in browser and "native" that this glitch happened. I believe a standard library and "batteries" would have abated it entirely or resulted in a slightly less-bad situation. I do think Cargo is a slightly less-bad situation in many ways, and that it can be done better.
  - Ygg2 2mo ago
    Sure. Maybe threshold is bit higher than moderately. But unless your language tries to sabotage itself by making code artifacts uncomposable (a la C/C++ where best way to compose libraries is through shell commands) some package manager will be inevitable. Batteries also don't help if dependencies don't replace them. Arrayref functionality has been part of Rust std lib for a while now.
  - josephg 2mo ago
    > It was only when people wanted a common approach to shipping both in browser and "native" that this glitch happened. Nah. Npm was invented because node had its node_modules directory. But it was tricky to find and download modules you wanted to use. Until npm, you had to add libraries to node_modules by hand. And check them in to git or something. And keep them up to date somehow. Npm added a searchable index and a tool to automatically install all your modules. Npm was only bundled alongside Nodejs many years later. Bundling was separate. I can’t remember if browserify predated npm or not. But it was a wild idea at the time to make node modules build for the browser too. Browserify - and later webpack and friends - work with or without npm.

mightyham 2mo ago

Rust has a sizable and well featured standard library at this point. I think it would be absurd to claim that the base language is "near-unusable" if you are using it for system programming, which is its intended use case. Huge standard libraries make sense for Java, Go, Apple platform etc. because they are developed by giant enterprises that can manage the overhead. Thinner modular systems are a more natural fit for open source development.

cosmic_cheese 2mo ago
It’s being used for a wide variety of other purposes however, and so perhaps it’s time to adapt to that reality. While overhead is a real concern, I think it’s often blown out of proportion. Once a language achieves a certain baseline of stability and isn’t in constant flux and the standard library matures, changes become infrequent and maintenance load is low. The work is heavily front-loaded.
- VorpalWay 2mo ago
  Not at all true, look at the large parts of Python's standard library that are effectively unusable or irrelevant. And they even allow some breaking changes over time (unlike Rust). This is especially true when it comes to anything related to internet protocols or file formats, but there are other modules that have far better replacements on PyPi too (re vs regex for example).
- kelnos 2mo ago
  > It’s being used for a wide variety of other purposes however, and so perhaps it’s time to adapt to that reality. Who is going to pay for the resources to make that happen, though? The reality is that the bulk of Rust contributions come from a fairly small group of people, many of whom are volunteers. Some are Mozilla employees, and they don't have all the funding in the world. Yes, it would be great if every open source project could magically be able to meet the needs of all its users, but that just isn't how it works.
josephg 2mo ago
True. And the rust standard library is pretty good. But I really wish we had a good, fast, small futures executor in std. And accompanying async variants of File and Socket and so on. Async rust is a jungle of weird compatibility questions. People treat async runtimes like sports teams. (I know I do). I wish it were more like Nodejs where async is just built in.

segphault 2mo ago

This is spot on. I am extremely uncomfortable with the large number of transitive dependencies that end up in pretty much any non-trivial rust application. No amount of memory safety will save us if a tiny, ubiquitous library that nobody scrutinizes because it’s nested eight layers down the dependency graph gets compromised. I think Go apps tend to have better dependency hygiene because the language has a better standard library, which results in better culture around dependencies. I also think it’s frustrating that both cargo and npm totally ignore the decades of prior art from Linux distributions that have figured out good ways to improve dependency management. We’d be in better shape if there was a community curated subset of known-good dependencies that are release-managed together that the broader ecosystem could build on, sort of like Ubuntu having “main” and “universe”.

__david__ 2mo ago
I think Go ends up with fewer dependencies mostly because there is more friction in finding them. With rust (and npm) you just "cargo search xxx", then "cargo add xxx". Go makes you web search and poke around github looking for something. It's not onerous or anything, but just that extra step slows things down just a bit. C projects tend to have the least because it's even more annoying to add them and you have to create build commands that deal with slightly different distributions (and learn makefile+pkg-config or cmake, or autoconf). Certainly having a larger stdlib helps Go projects keep their deps down, but I don't think it's the real reason.
- teach 2mo ago
  Actually I think this is more of a culture thing. Or maybe "is also" a culture thing. One of the core tenets of early Go was the maxim "a little copying is better than a little dependency". Probably because of this stance, they didn't even HAVE a dependency-management solution for years I strongly agree the fewer dependencies the better, on average.
  - cogman10 2mo ago
    I agree. Java has the same ability to quickly add deps, and in some case they can be sprawling, but it's still perfectly possible to develop complex apps without a lot of deps coming in. Culture has a lot to do with it.

nemothekid 2mo ago

>There’s no reason why this can’t be replicated elsewhere. The key is to make the programming language reasonably robust with at least 80% of common non-UI dev needs built in and put the remaining 20% and UI bits into a small family of well-supported, community-embraced, preferably first party libraries. The big reason is money & time. Maybe less so today if you are happy with an AI generated stdlib, but I don't think it's fair to compare Rust (built by Mozilla, who's primary product is an open source web browser) to Swift/AppKit (built by Apple, 4.6T marketcap at the time of writing). When Go was released it had an amazing stdlib, but that was because Google was funding it.

echelon 2mo ago
Python is batteries included, but all the batteries have corroded. Look at C++'s long in the tooth STL. You don't want to marry a language to fast aging libraries you have to support for eternity. Better libraries always naturally emerge. Rust's decision here is fine. The only thing I'd like to see is the ability to programmatically limit transitive dependency count or depth in Cargo. I'd also like crates to specify whether they limit their own deps and whether they have panick-y behavior or not.
- smw 2mo ago
  I think maybe the right answer is to have a standardized, curated group of libraries pegged at some sort of LTS release that only backports security fixes. However, someone would need to pay for creating and maintaining this -- and then you wonder where the money would come from?
  - cogman10 2mo ago
    That or potentially fast tracking merging popular libraries into the standard library. Or at least concepts from popular libraries. Basically all the "most downloaded" crates on the Crates.io front page should be candidates for merging into the standard library. https://crates.io/ https://crates.io/
    - 2mo ago

TZubiri 2mo ago

>I think we should be taking a more “batteries included” approach https://www.youtube.com/watch?v=GZOuz-SG7-g https://www.youtube.com/watch?v=GZOuz-SG7-g Funny how you skipped "I should build my own batteries" and when straight to "increasing and centralizing the duties of your main gratis 'vendor'".

cosmic_cheese 2mo ago
I don't like the "bring your own" approach because unless one happens to be an absolute tour de force 10x engineer unstoppable god of a programmer (which most of us, myself included, are not), whatever you build is never going to be as well-rounded, fleshed out, and complete as something built by a larger organization, especially when it comes to UI libraries (which are monstrous projects if done right, e.g. meeting accessibility requirements). I'm happy to contribute to a larger effort but anything I can build on my own is going to be a thin, flimsy happy meal toy compared to something with the backing of a company or well organized FOSS project.
- TZubiri 2mo ago
  I agree that building your own is hard and something that can be done by exceptional engineers, but software is famously a winner-take-all industry, even if the optimal strategy for lower percentile programmers and median programmers to import generic modules, as long as building your own results in the best product (which it does, whether importing frontend or backend modules, if you hand code something, it's going to be the optimal strategy for building a winner product. Even programmers that are median or below average probably have an incentive to aim for being exceptional, because the best value of median and below average programmers is not building median or low value software, but having a shot at building exceptional software. Also the challenge of building a generic module is much larger than building your own. A generic module needs to have flexibility for many different options and integrations, when you build your own you build just what you need and tightly integrate it with the product
  - cosmic_cheese 2mo ago

cpill 2mo ago

with LLMs it's becoming more common to just vibe up anything you need that might be missing. even if there is an available package you can pull in. the most secure option as well

rfgplk 2mo ago

> I can very easily build a highly functional, pleasant to use Apple platform app with 5 or fewer top level dependencies. In many cases, I reach for between 0-2 total. > There’s no reason why this can’t be replicated elsewhere. The key is to make the programming language reasonably robust with at least 80% of common non-UI dev needs built in and put the remaining 20% and UI bits into a small family of well-supported, community-embraced, preferably first party libraries. I wholeheartedly agree. Most standard libraries out there (when I say most I easily mean of 99% languages that I know) have pitifully tiny implementations. They at most provide for string parsing, io, a bare networking layer (that's at best a wrapper around the POSIX syscalls), threading and that's it. If you want to do anything more complex, you either have to roll it yourself or use an assortment of the "blessed libs" for any given language, that may or may not work properly, and may or may not even work well with each other. I got pissed off by this at some point so I decided to go ahead and roll my own standard lib that would actually have everything I need to.. actually develop apps. Now I know most people probably aren't going to be using it (mainly because its functional API isn't what most C++ devs want) but for me it's actually been brilliant.

fc417fc802 2mo ago

I don't see the problem with boost? Isn't that a perfect example of your well supported, community embraced option? I certainly feel much safer pulling something in from boost via the official debian repos than I do pulling a random package with npm or cargo or etc. Primarily I think the underlying concern has to do with the pathway for authoring code. When you have contributors whose submissions are gated with a rigid third party process and where that third party is the one responsible for curating the code (as opposed to the author also being the curator as well as the publisher) then you have the possibility to catch a lot of wrongdoing before it succeeds.

cosmic_cheese 2mo ago
> I don't see the problem with boost? There are many issues that I've seen taken up with Boost, but my personal peeve is how it can make building projects that incorporate it a pain, both because of its sheer size but also because it can sometimes be difficult to appease with its own dependencies.
- peesem 2mo ago
  that seems unrelated to the security problem to me

lelanthran 2mo ago

> I can very easily build a highly functional, pleasant to use Apple platform app with 5 or fewer top level dependencies. In many cases, I reach for between 0-2 total. > There’s no reason why this can’t be replicated elsewhere. It is replicated elsewhere and is not limited to Apple; I can do the same using a tech stack of perhaps 2x techs and very limited (manually added) deps. I'm thinking Lazarus, which comes with most things I'd need for most apps.

VorpalWay 2mo ago

> I think we should be taking a more “batteries included” approach to language and library design. The entire reason we’re in this mess is because we’ve decided it’s ok or maybe even preferable if stdlibs are rail thin, rendering base languages near-unusable. Nobody can agree on what those common things are in a general purpose langusge though. It works for something like Go, because it is largely used for servers and command line tools from what I can tell. For Rust, well I would like to prioritise features for embedded development, someone else might want game dev features (geometry and physics stuff), yet another person wants data science things. And so on. And even if did put some of those things in std, that is stable forever. That is how C++ ended up with an unusably slow regex implementation in the standard library. And it isn't fixable. Everyone just ignores it and uses a third party library like PCRE, RE2, etc instead (depending on their specific needs). I would not expect web or GUI things in the standard library for this reason, those standards change too frequently for that to be stable forever. And even something like Python, which is known for data science and machine learning, doesn't have core libraries for those activities in the standard library. Numpy, Pandas, Scipy, Pytorch etc are all third party projects.

ksbd-pls-finish 2mo ago
Well I use python daily for the past 10 years and I never did data science. Data science? Everyone knows python is the language of cyber security.
piker 2mo ago
Maybe that’s a good place to make the cut. One Rust crate for game dev, one for data science, etc. Then their deps are pinned and monitored by the crate maintainers.
barnabee 2mo ago
I wrote this on another thread recently, but my line for exclusion from standard library is a library that’s any one of: - not obviously/generally useful (i.e. useless or too specific/should be a program not a library) - obviously trivial (code it yourself when you need it/compose from other primitives) - already available (open source) elsewhere by a credible team that supports and maintains it Anything else… put it in the stdlib

mattrighetti 2mo ago

> I can very easily build a highly functional, pleasant to use Apple platform app with 5 or fewer top level dependencies. In many cases, I reach for between 0-2 total. Most of the things I wrote in Rust have less than 5 dependencies. Those 5 dependencies then depend on 20 other dependencies each. Those 20 dependencies have 2-3 other dependencies. And so on…

kibwen 2mo ago
Counting the number of crates in the dependency graph in order to gauge exposure is a misunderstanding of how Rust works. In Rust the crate is the unit of compilation. Unlike in Javascript, the fact that a crate has dependencies on other crates does not mean the author pulled in random code written by someone else, it often just means that the author wanted to leverage crate-level compilation parallelism by splitting a large compilation unit out into several smaller ones.

wmedrano 2mo ago

Ok in theory, but I don't think it applies here. Maybe it does in a cultural way. Arrayref seems somewhat niche, but its kind of in the standard library as of Jan 2026 as std::slice::as_array https://doc.rust-lang.org/std/primitive.slice.html#method.as_array https://doc.rust-lang.org/std/primitive.slice.html#method.as...

kibwen 2mo ago
For the example given in the arrayref docs, I'd say you should be using std::slice::as_chunks, stabilized in 1.88: https://doc.rust-lang.org/std/primitive.slice.html#method.as_chunks https://doc.rust-lang.org/std/primitive.slice.html#method.as...

raincole 2mo ago

> There’s no reason why this can’t be replicated elsewhere. There are plenty reasons. Just not technical reasons. At the end of the day, people like to feel useful. The ecosystem that attracted communities are those ones where everyone can feel they're contributing back to the communities. That's why the most successful languages, save those backed by big companies, are filled with very small libraries. No body gets excited making C#/nuget packages.

waterTanuki 2mo ago

deepsun 2mo ago

A big selling point of Java also was a very strong built-in library, e.g. with red-black trees (TreeMap) and concurrent lock-free zero-mutex queues (ConcurrentLinkedQueue). No wonder competitive coding champions sometimes preferred Java as they don't had to spend time coding it from scratch.

FacelessJim 2mo ago

I really like the approach Julia is taking. The std libs are their own packages with their own versions. You can then build your own “standard library” by compiling a sysimage that freezes the versions (you can add third party packages as well). Practically speaking the standard library is just meant as “what’s included in the default sysimage”. This allows to have different standard libs for different use cases. Think of Linux distributions in a sense. There are already a couple of alternative “stdlibs” out there for different focuses.

chiffaa 2mo ago

> we should be taking a more “batteries included” approach to language and library design. Okay, but how do we decide which approach to a problem should be standardised? Rust's approach of "provide a minimal core to build libraries on top of" provides a fairly significant benefit - flexibility. A prominent example is async: Rust has three fairly prominent async runtimes (being Tokio for general server-side use, smol for a simple non-work-stealing approach and embassy for embedded). Which one do you make the default? Tokio is very complex and work-stealing is arguably a very bad default in terms of development complexity. smol doesn't fit some workloads because of a simpler execution model. Embassy is way lower level and much more constrained than most applications need. Standardising over one implementation instead of the current (even if still messy due to early portability woes) standardisation around traits and general async semantics would make switching runtimes more problematic, even though the general case is solved with the same approach as Python's Database access is also a complicated topic. Rust has multiple fairly popular DB libraries. The first two that come to mind are SQLx and Diesel. Both are too complex to be a part of the standard library, both required a fair bit of breaking changes, and if you wanted a raw core to build on top of - you can't really build SQLx on the type of core e.g. Go's database/sql has, you'd be basically forced to implement it all from scratch to handle the compile time type checks anyway RNG sounds simple, except there are good reasons behind both rand and fastrand existing, and behind rand not being stabilised at 1.0. DateTime handling is notoriously complicated, has multiple competing implementations (chrono, time, jiff) with various trade offs Where do you draw the line? What do you standardise and which implementation do you standardise against? I've seen golang exemplified a lot in adjacent threads, but golang's standard library both has fairly significant issues (json, no set type, very limited CLI flag parsing, UUID took until 1.28) and is standardised around a relatively specific goal (unix server usage) Dunno, I'm not entirely sold on the whole "extend the standard library" idea for a language meant to run both high level applications and embedded stuff. If anything, recommending blessed.rs more is a better way IMO

pseudony 2mo ago

You can never please everyone , and some stdlibs can age like milk (see ocaml). Having libraries allow the community to explore rather than saddling it with a bad default. See the number of http server frameworks etc. The real solution here is not for the stdlib to become a black hole, swallowing up every half-way popular library a but rather for “rustaceans” to adopt a more security-conscious approach to writing programs- C programs typically have few and well-chosen dependencies. Some languages, like Odin, completely eschew package managers because they see the very real issues stemming from writing a program with scores or hundreds of dependencies.

a-french-anon 2mo ago
You seem to be ignoring that most people who want off the infernal npm/cargo hamster wheel are conscious that it implies a bit of spoilt milk or moldy bread in exchange for stability and that they're fine with it. The gains are just too numerous and important to reject the few rust spots on a "good enough" stdlib. But well, the kind of people who nod a bit too much while reading https://boringtechnology.club/ https://boringtechnology.club/ aren't using Rust. They're on C99, ANSI CL, Ada, maybe Python, Perl or Tcl.