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

411–420 of 593 posts

Re: Rust’s dependencies are starting to worry me

#411

Post by constantcrying »

kgeist wrote: post #378
constantcrying wrote: post #350

Earlier quoted context omitted.

And? Not every project had the same amount of resources. There is a tradeoff here. Having a large, but badly maintained, standard library with varying platform support is worse than having a smaller, but well maintained, one.

If you look at the numbers, Golang has 2000+ contributors, while Rust has 5000+ Golang's core dev team is something like 30 people. So Rust does have the resources.

The amount of contributors is a totally meaningless metric.

1. Not every contributor contributes equally. Some contributors work full time on the project, some work a few hours a month.

2. The amount of contributors says nothing about what resources are actually required. Rust is, no doubt, a more complex language than go and is also evolving faster.

3. The amount of contributors says nothing about the amount of contributors maintaining very niche parts of the ecosystem.

Re: Rust’s dependencies are starting to worry me

#412

Post by bob1029 »

Const-me wrote: post #408
Ygg2 wrote: post #330

Earlier quoted context omitted.

So it comes out of box with good renderers, physics engines, localization, input controllers and in-game GUIs?

The libraries you listed are too specialized. And they require integration with asset pipeline which is well outside of scope of a programming language. As for the generic things, I think C# is the only mainstream language which has small vectors, 3x2 and 4x4 matrices, and quaternions in the standard library.

> I think C# is the only mainstream language which has small vectors, 3x2 and 4x4 matrices, and quaternions in the standard library.

They've got SIMD-accelerated methods for calculating 3d projection matrices. No other ecosystem is even close once you start digging into the details.

Re: Rust’s dependencies are starting to worry me

#413

Post by constantcrying »

rs186 wrote: post #399
constantcrying wrote: post #345

Earlier quoted context omitted.

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'…

Why are you complaining that a project you do not care about is using 13 dependencies, all of which, to your knowledge, are absolutely essential for the functionality?

>There is a project that's 500kb in code with 120 dependencies

And therefore some project using 13 dependencies is doing it wrong? What are you on about. Obviously there is an enormous abuse of dependencies in the JS ecosystem, who cares?

Re: Rust’s dependencies are starting to worry me

#414

Post by espoal »

ak_111 wrote: post #372
tester756 wrote: post #362

Earlier quoted context omitted.

>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. So, what's is the compiler doing that he doesnt remove unused code?

"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.

Re: Rust’s dependencies are starting to worry me

#416

Post by YmiYugy »

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…

That's one hell of a task. First question is how fine-grained your capability system will be. Both in terms of capabilities and who they are granted for. Not fine-grained enough and everything will need everything, e.g. access to various clocks could be used to DoS you or as a side channel attack. Unsafe memory access might speed up your image parsing but kills all safety. Similar problems with scope. If per dependency, forces library authors to remove useful functionality or break up their library into tiny pieces. If per function and module you'll have a hard time auditing it all. Lastly, it's a huge burden on devs to accurately communicate why their library/function needs a specific capability. We know from JavaScript engines, containerization and WASM runtimes what's actually required for running untrusted code. The overhead is just to large to do it for each function call.

Re: Rust’s dependencies are starting to worry me

#417

Post by morsecodist »

I see a lot of concern like this about dependencies, mostly in node. I'm sure it's an issue I'm just not convinced it's as big of a problem as people say. We have scanners that can help keep your dependencies secure automatically. If you take a dependency and it goes unmaintained is it really that much worse than the relevant code in your own codebase going unmaintained?

Re: Rust’s dependencies are starting to worry me

#418

Post by tialaramex »

blub wrote: post #308
tialaramex wrote: post #188

Earlier quoted context omitted.

With C++ it's hilarious because the C++ community is so allergic to proper dependency management and also so desperate for stuff from third party libraries that the committee spends large amounts of its time basically doing dependency management for the community by baking in large features you'd ordinarily take as a dependency into the mandatory standard library. I'm sure I'll miss some, but IIRC C++ 26 is getting t…

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.

> it’s written and vetted by the standard library provider, not by a random third party

All three modern C++ standard libraries are of course Free Software. They are respectively the GNU libstdc++, Clang's libc++ and the Microsoft STL. Because it's a huge sprawling library, you quickly leave the expertise of the paid maintainers and you're into code that some volunteer wrote for them and says it's good. Sounds like random third parties to me.

Now, I'm sure that Stephan T. Lavavej (the Microsoft employee who looks after the STL, yes, nominative determinism) is a smart and attentive maintainer, and so if you provide a contribution with a function named "_Upload_admin_creds_to_drop_box" he's not going to apply that but equally Stephen isn't inhumanly good, so subtle tricks might well get past him. Similar thoughts apply to the GNU and Clang maintainers who don't have funny names.

Re: Rust’s dependencies are starting to worry me

#419

Post by rcxdude »

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.

It's not a case of 'learning to do it properly', it's a case of a huge amount of effort to deal with arbitrary differences between distros, as well as fighting with distro policies that would rather ship the software with known bugs than allow two versions of a library to exist on the system.

Re: Rust’s dependencies are starting to worry me

#420

Post by ffsm8 »

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 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 this domain.

I can understand that web development might be the only thing you care about though, it's definitely a large industry - but the thesis of a large standard lib solving the dependency issue really isnt true, as (almost) every other usecase beyond web development shows.

Post reply on HN