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

161–170 of 593 posts

Re: Rust’s dependencies are starting to worry me

#161

Post by eikenberry »

jerf wrote: post #29

A true enough statement, but "Rust" is unnecessarily specific. Dependencies are getting scary in general. Supply chain attacks are no longer hypothetical, they're here and have been for a while. If I were designing a new language I think I'd be very interested in putting some sort of capability system in so I can confine entire library trees safely, and libraries can volunteer somehow what capabilities they need/offe…

> I think it would need to be a new language [..]

Languages (plural) ... no single language will work for everyone.

Re: Rust’s dependencies are starting to worry me

#162

Post by api »

poincaredisk wrote: post #142
nicoburns wrote: post #90

Earlier quoted context omitted.

As far as I'm aware, LTO completely solves this from a binary size perspective. It will optimise out anything unused. You can still get hit from a build time perspective though.

"completely solves" is a bit of an overstatement. Imagine a curl-like library that allows you to make requests by URL. You may only ever use HTTP urls, but code for all the other schemas (like HTTPS, FTP, Gopher) needs to be compiled in as well. This is an extreme example, but the same thing happens very often at a smaller scale. Optional functionality can't always be removed statically.

That's a consequence of crufty complicated protocols and standards that require a ton of support for different transports and backward compatibility. It's hard to avoid if you want to interoperate with the whole world.

Re: Rust’s dependencies are starting to worry me

#163

Post by dathinab »

kion wrote: post #104
dcow wrote: post #100

Earlier quoted context omitted.

Further: I’ve never seen rust encourage anything of the sort. Module directory with a mod.rs and any number of files works just fine.

I probably mischaracterized this as its been a while since I did more than trivial Rust. AFAIK its not possible to depend on only a part of a module in Rust though right? (At least without an external build system) For example, you can't split up a module into foo.rs containing `Foo` and bar.rs containing `Bar`, both in module 'mymod' in such a way that you can `use mymod::Bar and foo.rs is never built/linked. My poi…

> not possible to depend on only a part of a module in Rust though right

yesn't, you can use feature flags similar to `#if` in C

but it's also not really a needed feature as dead code elimination will prune out all code functions, types, etc. you don't use. Non of it will end up in the produced binary.

Re: Rust’s dependencies are starting to worry me

#164

Post by constantcrying »

rs186 wrote: post #152
constantcrying wrote: post #149

Earlier quoted context omitted.

I am counting 13 dependencies, the rest are internal ones. Are any of these superfluous or only needed for small edge cases? Serde seems exactly a case where you absolutely should use an external dependency. Also, repository size seems an extremely irrelevant metric.

13 > 12 so over a dozen dependencies. If you look at acorn or babel/parser, they barely have any dependency. Repository size is directly related to how long it takes to run a build, which is extremely important if I were to contribute to the project. > Serde seems exactly a case where you absolutely should use an external dependency. I can't see any reason a parser has a hard dependency on a serialization library.

>13 > 12 so over a dozen dependencies. If you look at acorn or babel/parser, they barely have any dependency.

Which ones are superfluous?

There are good reasons to use dependencies. If someone has solved a problem you need to solve as well it is pointless to duplicate the effort.

>Repository size is directly related to how long it takes to run a build, which is extremely important if I were to contribute to the project.

Totally false. There is zero inherent relation.

>I can't see any reason a parser has a hard dependency on a serialization library.

And because you can't see a reason there is none?

It is totally meaningless to talk about any of this if you can not point out why this is superfluous.

Re: Rust’s dependencies are starting to worry me

#165

Post by int_19h »

Alupis wrote: post #93
dralley wrote: post #6

Earlier quoted context omitted.

There should be a second stdlib with relaxed stability guarantees. Don't fill the normal stdlib full of cruft that can never be changed again.

So we reinvent Java's bloated SDK again, with all of the "javax" packages. What's old is new?

Well, it turned out that the alternative is even worse, so... let's chalk it down to learning experience.

Re: Rust’s dependencies are starting to worry me

#166

Post by palata »

eikenberry wrote: post #158
pjmlp wrote: post #132

Earlier quoted context omitted.

It was more like no one used them correctly .

Wouldn't that mean they were poorly implemented. If no one uses something correctly, seems like that isn't a problem with the people but the thing.

I don't think so. Software is maybe the only "engineering" discipline where it is considered okay to use mainstream tools incorrectly and then blame the tools.

Re: Rust’s dependencies are starting to worry me

#168

Post by jongjong »

zaptheimpaler wrote: post #111

This is just a modern problem in all software development, regardless of language. We are doing more complex things, we have a much bigger library of existing code to draw from and there are many reasons to use it. Ultimately a dependency is untrusted code, and there's a long road to go in hardening entire systems to make running arbitrary dependencies safe (if its even possible). In the absence of a technical soluti…

Yes, but a lot of the complexity is unnecessary bloat. Almost every project I've ever seen or worked on was full of unnecessary complexity. People naturally tend to over-complicate things, all the programming books, including software design books focus on unimportant aspects and miss all the important ones. It's incredibly frustrating.

Yet, if someone were to write a book which explained things properly (probably a 3000 word article would suffice to turn anyone into a 10x dev), nobody would buy it. This industry is cooked.

Re: Rust’s dependencies are starting to worry me

#169

Post by palata »

X0Refraction wrote: post #30
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…

This was linked from the top comment on the Rust subreddit: https://wiki.alopex.li/LetsBeRealAboutDependencies I think it makes a good point that some of the difference here is just perception due to dependencies in C/C++ being less immediately visible since they're dynamically loaded. To some degree that is a plus though as you likely trust the maintainers of your OS distribution to provide stable, supported librari…

> some of the difference here is just perception due to dependencies in C/C++ being less immediately visible since they're dynamically loaded.

Not in my case. I manually compile all the dependencies (either because I need to cross-compile, or because I may need to patch them, etc). So I clearly see all the transitive dependencies I need in C++. And I need a lot less than in Rust, by a long shot.

Re: Rust’s dependencies are starting to worry me

#170

Post by palata »

ChocolateGod wrote: post #28
jampekka wrote: post #11

Earlier quoted context omitted.

I take bit less unstable dependencies over the total mess of C++ dependencies with CMake, shared libraries, version conflicts etc any time. There's probably also a bit of an illusion about C++ transitive dependencies due to them usually being precompiled (because compiling them is such pain).

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.

Post reply on HN