Comment by rfgplk | Hacker News Reader

Comment by rfgplk | Hacker News Reader

Parent Full thread

Yep. Sorry for the spam, but look at this, compiling "yazi" from source (ie a relatively simple TUI file manager) 676 dependencies:

  Downloaded by_address v1.2.1
  Downloaded block-buffer v0.12.1
  Downloaded block-padding v0.4.2
  Downloaded adler2 v2.0.1
  Downloaded color_quant v1.1.0
  Downloaded blowfish v0.10.0
  Downloaded byteorder v1.5.0
  Downloaded bytemuck_derive v1.12.0
  Downloaded futures-sink v0.3.34
  Downloaded bs58 v0.5.1
  Downloaded critical-section v1.2.0
  Downloaded fnv v1.0.7
  Downloaded bytemuck v1.25.2
  Downloaded form_urlencoded v1.2.2
  Downloaded futures-macro v0.3.34
  Downloaded futures-io v0.3.34
  Downloaded blake2 v0.11.0-rc.6
  Downloaded find-msvc-tools v0.1.11
  Downloaded funty v2.0.0
  Downloaded fdlimit v0.3.0
  Downloaded ff v0.14.0
  Downloaded foldhash v0.2.0
  Downloaded bon v3.9.3
  Downloaded fdeflate v0.3.7
  Downloaded darling_core v0.23.0
  Downloaded bon-macros v3.9.3

.... Compiling clap v4.6.6 Compiling tokio-util v0.7.19 Building [===============> ] 451/676: ecdsa, exr, yazi-shared, regex-automata,

'bs58' jumped out at me as a random looking package name.

It implements the base58 encoding, which is used primarily by... Bitcoin.

I'd love to see the explanation of why "a TUI file manager" needs a crate closely associated with crypto coins and not much else.

It is precisely this kind of thing that makes Rust a no-go for most enterprises.

"I just want a CLI tool."

"Congratulations, your servers are mining crypto!"

PS: bs58 is maintained by one anonymous person and their package is used in just about every Rust crypto library and hence application. Compromise his account in the same manner as the 'xz tools' attack and you could still billions in crypto!

It doesn't actually use it, this is just referencing it in the dependency graph (Cargo.lock). bs58 is an optional (feature-gated) transitive dependency of another crate, which is never referenced at all in the top-level crate. The build.rs doesn't run or anything.

I believe there's (several) open issues about changing this behavior of the lock file, but I have moved on from Rust so don't know the status of things.

That said, this is confusing behavior. I remember I first noticed it when a bunch of crates were showing up in my lock file for every OS under the sun, even though I was specifically using a "wayland" (linux-only) feature.

Not to defend Rust's crazy culture of dependencies, mind you.

The lockfile confusion/bug is indeed a thing, but OP is noting that b58 was downloaded, which makes me think it's actually used.

I ran in to the lockfile bug myself a day ago and noticed that dependency-feature-flagged-crates show up in Cargo.lock, but their crates aren't downloaded.

I don’t know anything about this particular tool. But I’ll note that comparing package counts often doesn’t make sense between ecosystems, since some ecosystems (like Rust) lean heavily towards workspace patterns where several “physical” packages make up one “logical” unit.

(Rust even enforces for proc macros, which is why so many of the crates in your example end with “derive” or “macros.”)

I use nnn[0], a C tui file manager, and from the makefiles, you mostly need

  readline
  pcre
  ncurses
  pthread
  and POSIX (and some unix thingies)

Which is why I love C projects, even with all the footguns. You have libraries with nice API that lets you write software without being on a treadmill to update the code every few months.

[0] https://github.com/jarun/nnn/

You can't imagine how much your example calls home!

https://github.com/hbbio/rc

In my opinion, library authors should really minimize the amount of dependencies they have. Back to TypeScript, we are also the authors of https://github.com/okcontract/cells and we made a point of almost not having dependencies or even devDependencies.

Yes this is the way to go. As few deps as possible.

Reply on news.ycombinator.com