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

431–440 of 593 posts

Re: Rust’s dependencies are starting to worry me

#431

Post by kokada »

zahlman wrote: post #275
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…

>A great std lib is obviously the solution. Some Rust defenders are talking it down by giving Python as counter example. Python's standard library is big . I wouldn't call it great, because Python is over 30 years old and it's hard to add things to a standard library and even harder to remove them.

While not everything in Python's stdlib is great (I am looking at you urllib), I would say most of it is good enough. Python is still my favorite language to get stuff done exactly because of that.

Re: Rust’s dependencies are starting to worry me

#432

Post by nicce »

zahlman wrote: post #275
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…

>A great std lib is obviously the solution. Some Rust defenders are talking it down by giving Python as counter example. Python's standard library is big . I wouldn't call it great, because Python is over 30 years old and it's hard to add things to a standard library and even harder to remove them.

Maybe Python 4 will just remove stuff.

Re: Rust’s dependencies are starting to worry me

#433

Post by nicce »

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…

> Procedural macros are often synonymous with slow compile times and code bloat.

In theory they should reduce it because you wouldn’t make proc macros to generate code you don’t need…right? How much coding time you save with macros compared to manually implementing them?

Re: Rust’s dependencies are starting to worry me

#434

Post by mexicocitinluez »

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…

> The problem I notice in npm land is many developers have no taste.

Programming is not the same as hanging out some hoity-toity art gallery. If someone critiqued my software dev by saying I had "no taste", I'd cringe so hard I'd turn into a black hole.

I know this is hackernews, but this reeks of self-importance.

Re: Rust’s dependencies are starting to worry me

#435

Post by fiedzia »

WuxiFingerHold wrote: post #271
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…

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

> but neither Go or C# have issues with dependency hell like Rust or even more JavaScript, because they have exceptional std libs

They also have a lot narrower scope of use, which means it is easier to create stdlib usable for most people. You can't do it with more generic language.

Re: Rust’s dependencies are starting to worry me

#436

Post by dgb23 »

mort96 wrote: post #423
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, 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.

Not all web servers deal in HTML or JSON, many don't have databases outside of managing their internal state.

Even ignoring that, those are just common formats. They don't tell you what a particular web server is doing.

Take a few examples of some Go projects that either are web servers or have them as major components like Caddy or Tailscale. Wildly different types of projects.

I guess one has to expand "web server" to include general networking as well, which is definitely a well supported use case or rather category for the Go std lib, which was my original point.

Re: Rust’s dependencies are starting to worry me

#437

Post by tome »

loglog wrote: post #325
notnullorvoid wrote: post #234

Earlier quoted context omitted.

I don't think you need to get very complex to design a language that protects libraries from having implicit system access. If the only place that can import system APIs is in the entry program, then by design libraries need to use dependency injection to facilitate explicit passing of capabilities. One can take just about any existing language and add this constraint, the problem however is it would break the existi…

If you want this today, Haskell might be the only choice.

Yes, there is a sense in which Haskell's "effect systems" are "capability systems". My effect system, Bluefin, models capabilities as values that you explicitly pass around. You can't do I/O unless you have the "IOE" capability, for example.

https://hackage.haskell.org/package/bluefin

Re: Rust’s dependencies are starting to worry me

#438

Post by silon42 »

sitkack wrote: post #224
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…

Way back when, I used to vendor all the libraries for a project (Java/Cpp/Python) into a mono repo and integrate building everything into the projects build files so anyone could rebuild the entire app stack with whatever compiler flags they wanted. It worked great, but it took diligence, it also forces you to interact with your deps in ways that adding a line to a deps file does not.

I would absolutely do this for any non-toy project.

Alternatively, for some project it might be enough to only depend on stuff provided by Debian stable or some other LTS distro.

Re: Rust’s dependencies are starting to worry me

#439

Post by tome »

lxpz wrote: post #331
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…

Doesn't Haskell do this to some degree with the IO monad? Functions that are not supposed to do IO directly simply have a more specific type signature, like taking in a stream and returning a buffer for example.

Yes, although it can be violated by unsafePerformIO and friends. Haskell's is not an "assured" system.

Re: Rust’s dependencies are starting to worry me

#440

Post by wizzwizz4 »

bsaul wrote: post #344
IshKebab wrote: post #338

Earlier quoted context omitted.

Yeah that's one huge advantage Rust has over NPM - Rust developers are a lot more skilled and crates are generally much higher quality.

Random remark: I've noticed the quality of rust libraries too. Which made me really surprised to see the overengineered mess that is the async-openai crate. how can one take an api as simple as openai's one, and turn it to this steaming pile of manure ? in the end, i used reqwest and created my queries manually. I guess that's what everyone does...

The kinds of people who think OpenAI's tech is worth touching with a bargepole are generally not the kinds of people who develop and maintain high-quality Rust libraries.
Post reply on HN