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

511–520 of 593 posts

Re: Rust’s dependencies are starting to worry me

#511

Post by [deleted] »

procaryote wrote: post #86
delusional wrote: post #55

Earlier quoted context omitted.

I have a lot of sympathy for this viewpoint, but I also ask that we try to remind ourselves. We are asking for professionalism from hobby projects. If you want a mature protobuf implementation you should probably buy one. Expecting some guy/gal on the internet to maintain one for your for free seems ill advised.

Isn't that an argument _for_ having a "mature" label? To avoid the hobbyists who have no intention to maintain their thing? Also there are lots of lovely projects maintained at high levels by hobbyists, and plenty of abandonware that was at some point paid for

[deleted]

Re: Rust’s dependencies are starting to worry me

#512

Post by delusional »

procaryote wrote: post #86
delusional wrote: post #55

Earlier quoted context omitted.

I have a lot of sympathy for this viewpoint, but I also ask that we try to remind ourselves. We are asking for professionalism from hobby projects. If you want a mature protobuf implementation you should probably buy one. Expecting some guy/gal on the internet to maintain one for your for free seems ill advised.

Isn't that an argument _for_ having a "mature" label? To avoid the hobbyists who have no intention to maintain their thing? Also there are lots of lovely projects maintained at high levels by hobbyists, and plenty of abandonware that was at some point paid for

> Also there are lots of lovely projects maintained at high levels by hobbyists, and plenty of abandonware that was at some point paid for

There certainly are. I would never say to disregard anything because it was a hobby project. You just don't get to expect it being that way.

My basic point is that a hobby project can never take responsibility. If you have a support contract you are allowed to have some expectation of support. If you do not, then no expectation is warranted and everything you get is a gift.

A "mature" label carries the same problem. You are expecting the author to label something for you. That's work. If you're pulling from the commons, you must respect that people can label stuff whatever they like, and unmotivated blanket lies are not illegal.

Re: Rust’s dependencies are starting to worry me

#513

Post by tester756 »

arccy wrote: post #444
ak_111 wrote: post #422

Earlier quoted context omitted.

As poster dead deep in the thread below, something like this can happen doc_format = get_user_input() parsed_doc = foolib.parse(doc_format) You as the implementer might know the user will never input xml, so doc_format can't be 'xml' (you might even add some error handling if the user inputs this), but how can you communicate this to the compiler?

That's called bad library design. Rather than a global, make an instantiated parser that takes in specific codecs.

It aint matter, if format is comes from runtime then compiler will not know.

Re: Rust’s dependencies are starting to worry me

#514

Post by arp242 »

hu3 wrote: post #475
arp242 wrote: post #287

3.6M lines of code seems so much that it sets off my "are you sure that's counted right?" alarm. I'm not very familiar with Rust, but all of Go is 1.6M lines of Go code. This includes the compiler, stdlib, tests for it all: the lot. Not that I doubt the sincerity of the author of course, but maybe some irrelevant things are counted? Or things are counted more than once? Or the download tool does the wrong thing? Or t…

This other person wrote their own async runtime and web server from scratch to reduce bloat, and their rust app still vendors 2 million lines of code: https://news.ycombinator.com/item?id=43942055

Sounds like a lot is just (generated) syscall stuff? Either way, that doesn't really explain anything.

Re: Rust’s dependencies are starting to worry me

#515

Post by thayne »

kbolino wrote: post #506
djfivyvusn wrote: post #443

Earlier quoted context omitted.

I didn't understand the embedded systems argument. Just because a standard lib is large doesn't mean it all ends up in the compilation target.

Indeed, it has no bearing on binary size at all, because none of it will be included. If you are coming from the perspective where the standard library is entirely unusable to begin with, then improving the standard library is irrelevant at best. It also likely means that at least some time and effort will be taken away from improving the things that you can use to be spent on improving a bunch of things that you can…

> Indeed, it has no bearing on binary size at all, because none of it will be included.

That depends on the language. In an interpreted language (including JIT), or a language that depends on a dynamically linked runtime (ex c and c++), it isn't directly included in your app because it is part of the runtime. But you need the runtime installed, and if your app is the only thing that uses that runtime, then the runtime size is effectively adds to your installation size.

In languages that statically link the standard library, like go and rust, it absolutely does impact binary size, although the compiler might use some methods to try to avoid including parts of the standard library that aren't used.

Re: Rust’s dependencies are starting to worry me

#516

Post by hu3 »

arp242 wrote: post #514
hu3 wrote: post #475

Earlier quoted context omitted.

This other person wrote their own async runtime and web server from scratch to reduce bloat, and their rust app still vendors 2 million lines of code: https://news.ycombinator.com/item?id=43942055

Sounds like a lot is just (generated) syscall stuff? Either way, that doesn't really explain anything.

That's one part of Rust bloat and slow compilation times.

But there's still a ton of dependency code there.

Re: Rust’s dependencies are starting to worry me

#517

Post by ChocolateGod »

jampekka wrote: post #193
ChocolateGod wrote: post #173

Earlier quoted context omitted.

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.

Distro maintainers/packagers are who keep the current software stacks running. It's rather amazing how they manage to keep the billion or so lines of separately written code working in unison. That said, the labor needed to keep the stuff together could be reduced a lot by the more ergonomical and universal packaging and distribution methods like Cargo (and, dare I say, npm). I think some kind of a better bridge betw…

> > I think some kind of a better bridge between developers and distros could be found here.

Every tom dick and harry is making their own distro these days (even if they're just respins of Arch with Calamares and some questionable theme settings), why add more work onto developers?

We have things like Flatpak and Docker now that let application developers ignore the distros and stop them breaking things, unless you're Ubuntu whom is constantly begging to get purchased by Microsoft.

Re: Rust’s dependencies are starting to worry me

#518

Post by Aurornis »

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…

> Eventually you end up in a world where your simple binary is 500 MiB of code you never actually call,

It’s getting hard to take these conversations seriously with all of the hyperbole about things that don’t happen. Nobody is producing Rust binaries that hit 500MB or even 50MB from adding a couple simple dependencies.

You’re also not ending up with mountains of code that never gets called in Rust.

Even if my Rust binaries end up being 10MB instead of 1MB, it doesn’t really matter these days. It’s either going on a server platform where that amount of data is trivial or it’s going into an embedded device where the few extra megabytes aren’t really a big deal relative to all the other content that ends up on devices these days.

For truly space constrained systems there’s no-std and entire, albeit small, separate universe of packages that operate in that space.

For all the doom-saying, in Rust I haven’t encountered this excessive bloat problem some people fret about, even in projects with liberal use of dependencies.

Every time I read these threads I feel like the conversations get hijacked by the people at the intersection of “not invented here” and nostalgia for the good old days. Comments like this that yearn for the days of buying paid libraries and then picking them apart anyway really reinforce that idea. There’s also a lot of the usual disdain for async and even Rust itself throughout this comment section. Meanwhile it feels like there’s an entire other world of Rust developers who have just moved on and get work done, not caring for endless discussions about function coloring or rewriting libraries themselves to shave a few hundred kB off of their binaries.

Re: Rust’s dependencies are starting to worry me

#519

Post by shwouchk »

simonask wrote: post #326
blub wrote: post #308

Earlier quoted context omitted.

If something is in the standard library, then it’s written and vetted by the standard library provider, not by a random third party like you make it sound. With Rust, it’s literally a random third party.

Maintainers of all open source standard libraries are effectively "random third parties". With heavily used ecosystem dependencies (such as Tokio, but also swaths of small libraries, such as `futures` or `regex`), the number of people who have looked at the code and battle-tested it is also huge. On crates.io, a good heuristic is to look at two numbers: the number of dependents and the number of downloads. If both ar…

what other “quality” is there to worry about besides security?
Post reply on HN