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.

It's a self-inflicted issue that most other languages with "batteries included" don't have since they will document breakage and upgrade paths when anything changes, or they are not impacted as much since they are using an intermediate language as interface and avoid most ABI issues.

The implementation is fixable though, you can break the ABI and address your issues. A lot of standard library defects are fixed in an unstable ABI mode they have, but that requires you to link it statically or dynamically and then ensure all your shared object dependencies are using the same exact version. It's not trivial for everyone, but many do this (usually the static version).

But even something like Python has lots of cruft in its standard library. And they are willing to make breaking changes. Nobody should use urllib.request for example, requests is a far better HTTP client library. To the point where the stdlib docs tell you so.

Well, then take the Lazarus / Free Pascal's approach and just put everything :-P. It isn't like code takes THAT much space.

If you install Lazarus you get a ton of stuff out of the box, aside from the crossplatform WYSIWYG RAD IDE and desktop application framework you also get 2D graphics libraries (with a bunch of image i/o), networking libraries, (de)compression libraries, a webapp framework, database clients, parsers for json, xml, markdown, javascript and a bunch of other stuff (even a parser for the language itself), a TUI framework, bindings for a bunch of external libraries and other stuff.

And all that stuff (or at least most of it) work on all the platforms the compiler supports. Yes, using FPC you can probably (didn't try) make a pretty markdown viewer with inline JPG and PNG display support that runs on Windows 3.1 :-P.

Unfortunately some people are trying to break this and introduce online package management, but so far at least FPC and Lazarus comes out of the box with not just batteries included but an entire carton of batteries just in case :-P.

It, as you put it, works for Go because its designers took a hard stance and decided that it was a language for network systems and you're on your own if you want to make it do other things. Nobody needed to agree because it was already chosen for you.

> 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.

But does Rust need to be all things to all people? The Go ecosystem has a separate standard library under the Tinygo project for those who want to prioritize embedded development. Even if there was convergence on Rust as a language, it doesn't technically need a singular standard library. There can be a distribution for embedded developers, a distribution for game developers, etc.

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”.

Rust meanwhile seems to be following some "no standard library" philosophy.

I feel like there's an opportunity out there to become like an amoeba: fund and build a third party Rust standard library, absorb absolutely everyone who is so grateful to have a library, and then get so big absorb Rust itself.

As an embedded dev, I personally find it very useful to compile Rust programs without a standard library. I would not use C# or Python for an embedded project for the reasons you probably prefer them for your projects.

But you gotta admit people trying to build GUI libraries and using linked lists don't fit.

Certainly having a larger stdlib helps Go projects keep their deps down, but I don't think it's the real reason.

I think the ease of adding dependencies does drive the idea of "microdependencies", where you have many dependencies that do one little thing, and then those dependencies likely have their own small dependencies.

Whereas in the C world, you'll probably have a smaller number of dependencies, but it's likely that some of them are very big dependencies that offer a lot of functionality (like glib, for example).

I could maybe see the argument that ease of adding dependencies discourages people from writing small things themselves. Good ol' left-pad comes to mind. In an ecosystem like C, I'd just write that algorithm myself, over and over and over, because pulling in a dep just for that feels annoying.

I disagree: having a big stdlib that encompasses a huge chunk of common functionality (logging, a plethora of network server/client protocols, etc) means that for basic needs, the question of 3rd party libs never arise, whereas for other language, the question is not if you need a dep, but which one. Making gorilla easier to find won't undo the cultural reluctance of adding a 3rd party dep when using the (very pragmatic, IMO) stdlib server is adequate to the task.

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.

Personally I came from a C background so I tended to use deps more sparingly.

In the end it's a bit of a balancing act—lots of dependencies is a larger opportunity for these kind of supply chain attacks to affect you. Copying stuff into your repo protects you from that, but it also makes it way more likely that you'll miss security fixes, unless you're actively looking for them. Re-implementing what you need is also viable but it slows down the dev process.

Culture has a lot to do with it.

There’s no poking, unless you are into that sort of thing

I'm not sure that's a bad thing. I suspect with increased friction, users are more likely to scrutinise dependencies before importing them.

This does sound like an excellent way of improving automated package checks, even if it does result in some false positives and false negatives. For all sorts of packages, not just code dependencies.

The proposal ends up amounting to either shifting stuff around, or asking to other people to put in more effort? Into a project that usually doesn't pay (programming languages and runtimes)

Which by the way, asking other people to do stuff for free IS the attack vector, if you are the kind of dev or company that gets hit by these, your ultimate root cause is that your business strategy is using code without paying for it. No such thing as a free lunch, you will pay for it, among other things, with an increased cybersecurity risk.

Packages can release updates arbitrarily, while standard libraries tend to have longer release cadences.

It's also more difficult to put arbitrary code into an stdlib, because stdlibs are scrutinized better.

Also, it's harder for some random anonymous developer to gain push access to stdlib repository.

One of the reasons so much Rust code is in libraries is not because there are no people to write it (duh), but because putting these in std commits maintainers to keeping backwards compatibility and slows down included package's release cycle.

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.

You will be trading a stable and vetted huge standard library for 200 small packages that may all be targets for supply-chain attack. Open-source projects don't all have the resources unfortunately to keep track of all their dependencies, so I'm not sure it's necessarily a more natural fit.

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.

That’s not what I call well featured.

Most programs should need close to zero dependencies.

Of course they’re free to do what they want, and there’s the question of maintenance overhead[0], but while https://blessed.rs/ needs to exist, Rust’s standard library is deficient in my eyes.

[0] One idea would be to treat a language more like an Linux distro and have library maintainers like package maintainers but a unified quality, audit, and release process

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.

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.

https://github.com/rust-stdx/stdx

https://news.ycombinator.com/item?id=48571266

Note that there are baby versions of this that are uncontentious, for example

https://blessed.rs/crates

this is missing the LTS release. but it is a curated group of libraries that are relatively uncontentious to recommend.

https://crates.io/

https://crates.io/crates/once_cell

https://doc.rust-lang.org/std/cell/struct.OnceCell.html

Not everything should be eligible for this treatment. Certainly not an HTTP library or something without extremely widespread applicability.

Nearly all of my projects used once_cell, so it's good to see that pulled in. I wouldn't want to see anyhow, thiserror, anything opinionated, or anything domain specific in the std. That's a weight you have to bear forever.

Remember how long Python 2 -> 3 took, and look at the ancient and awful stuff in Python 3's standard library. Rust is not the right language for this.

One can very simply....make breaking changes. Yes it will require some work to update but that's already the case when you upgrade library versions.

The dependency hell doesn't help anyone here, the downside is much worse - lots of bloat, overgeneric libraries and awful supplychain security.

For rust, this would mean something like adding std = 1.0.6 to your cargo.toml. The advantage is it means the standard library can deprecate and replace features. Upgrading std is an explicit step by the developer. Annoying, but in the age of LLMs it should be pretty easy.

The one big question I can’t answer is what happens if your dependencies use a different version of std? Are std v1 Strings compatible with std v2 strings? Oof.

C++ went through that around C++11, where some types had to have ABI breaks (on some implementations, such as that of GCC's libstdc++). It has been a while, but as I remember it std::string was affected since it went from COW to SSO. Map might have been affected too (don't quite remember). It was a mess.

Rust can link multiple semver versions of the same dependency, but you can't pass data structures between those versions. For transitive dependencies that usually isn't a big deal if your direct dependencies use them internally rather than exposing the types in their own APIs. But std contain vocabulary types that everyone uses (Option, Result, String, etc) so that would really not work.

Some features, e.g. the never type[0], are held back years due to all the work that's needed to minimize the breakage.

[0] https://youtu.be/3jM4cnEVrLc?t=271

Swift was intended from the start to not only replace Objective-C and all of its use cases, but also take on new use cases and bring a number of features from other languages that were newer and had different dominant paradigms.

Certainly having a juggernaut like Apple behind it has been instrumental in its success in achieving those goals. That said, a community-lead project with similar aims could probably achieve those aims as well, given enough time.

I think it's just rare for enthusiast-led projects to set out to do such things. My theory on why things tend to go that way is that the types of people to start programming language projects tend to heavily lean nuts-and-bolts and theory with a purist/idealist sort of mentality that's more concerned ideological purity than practical usability.

So to sum this all up, a community-run practical, multi-purpose, batteries-included language likely needs to at least partially designed and helmed by product engineer types so it doesn't end up anemic and stuck in an ideological rut.

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.

Another big reason to put something in std is providing types for cross-crate compatibility. If I want to pass a String from one crate to another, I’m glad that string is defined in std so there’s an obvious type we can both use in our APIs.

C - for example - does not have this luxury. Everyone makes their own string type, and C APIs all need to translate strings at the api boundary. It’s super annoying.

It would be nice if we had a standard way in rust to declare a type as serialisable. Right now lots of crates have a serde feature flag to do this with serde. But (a) they need to put this behind a feature flag, since it adds a dependency on serde. And (b) this doesn’t work with other serialisation libraries.

The other big one is futures. There’s still no futures executor in std. Async crates have to decide if they want to tie themselves to a single executor (like Tokio) or be compatible. There is no async stream api in std. No async file api. And so on. It’s a compatibility nightmare.

We need useful traits to abstract over async runtimes. But there are a lot of design points for runtimes so this can't ever go into std. There is embassy, for embedded systems. There is monio and glommio built around io-uring. Then there is smol intended to be simple and lightweight. And then there is the kitchensink of tokio.

Clearly embassy is the one we want in the standard library. /s (It is the only one I personally would have a use for. But no, I don't think any of them belong in std. Traits to abstract over them? Yes, absolutely.)

But even your other example of strings: there are many design points for strings too, that might be better fits for specific use cases: string builder (with a capacity, what String in rust is), copy on write, small string optimisation (like compact_str), even interned strings. So your example of a vocabulary type is somewhat flawed, a better example would be Option or Result. Even anyhow and thiserror build on top of those vocabulary types.

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?

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.

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.

No it's not. It's exactly what I want, at least.

> When you're upgrading software, you presumably want a better version.

Sure...

> You can't have something better without changing it. It's a logical contradiction.

No, that makes no sense. When I upgrade the rust compiler, I might want it to compile programs faster. I might want its borrow checker to be smarter so that it accepts more valid programs than it did before. I might want to have some new language features (like if-let chaining or GATs).

What I absolutely do not want is to have to change the code in my programs so that it can be successfully compiled by the new version of the compiler.

Yes, certainly there are some times in the lifecycle of a piece of software that there's an improvement that requires a breaking change, but you believe is important and necessary, so you bite the bullet and do it. But you burn user goodwill every time you do that (maybe not your goodwill, but most people are not like you in this regard), and create work for people that they would probably prefer not to do. You also create fragmentation, because people aren't going to upgrade their new stuff to the new version all at the same time, and some people may never upgrade. All of this has costs, and deciding never to make breaking changes (or at least keep them to the absolute bare minimum) is a reasonable choice in the face of those costs.

Maybe it's not the choice you personally would have made, but it doesn't mean it's a mistake. They just value a different set of things than you do, in a completely reasonable way.

Sorry, that's a strawman. Of course you cannot have a better version without changing things. You definitely can have a better version without changing public API.

And people upgrade their toolchain not because they want a different API. They mostly want bugs fixed, support, and sometimes features. Breaking the API has a huge cost and minor benefit.

> It very much does because you don't need 95% of the random stuff in the crates.

But why does it matter if all that stuff comes in std or in an different crate? As I said security doesn't play a role here. You can't even avoid compile-time cost because the std can only come precompiled because it only changes with the toolchain, which is another downside we want to avoid.

> 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.

And again, how is that different from what I say, other than calling "official crates" as "std"?

Batteries included ia the only sane way to do programming languages.

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.

And tons of parts of the standard library (and language) being cordoned off as "legacy, don't use for new development". Of course figuring out what you shouldn't use in C++ can be hard too. It isn't well documented (or universally agreed upon), and it takes having it as a full time job to be able to keep up with these days.

No, I much prefer the way Rust is doing it.

Sure, it would be great if the volunteers that contribute to C++ compilers, would improve regex instead of adding the gazillion of features that each ISO C++ standard requires, mostly on their free time, because devs can't be bother to pay for compilers.

Additionally the companies that actually sponsor those compilers also have bigger priorities than improving regex implementation.

Finally if you want to stick regex into a micro-benchmarks context, there are plenty of options out there, as you point out.

The Rust way, like you can have any async runtime, as long as it is Tokio?

As for async in Rust, I wrote in another comment that yes that is an issue. What we need is std to define traits that all the different runtimes can implement. Because there are absolutely reasons to use alternative runtimes, depending on what you do. I mostly use embassy (embedded microcontroller development) for example. And if you want thread-per-core with io-uring you want glommio or monio. Smol is simple and compact.

I could also see uses for async in desktop GUI or gamedev (but to my knowledge there isn't any runtime suitable for those domains yet).

Just to quote a possible scenario among others.

Guava for whatever cool reason, and so on.

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.

I think it goes without saying that emulating PHP is rarely a good decision.

No, I prefer what rust is doing. It suits a system programming language. Which is what Rust is.

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.

Not every application requires internationalisation, especially server code or internal company tools.

> 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.

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

> 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.

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...

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.

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/ aren't using Rust. They're on C99, ANSI CL, Ada, maybe Python, Perl or Tcl.

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.

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.

What is your critique of their approach? Is it not the case that `go get` is the only one which doesn't even provide a way for the person downloading to run the downloaded code until it is actually executed by the consuming codebase? That seems pretty sound by comparison.

I guess you're saying, "they had to" meaning they should've seen the need and provided it? I'll say this to that (imagined) take; plenty of useful software was made without it, and they got the job done when they knew the absolute most about what a good solution would need. I totally understand being annoyed at the fact that this is the story of every evolution in Go, but I genuinely think they're picking good implementations when they decide on them.

It’s half arsed, brittle and far from user friendly.

> Is it not the case that `go get` is the only one which doesn't even provide a way for the person downloading to run the downloaded code until it is actually executed by the consuming codebase?

If you’ve added the package to your imported then odds are your next step is going to build it. Thus negating any benefit.

I think the real issue is malicious packages entering package ecosystems. Whether your package manage executes on downloads or not is moot because you’ve still got untrusted code sat in your project imports, just waiting to be accidentally executed.

> I guess you're saying, "they had to" meaning they should've seen the need and provided it? I'll say this to that (imagined) take; plenty of useful software was made without it, and they got the job done when they knew the absolute most about what a good solution would need. I totally understand being annoyed at the fact that this is the story of every evolution in Go.

I think you’re being too charitable here. I think Russ Cox just didn’t want a package manager because C doesn’t have one. But ended up relenting after everyone nagged the Go team for years afterwards.

And really what they built was the bare minimum to manage package version pinning and updates. But it has none of the visibility that central package repositories have. So how do you know if a Go package has been compromised when the only source of truth is the compromised origin?

I don't think automatic updating is a good idea at all. It's just the honor-system, and trust is a security flaw.

The problem is your solution depends on the honor-system. Ie “trust me, because I’m just a YAML mashaller. Why would I want to inject a crypto miner?”

That’s why package databases exist. They are meant to be centralised databases of peer reviewed and CVE checked resources. But Gos approach pushes all that responsibility onto each and every developer.

One thing it does get right, in my opinion, is removing the value of name squatting.

We really do need to rethink the security model behind open source.

If Odin gets moderately successful someone will probably reinvent it.

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.

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.

Batteries also don't help if dependencies don't replace them. Arrayref functionality has been part of Rust std lib for a while now.

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.

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.

No wonder competitive coding champions sometimes preferred Java as they don't had to spend time coding it from scratch.

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.

The rand crate is my favorite example of this. They have a whole bunch of different rngs. All rated by quality and performance. Some are csrngs and some aren’t. It’s a delight. “Batteries included” languages don’t come close.

Then there’s serde - which uses a clever technique with traits to allow compile time specialisation and optimisation of binary and json serialisers. Most people had no idea that was even possible in rust until someone in the community made it.

Maybe std should pick up the best crates from the community and bring them in house? This might be a good idea. But also maybe not. Since serde came out, several other crates have found ways to crush its performance numbers. Often by 2-5x if memory serves. What a relief we didn’t immortalise the slow version of serde, right?

I’m playing devils advocate here. I think std should be a bit bigger too. But there are real tradeoffs in doing so.

I think periodically rolling in the best crates is the way.

Don't immortalize anything, though. Always reserve the freedom to swap out integrated crates when something better rolls around. Negative impact can be reduced by limiting these kinds of changes to major new versions.

Another option is to swap internals while keeping the same public API. Apple has done this several times with Swift, resulting in massive speed improvements in things like string handling and JSON decoding without breaking anybody's code.

That's a non-starter, though. Once it's in std, it's not an "integrated crate", it's in std, just like any other part of it. Removing it is a breaking change, and I don't want a new incompatible Rust major version every year or two (or even five or ten, honestly). (Of course, Rust has editions to make breaking changes possible without affecting old code, but there are limits to what you can change in editions.)

Pretty much every language ecosystem fights really hard to maintain backward compatibility as they evolve, and every time they fail to do that, it causes headaches, sometimes for years. Python 2->3 is of course the canonical painful example of that, but there are others that are instructive if you only take the time to research.

(And before you mention something like Zig, which changes incompatibly frequently enough, remember that the author has made an active decision to remain pre-1.0 unstable. That's one reason why the Zig community isn't that large. That's not me looking down on them; that's an active choice they've made, and they're free to make that choice. But bigger/popular languages like Rust can't go back in time and decide to be like that.)

Yes, it’s annoying to have to make fixes around my codebases periodically, but to me that’s a hell of a lot less annoying than having to pull in a mile long list of dependencies to do anything of consequence. It’s also better than the bad parts of the language being frozen in time forever.

Apple breaks things with Swift not constantly but on occasion and while there’s some griping around it, it’s not a big deal. We make the needed changes and move on, knowing it’s enabling improvements that will be nice to have.

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

True but I believe overestimated. Usually rather than building what's needed, what gets built is what is thought to be needed (often a substantially smaller subset), and then over time you end up building a markedly poor version of a generic module.

let's look at the actual package from OP

>https://docs.rs/arrayref/latest/arrayref/

>This package contains just four macros, which enable the creation of array references to portions of arrays or slices (or things that can be sliced).

I'm no rust programmer, but that doesn't sound like something that moves the needle. I talked about the ratio between value to risk being a relevant decision parameter, so getting infected by an http framework would be defensible, getting infected by adding this to a project to me is a PIP, and getting infected by installing leftpad or a custom cursor plugin in an IDE would be fireable.

So sure, you want, say, a JSON library in Rust std? Who's going to shepherd it in and then maintain it? Well, you could hope that the people behind serde_json might want to do it, but what if they don't? Where are you going to get the people with the time to do it?

For something like Go, the answer is easy: tap into the money printer that is Google, and hire more people. But for Rust? Hell, the core team has probably only declined in number over the years (Mozilla layoffs, for one thing).

>This package contains just four macros, which enable the creation of array references to portions of arrays or slices (or things that can be sliced).

The package in the OP is definitely not in the category of decades of development, it's closer to a leftpadism.

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.