Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Battery packs: Let's talk about crates, baby

smallcultfollowing.com

Post reply on HN
Print view View original

11–20 of 33 posts

Re: Battery packs: Let's talk about crates, baby

#11

Post by zem »

yjftsjthsd-h wrote: post #5

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

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.

Re: Battery packs: Let's talk about crates, baby

#12

Post by inigyou »

whstl wrote: post #10
ho_lee_phuk wrote: post #7

Go ecosystems seems to choose quality over quantity (fewer higher-quality libraries) over Rust. What seems to be causing this?

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.

What is Python?

Re: Battery packs: Let's talk about crates, baby

#13

Post by inigyou »

olalonde wrote: post #9
ho_lee_phuk wrote: post #7

Go ecosystems seems to choose quality over quantity (fewer higher-quality libraries) over Rust. What seems to be causing this?

I'd say ease of package management. You can see this with Python too.

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.

Re: Battery packs: Let's talk about crates, baby

#14

Post by wseqyrku »

eptcyka wrote: post #6
wseqyrku wrote: post #4

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.

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.

> if async was implemented as effect handling

By any chance, was there a proposal for that I could read?

Re: Battery packs: Let's talk about crates, baby

#19

Post by olalonde »

inigyou wrote: post #13
olalonde wrote: post #9

Earlier quoted context omitted.

I'd say ease of package management. You can see this with Python too.

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.

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.

Re: Battery packs: Let's talk about crates, baby

#20

Post by inigyou »

olalonde wrote: post #19
inigyou wrote: post #13

Earlier quoted context omitted.

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.

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.

That is the package manager. The package has a URL. You import the URL and you're done.
Post reply on HN