>I think we should be taking a more “batteries included” approach
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'".
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.
There's also the time factor. Something you build on your own will not have decades of development and polish behind it.
>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).
The package in the OP is definitely not in the category of decades of development, it's closer to a leftpadism.
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.
I think that even for core modules like an http server or client, but that's not the case and we don't need to get into that debate.
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.