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

421–430 of 593 posts

Re: Rust’s dependencies are starting to worry me

#421

Post by nullc »

PoignardAzur wrote: post #388
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…

> At each level a caller might need 5% of the functionality of any given dependency. The deeper the dependency tree gets the more waste piles on. Eventually you end up in a world where your simple binary is 500 MiB of code you never actually call, but all you did was take that one dependency to format a number. I'm not convinced that happens that often. As someone working on a Rust library with a fairly heavy depende…

I was very 'impressed' to see multiple SSL libraries pulled into rust software that never makes a network connection.

Re: Rust’s dependencies are starting to worry me

#422

Post by ak_111 »

espoal wrote: post #414
ak_111 wrote: post #372

Earlier quoted context omitted.

"dependency" here I guess means something higher-level that your compiler can't make the assumption you will never use. For example you know you will never use one of the main functions in the parsing library with one of the arguments set to "XML", because you know for sure you don't use XML in your domain (for example you have a solid project constraint that says XML is out of scope). Unfortunately the code dealing…

Why the compiler can't detect it will not be used? Tree shaking is well implemented in Javascript compilers, an ecosystem which extensively suffer from this problem. It should be possible to build a dependency graph and analyze which functions might actually end up in the scope. After all the same is already done for closures.

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?

Re: Rust’s dependencies are starting to worry me

#423

Post by mort96 »

dgb23 wrote: post #380
athrowaway3z wrote: post #301

Earlier quoted context omitted.

No it doesn't. A large stdlib solves the problems the language is focused on. For C# and Go that is web hosts. Try using them outside that scope and the dependencies start to pile in (Games, Desktop) or they are essentially unused (embedded, phones, wasm)

“Web server” is a pretty big use case though. But I agree that graphics is often overlooked in std libs. However that’s a bit of a different beast. Std libs typically deal with what the OS provides. Graphics is its own world so to speak. As for Wasm: first, that’s a runtime issue and not a language issue. I think GC is on the roadmap for Wasm. Second, Go and C# obviously predate Wasm. In the end, not every language s…

"Web server" is, more or less, about converting a database into JSON and/or HTML. There are complexities there, sure, but it's not like it's some uniquely monumental undertaking compared to other fields.

Re: Rust’s dependencies are starting to worry me

#425

Post by nine_k »

bradley13 wrote: post #424

This is a general problem: devs pulling in libraries instead of writing a few lines of code. Those libraries pull in more dependencies that have even more dependencies. There's no good solution...

Why, offer a patch that introduces the few lines and removes a dependency.

Re: Rust’s dependencies are starting to worry me

#426

Post by tlb »

bradley13 wrote: post #424

This is a general problem: devs pulling in libraries instead of writing a few lines of code. Those libraries pull in more dependencies that have even more dependencies. There's no good solution...

LLM coding assistants are a partial solution. Recently I typed

  vec4 rgb2hsv(vec4 rbg)
and a few tab-completes later it had filled in the body of the code with a correct color conversion routine. So that saved me searching for and pulling in some big-ass color library.

Most of lodash.js can be avoided with LLMs too. Lodash's loops are easier to remember than Javascript's syntax, but if your LLM just writes the foo.forEach((value, key) => {...}) for you, you can skip the syntactic sugar library.

Re: Rust’s dependencies are starting to worry me

#427

Post by kibwen »

hedora wrote: post #243
andrepd wrote: post #216

Earlier quoted context omitted.

Dead code elimination means binary size bloat does not follow from dependency bloat. So this point is pretty much invalid for a compiled language like Rust.

Dead code elimination is exactly the same as the halting problem. It’s approximate (and hopefully conservative!) at best.

No, dead code elimination in a statically-dispatched language is not equivalent to the halting problem.

Re: Rust’s dependencies are starting to worry me

#428

Post by dev_l1x_be »

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 late Joe Armstrong had an idea about open source that it should be just a collection of functions that we publish. It would solve this problem.

Re: Rust’s dependencies are starting to worry me

#429

Post by nicce »

ffsm8 wrote: post #420
dgb23 wrote: post #380

Earlier quoted context omitted.

“Web server” is a pretty big use case though. But I agree that graphics is often overlooked in std libs. However that’s a bit of a different beast. Std libs typically deal with what the OS provides. Graphics is its own world so to speak. As for Wasm: first, that’s a runtime issue and not a language issue. I think GC is on the roadmap for Wasm. Second, Go and C# obviously predate Wasm. In the end, not every language s…

> “Web server” is a pretty big use case though. You don't consider games, desktop and mobile applications big use cases, each being multi billion industries? I don't know man, I feel like you're arguing in bad faith and are intentionally ignoring what the athrowaway3z said: it works there because they're essentially languages specifically made to enable web development . That's why their standard lib is plenty for th…

Web is likely bigger than all of those together. And large part of mobile and desktop apps depends on the web tech these days.

Re: Rust’s dependencies are starting to worry me

#430

Post by stevenhuang »

whstl wrote: post #396
akshitgaur2005 wrote: post #390

Earlier quoted context omitted.

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.

When talking about LTO we don't expect it to be removing code used in runtime. Such code is not dead code, by definition.

If you want to disable certain runtime features, you'd do so with feature flags.

Post reply on HN