Live data from Hacker News

Battery packs: Let's talk about crates, baby

smallcultfollowing.com

21–30 of 33 posts

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

#21

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)

Reminds me of how calling wine prefixes "bottles" makes things easier to someone.

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

#22
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.

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

#23

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.

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

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.

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

#24
post #20

Earlier quoted context omitted.

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.

Back then there was no versioning. When you imported a URL, you had to hope that all your projects and transient dependencies happened to be compatible with whatever commit was currently sitting on the master branch. Because one update could silently break an unrelated project on your machine, adding a dependency was a bigger decision. That naturally led the ecosystem to favor fewer, larger libraries.

PS: it looks like this issue was addressed in 2019 with the introduction of Go Modules.

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

#25
post #21

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)

Reminds me of how calling wine prefixes "bottles" makes things easier to someone.

Homebrew is also great in this regard

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

#26

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.

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.

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

#27
post #21

Earlier quoted context omitted.

Reminds me of how calling wine prefixes "bottles" makes things easier to someone.

Homebrew is also great in this regard

Yeah, I definitely think "pallets" would make more sense in this context.
Post reply on HN