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.
The counterpoint is that whatever std invents is probably not going to be as good as what moviated people in the community make.
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.
> 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 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.
> Don't immortalize anything, though. Always reserve the freedom to swap out integrated crates when something better rolls around.
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.
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
> 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.
>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.
You seem to be under the mistaken impression that the Rust team is some huge organization. They're not. They are certainly larger than you or me sitting behind our keyboards at home, but they don't have endless resources, and they are always stretched pretty thin.
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).
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.