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

Rust’s dependencies are starting to worry me

vincents.dev

Post reply on HN
Print view View original

171–180 of 593 posts

Re: Rust’s dependencies are starting to worry me

#171

Post by dathinab »

wofo wrote: post #27
neilv wrote: post #19

In the past (not in Rust, but other languages), for important systems, I've instituted policies of minimizing dependencies from these language-specific package repositories, and for the ones you do use, having to copy it to our own repos and audit each update before use. But that's not practical for all situations. For example, Web frontend developer culture might be the worst environment, to the point you often can'…

There are some voices trying to address this security risk (e.g. the proponents of this new RFC: https://github.com/rust-lang/rfcs/pull/3810 ). However, for some reason (probably culture) there isn't much momentum yet to change the status quo.

> isn't much momentum yet to change the status quo.

it's complex problem with tons of partial solutions which each have tons of ways to implement them with often their no being a clear winner

i.e. it's the kind of hard to solve by consensus problem

e.g. the idea of a extended standard library is old (around since the beginning of rust) but for years it was believed it's probably the best to make it a separate independent project/library for various reason. One being that the saying "the standard library is the place where code goes to die" has been quite true for multiple ecosystems (most noticeably python)

as a side note ESL wouldn't reduce the LOC count it would increase it as long as you fully measure LOCs and not "skip" over some dependencies

Re: Rust’s dependencies are starting to worry me

#172

Post by api »

XxiXx wrote: post #14

I think it's a "cultural" thing. With Go you often find developers/projects proudly mentioning that any or just a few non-std dependencies are used. Coming from Go it really feels strange when you see pages of dependencies scrolling over your screen when you build a Rust project.

Go has a fatter standard library and a "fat" runtime with built-in green threads (an asynchronous runtime basically) and garbage collection, so you get more out of the box and thus end up using fewer dependencies.

Re: Rust’s dependencies are starting to worry me

#173

Post by ChocolateGod »

skydhash wrote: post #88
ChocolateGod wrote: post #28

Earlier quoted context omitted.

The whole pkgconfig, cmake, autotools etc ecosystem is insane compared to how Rust and Go do things. It's part of the reason why software distribution on Linux has been pushed to using containers, removing the point of having shared libraries. I think Google with it's C++ replacement (Carbon) plans on doing it's own system.

From my point of view, the issue stems from developers wanting to control distribution. Fine if it's for your own usage, not really if you're planning for others to use it. You will find the most convoluted build system just because they have a pet platform they want to specially support making it hell to do anything on others. It could be better, but the current solutions (npm, go, python,...) favor only the develop…

There's examples of maintainers/packagers effectively sabotaging other peoples projects when making packages for distros, whether that's shipping them broken, ancient versions etc.

e.g. Bottles, WebkitGTK (distros liked keeping this one held back even though doing so is a security risk)

IMHO it shouldn't be the responsibility of the OS vendor to package third party applications.

Re: Rust’s dependencies are starting to worry me

#174

Post by palata »

MeetingsBrowser wrote: post #83
antonvs wrote: post #17

Earlier quoted context omitted.

> Sure, but that means I won't write my project, because I won't write those things from scratch. You need to think a bit harder about that, to help you decide whether your position is rational.

This confuses me as well. Is the implied solution to choose a language where you are forced to write those things from scratch?

My point is that if, in the language, everybody is incentivise to use fewer dependencies, then a random library that I would not write myself (because it is an entire project in itself) would have fewer dependencies. Because it is not the case, either I take that library and accept its transitive dependencies, or I don't have a library at all.

In Rust, I'm sometimes actually tempted to wrap a C/C++ library (and its few dependencies) instead of getting the Rust alternative (and its gazillion dependencies).

Re: Rust’s dependencies are starting to worry me

#175

Post by KennyBlanken »

kion wrote: post #85

IMO any system where taking a dependency is "easy" and there is no penalty for size or cost is going to eventually lead to a dependency problem. That's essentially where we are today both in language repositories for OSS languages and private monorepos. This is partly due to how we've distributed software over the last 40 years. In the 80s the idea of a library of functionality was something you paid for, and painsta…

I can't remember the last time I saw someone so conclusively demonstrate they know nothing about the basics of how libraries, compilers, and linkers work.

Re: Rust’s dependencies are starting to worry me

#176

Post by palata »

antonvs wrote: post #17
palata wrote: post #3

Similar feeling here. Cargo makes it so simple to add tons of dependencies that it is really hard not to do it. But that does not stop here: even if I try to be careful with adding dependencies, a couple dependencies are likely to pull tens of transitive dependencies each. "Then don't depend on them", you say. Sure, but that means I won't write my project, because I won't write those things from scratch. I could prob…

> Sure, but that means I won't write my project, because I won't write those things from scratch. You need to think a bit harder about that, to help you decide whether your position is rational.

And you need to think a bit about that (probably not very hard), to help you decide whether I'm irrational or whether you may not have totally understood my point.

Re: Rust’s dependencies are starting to worry me

#177

Post by palata »

imtringued wrote: post #45
palata wrote: post #3

Similar feeling here. Cargo makes it so simple to add tons of dependencies that it is really hard not to do it. But that does not stop here: even if I try to be careful with adding dependencies, a couple dependencies are likely to pull tens of transitive dependencies each. "Then don't depend on them", you say. Sure, but that means I won't write my project, because I won't write those things from scratch. I could prob…

I have been wasting 6 hours yesterday on getting the bullet examples to compile outside of bullet itself with no success. It's more likely that a lot of software simply doesn't get written because C++ and CMake are a pain in the ass.

I find CMake pretty easy, and I only use a few core features from it. Usually the pain comes from completely wrong setups by people who didn't learn the basic. But it's true of everything, I think.

Re: Rust’s dependencies are starting to worry me

#178

Post by KennyBlanken »

kibwen wrote: post #114
kion wrote: post #85

IMO any system where taking a dependency is "easy" and there is no penalty for size or cost is going to eventually lead to a dependency problem. That's essentially where we are today both in language repositories for OSS languages and private monorepos. This is partly due to how we've distributed software over the last 40 years. In the 80s the idea of a library of functionality was something you paid for, and painsta…

> In some cases the languages make this worse. Go and Rust, for example, encourage everything for a single package/mod to go in the same file. What? I don't know about Go, but this certainly isn't true in Rust. Rust has great support for fine-grained imports via Cargo's ability to split up an API via crate features.

[flagged]

Re: Rust’s dependencies are starting to worry me

#179

Post by ruraljuror »

kion wrote: post #85

IMO any system where taking a dependency is "easy" and there is no penalty for size or cost is going to eventually lead to a dependency problem. That's essentially where we are today both in language repositories for OSS languages and private monorepos. This is partly due to how we've distributed software over the last 40 years. In the 80s the idea of a library of functionality was something you paid for, and painsta…

The actual behavior of go seems much closer to your ideal scenario than what you attribute to it. Although it is more nuanced, so both are true. In go, a module is a collection of packages. When you go get a module, the entire module is pulled onto the host, but when you vendor only the packages you use (and i believe only the symbols used from that package, but am not certain) are vendored to your module as dependencies.

Re: Rust’s dependencies are starting to worry me

#180

Post by jampekka »

palata wrote: post #170
ChocolateGod wrote: post #28

Earlier quoted context omitted.

The whole pkgconfig, cmake, autotools etc ecosystem is insane compared to how Rust and Go do things. It's part of the reason why software distribution on Linux has been pushed to using containers, removing the point of having shared libraries. I think Google with it's C++ replacement (Carbon) plans on doing it's own system.

> It's part of the reason why software distribution on Linux has been pushed to using containers My understanding of people distributing their software in containers is that they can't be arsed to learn how to do it properly. They would install their software and ship the entire computer if that was cost effective.

What needs to be "learned properly" is sadly a huge pile of incoherent legacy cruft that ideally wouldn't be there at all.

This is not to denigrate the huge and critical effort that makes current computing possible, and that is likely unavoidable in the real world. But software distribution needs to evolve.

Post reply on HN