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

391–400 of 593 posts

Re: Rust’s dependencies are starting to worry me

#391

Post by whstl »

iTokio wrote: post #300
WuxiFingerHold wrote: post #271

Earlier quoted context omitted.

> 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. Go and C# (.NET) are counterexamples. They both have great ecosystems and just as simple and effective package management as Rust or JS (Node). But neither Go or C# have issues with dependency hell like Rust or even more JavaScript, because they have exceptional std libs a…

I think this is partially true, but more nuanced than just saying that Rust std lib is lacking. Compared to go and c#, Rust std lib is mostly lacking: - a powerful http lib - serialization But Rust approach, no Runtime, no GC, no Reflection, is making it very hard to provide those libraries. Within these constraints, some high quality solutions emerged, Tokio, Serde. But they pioneered some novel approaches which wou…

I would say compared to other languages Rust feels even more lacking.

All those AFAIR need 3rd party packages:

Regex, DateTime, base64, argument parsing, url parsing, hashing, random number generation, UUIDs, JSON

I'm not saying it's mandatory, but I would expect all those to be in the standard library before there is any http functionality.

Re: Rust’s dependencies are starting to worry me

#392

Post by jll29 »

socalgal2 wrote: post #214

I'm curious if rust has this problem. The problem I notice in npm land is many developers have no taste. Example, there's a library for globbing call glob. You'd think it would just be a function that does globbing but no, the author decided it should ALSO be a standalone commandline executable and so includes a large commandline option parser. They could have easily made a separate commandline tool that include a li…

> I can't imagine it's any different in [R]ust land

Taste is important; programmers with good architectural taste tend to use languages that support them in their endeavour (like Rust or Zig) or at least get out of the way (C).

So I would argue the problems you list are statistically less often the case than in certain other languages (from COBOL to JavaScript).

> There's just too many devs and all of them, including myself, don't always make the best choices.

This point you raise is important: I think an uncoordinated crowd of developers will create a "pile of crates" ("bazaar" approach, in Eric Raymond's terminology), and a single language designer with experience will create a more uniform class library ("cathedral" approach).

Personally, I wish Rust had more of a "batteries included" standard library with systematically named and namespaced official crates (e.g. including all major data structures) - why not "stdlib::data_structures::automata::weighted_finite_state_transducer" instead of a confusing set of choices named "rustfst-ffi", "wfst", ... ?

Ideally, such a standard library should come with the language at release. But the good news is it could still be devised later, because the Rust language designers were smart enough to build versioning with full backwards compatibility (but not technical debt) into the language itself. My wish for Rust 2030 would be such a stdlib (it could even be implemented using the bazaar of present-day crates, as long as that is hidden from us).

Re: Rust’s dependencies are starting to worry me

#393

Post by panstromek »

sitta wrote: post #233

I recently wrote an extremely basic Rust web service using Axum. It had 10 direct dependencies for a total of 121 resolved dependencies. I later rewrote the service in Java using Jetty. It had 3 direct dependencies for a total of 7 resolved dependencies. Absolutely nuts.

I don't think number of dependencies is a useful comparison metric here. Java runtime already implements stuff that you have to use libraries for in Rust, and it's a design choice. Rust also has slimmer std. Both languages have different constraints for this.

Re: Rust’s dependencies are starting to worry me

#394

Post by whstl »

tester756 wrote: post #373
sph wrote: post #370

Earlier quoted context omitted.

A surprising amount of code might be executed in rarely-used or undocumented code paths (for example, if the DEBUG environment variable is 1 or because a plugin is enabled even if not actually used) and thus not shaken out by the compiler.

What makes you think that a lot of code is hidden behind dbg env variable instead of e.g dbg build?

Plenty of libraries have "verbose" logging flags ship way more than assumed. I remember lots of NPM libs that require `winston` for example are runtime-configurable. Or Java libraries that require Log4J. With Rust it's getting hard to remember because everything today seems to pull the fucking kitchen sink...

And even going beyond "debug", plenty of libraries ship features that are downright unwanted by consumers.

The two famous recent examples are Heartbleed and Log4shell.

Re: Rust’s dependencies are starting to worry me

#395

Post by j1elo »

conradludgate wrote: post #105
nemothekid wrote: post #43

I feel like leftpad has given package managers a very bad name. I understand the OP's hesitation, but it feels a little ridiculous to me. tokio is a work-stealing, asynchronous runtime. This is a feature that would be an entire language . Does OP consider it reasonable to audit the entire Go language? or the V8 engine for Node? v8 is ~10x more lines than tokio. If Cloudflare uses Node, would you expect Cloudflare to…

And for what it's worth, people do audit tokio. I have audited tokio. Many times in fact. Sure, not everyone will, but someone will :)

How does one approach doing so? Do you open the main.rs file (or whichever is the entry point) and start reading code and referenced functions on a breadth-first search (BFS) manner?

Re: Rust’s dependencies are starting to worry me

#396

Post by whstl »

akshitgaur2005 wrote: post #390
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 am just a college student, so sorry if this is stupid, but we know that Rust compiler can detect unused code, variables, functions and all, as can IDE's for all languages, then why don't we just remove those parts? The unused code is just not compiled.

Mainly because in some libs some code is activated at runtime.

A lot of the bloat comes from functionality that can be activated via flags, methods that set a variable to true, environment variables, or even via configuration files.

Re: Rust’s dependencies are starting to worry me

#397

Post by kouteiheika »

whstl wrote: post #391
iTokio wrote: post #300

Earlier quoted context omitted.

I think this is partially true, but more nuanced than just saying that Rust std lib is lacking. Compared to go and c#, Rust std lib is mostly lacking: - a powerful http lib - serialization But Rust approach, no Runtime, no GC, no Reflection, is making it very hard to provide those libraries. Within these constraints, some high quality solutions emerged, Tokio, Serde. But they pioneered some novel approaches which wou…

I would say compared to other languages Rust feels even more lacking. All those AFAIR need 3rd party packages: Regex, DateTime, base64, argument parsing, url parsing, hashing, random number generation, UUIDs, JSON I'm not saying it's mandatory, but I would expect all those to be in the standard library before there is any http functionality.

> All those AFAIR need 3rd party packages: Regex

Regex is not 3rd party (note the 'rust-lang' in the URL):

https://github.com/rust-lang/regex

Re: Rust’s dependencies are starting to worry me

#398

Post by whstl »

f_devd wrote: post #226
rafram wrote: post #197

Earlier quoted context omitted.

let uri = get_uri_from_stdin(); networking_library::make_request(uri); How is the compiler supposed to prune that?

let uri: Uri = get_uri_from_stdin().parse()?; If the library is made in a modular way this is how it would typically be done. The `HTTP` may be inferred by calls further along in the function.

So what happens if the user passes an url containing ftp:// or even https:// to stdin? Or is this an HTTP only library?

Re: Rust’s dependencies are starting to worry me

#399

Post by rs186 »

constantcrying wrote: post #345
rs186 wrote: post #181

Earlier quoted context omitted.

I don't think there is any point in debating this, because apparently you are in the camp of "dependencies are ok", with or without a good reason, when a different camp is "avoid dependencies unless you really have to". You just provided an example of why dependencies explode like this. > And because you can't see a reason there is none? Somehow every other JS based parser doesn't do fancy serialization, as far as I…

You are just making stuff up. You still can not articulate why these dependencies are unnecessary. That you in particular might have no use for the features they bring couldn't be more irrelevant. What other parsers are doing could also not be more irrelevant.

> You still can not articulate why these dependencies are unnecessary.

No, because I don't have to answer that question. I can simply choose not to use this project, like what I do with npm projects. There is a project that's 500kb in code with 120 dependencies, when another one is 100kb with 10 dependencies that's also well maintained? I'll choose the latter without question, as long as it satisfies my needs. I don't care why the other one has 120 dependencies or try to justify that.

Re: Rust’s dependencies are starting to worry me

#400

Post by f_devd »

whstl wrote: post #398
f_devd wrote: post #226

Earlier quoted context omitted.

let uri: Uri = get_uri_from_stdin().parse()?; If the library is made in a modular way this is how it would typically be done. The `HTTP` may be inferred by calls further along in the function.

So what happens if the user passes an url containing ftp:// or even https:// to stdin? Or is this an HTTP only library?

Depends on what is desired, in this case it would fail (through the `?`), and report it's not a valid HTTP Uri. This would be for a generic parsing library that allows for multiple schemes to be parsed each with their own parsing rules.

If you want to mix schemes you would need to be able to handle all schemes; you can either go through all variations (through the same generics) you want to test or just just accept that you need a full URI parser and lose the generic.

Post reply on HN