Rendered at 14:17:57 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
efaref 6 minutes ago [-]
I guess the name is intending to evoke the "batteries included" metaphor, but it seems pretty terrible to me.
If we're sticking with the crates/cargo metaphor, surely this should be called a "pallet".
rickdeckard 6 hours ago [-]
The hobbyist device maker in me took waaay to long to be certain that this is NOT about physical batteries...
(was already confident, then there's suddenly a screenshot mentioning display components)
RunSet 2 hours ago [-]
Reminds me of how calling wine prefixes "bottles" makes things easier to someone.
tomashubelbauer 59 minutes ago [-]
Homebrew is also great in this regard
bennettnate5 8 minutes ago [-]
Yeah, I definitely think "pallets" would make more sense in this context.
two_handfuls 9 hours ago [-]
For those struggling for context like me: this is about the Rust programming language.
tialaramex 2 hours ago [-]
I hope one day to coincidentally have an earworm which works as sub-headings for something I want to write about.
yjftsjthsd-h 7 hours ago [-]
> Battery packs are meant to address one of the most common things I hear from new Rust adopters. Everyone loves the wealth of high-quality crates available on crates.io. And everyone hates having to spend a bunch of time researching and comparing alternatives.
> [...]
> One of the key ideas from battery packs is that anybody can publish one.
So now we get to research and compare alternative battery packs? I guess it could help if there's fewer of them, but I don't see why that would be.
zem 5 hours ago [-]
at the very least you could follow some trusted entity's recommendation for a bunch of crates at once. e.g. if the author of some large rust project like bevy published a battery pack I would pay attention because they have had to solve the problem of picking out several crates and seeing that they all work well together.
ho_lee_phuk 6 hours ago [-]
Go ecosystems seems to choose quality over quantity (fewer higher-quality libraries) over Rust.
What seems to be causing this?
whstl 5 hours ago [-]
Money dictates personal philosophies.
Rust and Node have too many deps because you can't make a Patreon or Github Sponsors page for contributions to stdlib.
Go is batteries-included because it was made by Google by people with a salary.
The people writing "thousands of small packages are good" are the people making money from the clout of having made thousands of small packages.
inigyou 4 hours ago [-]
What is Python?
olalonde 6 hours ago [-]
I'd say ease of package management. You can see this with Python too.
inigyou 4 hours ago [-]
Package management is easier in Go than almost any other ecosystem, including Rust, Python and Javascript. And Go projects may have tens of package dependencies. Yet it's closer to a C++ project which has single-digit dependencies than a Javascript project which has tens of thousands.
olalonde 2 hours ago [-]
Interesting. When I learned Go a while ago, it didn't have a package manager. You just pulled down master branches directly into your global GOPATH. So pulling in a dependency was a big decision and people naturally favored "batteries included" libraries. That probably still permeates the culture today.
inigyou 2 hours ago [-]
That is the package manager. The package has a URL. You import the URL and you're done.
olalonde 1 hours ago [-]
[dead]
Levitating 4 hours ago [-]
In my opinion this will just worsen the ecosystem. Many Rust crates are already bloated with dependencies.
assbuttbuttass 2 hours ago [-]
Sounds like a great way to get dozens of dependencies before you even write a line of code
functionmouse 2 hours ago [-]
It's about boosting attack surface. Trust the plan :)
wseqyrku 8 hours ago [-]
Off we go comparing battery packs.
Seriously though, I wish the dual futures, streams types to be consolidated first than building anything on top of the situation.
eptcyka 6 hours ago [-]
Futures would be less of a problem if async was implemented as effect handling instead of coloring functions - I am truly miffed about e.g. not being to use `or_insert_with` with a fallible async function. That and build sandboxing are my 2 pie in the sky dreams for a rust edition far, far away.
wseqyrku 4 hours ago [-]
> if async was implemented as effect handling
By any chance, was there a proposal for that I could read?
8 hours ago [-]
cold_pizz4 1 hours ago [-]
Everybody agrees that Rust's ecosystem is too fragmented, but I don't think that the solution proposed here will solve anything.
The most promising project to solve this problem is https://github.com/rust-stdx/stdx which is (more or less) re-creating Go's standard library in Rust.
chrismorgan 36 minutes ago [-]
The guy that is making stdx has been doing various shady stuff in his books and code which have resulted in all his stuff being banned on /r/rust. In stdx, he’s been forking good code, violating licenses, completely rewriting stuff with LLMs (including cryptography code, and definitely introducing bugs in the process)… it’s not a good approach.
jvanderbot 1 hours ago [-]
You're advocating for one solution that has two problems:
* It is precisely what TFA goes in for: a one-stop shop (somewhat application dependent)
* It is antithetical to the "embarassment of riches" approach that Rust tried for when they delegated almost all functionality to crates - the ecosystem has proven fruitful
It seems to me that advocacy, writing good applications, or human-readable guides will do more for convergence on crate bundles than a more technical solution. I reach for the crates I know, not yet-another-framework.
If we're sticking with the crates/cargo metaphor, surely this should be called a "pallet".
(was already confident, then there's suddenly a screenshot mentioning display components)
> [...]
> One of the key ideas from battery packs is that anybody can publish one.
So now we get to research and compare alternative battery packs? I guess it could help if there's fewer of them, but I don't see why that would be.
What seems to be causing this?
Rust and Node have too many deps because you can't make a Patreon or Github Sponsors page for contributions to stdlib.
Go is batteries-included because it was made by Google by people with a salary.
The people writing "thousands of small packages are good" are the people making money from the clout of having made thousands of small packages.
Seriously though, I wish the dual futures, streams types to be consolidated first than building anything on top of the situation.
By any chance, was there a proposal for that I could read?
The most promising project to solve this problem is https://github.com/rust-stdx/stdx which is (more or less) re-creating Go's standard library in Rust.
* It is precisely what TFA goes in for: a one-stop shop (somewhat application dependent)
* It is antithetical to the "embarassment of riches" approach that Rust tried for when they delegated almost all functionality to crates - the ecosystem has proven fruitful
Oh and a third:
https://xkcd.com/927/
It seems to me that advocacy, writing good applications, or human-readable guides will do more for convergence on crate bundles than a more technical solution. I reach for the crates I know, not yet-another-framework.