Battery packs: Let's talk about crates, baby
23 points
1 day ago
| 5 comments
| smallcultfollowing.com
| HN
rickdeckard
1 hour 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)

reply
two_handfuls
4 hours ago
[-]
For those struggling for context like me: this is about the Rust programming language.
reply
yjftsjthsd-h
2 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.

reply
zem
26 minutes 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.
reply
ho_lee_phuk
1 hour ago
[-]
Go ecosystems seems to choose quality over quantity (fewer higher-quality libraries) over Rust.

What seems to be causing this?

reply
whstl
43 minutes 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.

reply
olalonde
1 hour ago
[-]
I'd say ease of package management. You can see this with Python too.
reply
wseqyrku
3 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.

reply
eptcyka
1 hour 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.
reply