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

581–590 of 593 posts

Re: Rust’s dependencies are starting to worry me

#581

Post by FredPret »

mexicocitinluez wrote: post #571
FredPret wrote: post #463

Earlier quoted context omitted.

Engineering is a form of art where the engineer makes many decisions, large and small, where optimality cannot be proven. Taste most certainly plays a role, and there are engineering products that clearly show good or poor taste. Unfortunately this particular art form requires fluency in mathematics and the sciences/computers, so it’s very inaccessible.

> Taste most certainly plays a role, and there are engineering products that clearly show good or poor taste. No. Get over yourself.

Wow, I’m convinced!

In all seriousness: why do you insist on an intellectual totem pole with art being more “hoity toity” as you say, and more worthy? And if so, why is engineering below painting?

In mathematics and some hard sciences, and in absolutely elementary aspects of other fields like programming, things can be proven to be right or wrong. In every other endeavour, we need to repeatedly apply fuzzy judgements.

Some do this poorly, some do it well.

Just in case you actually are interested in nuance, here’s some more on the topic:

https://www.paulgraham.com/hp.html

https://nealstephenson.substack.com/p/idea-having-is-not-art

Re: Rust’s dependencies are starting to worry me

#582

Post by mleonhard »

bsaul wrote: post #354
mleonhard wrote: post #215

> I can't rewrite the world, an async runtime and web server are just too difficult and take to long for me to justify writing for a project like this (although I should eventually just for a better understanding). I did this and it only solved half of the bloat: https://crates.io/crates/safina - Safe async runtime, 6k lines https://crates.io/crates/servlin - Modular HTTP server library, threaded handlers and async p…

I've come to accept that i wasn't really developing in "rust", but in "tokio-rust", and stopped worrying about async everywhere (it's not fundamentally different from what happens with other lang having async). Why the need for going back to threaded development ?

1. Async Rust is extra stuff for engineers to learn and maintain in their heads.

2. Async Rust has a lot of papercuts.

3. Very little code actually needs async. For example, in an API server, every request handler will need a database connection so the concurrency is limited by the database.

I wrote the Servlin HTTP server in async rust, to handle slow clients, but it calls threaded request handlers.

Re: Rust’s dependencies are starting to worry me

#583

Post by immibis »

amiga386 wrote: post #385
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…

> Its super easy to say `import foolib`, then call `foolib.do_thing()` and just start running. It's effectively an end-run around the linker. It used to be that you'd create a library by having each function in its own compilation unit, you'd create a ".o" file, then you'd bunch them together in a ".a" archive. When someone else is compiling their code, and they need the do_thing() function, the linker sees it's unfu…

foolib is the name of the library, not an object.

It also happens to be an object, but that's just because python is a dynamic language and libraries are objects. The C++ equivalent is foolib::do_thing(); where foolib is not an object.

Re: Rust’s dependencies are starting to worry me

#584

Post by int_19h »

Alupis wrote: post #218
int_19h wrote: post #165

Earlier quoted context omitted.

Well, it turned out that the alternative is even worse, so... let's chalk it down to learning experience.

I'm outside of the Rust community, so my two cents are worthless - but in this thread it seems a lot of people are actually wanting a defacto app framework, not necessarily a bloated "kitchen sink" style stdlib. The stdlib probably should remain simple, in my opinion. The complexity should be optional.

No, we specifically want stdlib and not an app framework.

The problem with third party frameworks is that by definition (of being third party) there's no single standard one to use, so libraries use different ones, and then you end up with a mess of dependencies, or else multiple incompatible ecosystems, each duplicating the same functionality around a different framework.

The beauty of stdlib is that it's guaranteed to be there, meaning that any library can use it as needed. It also improves interop between libraries because the same concepts are represented by the same standard types. And even when parts of stdlib are optional - which by necessity they must be for any "batteries included" stdlib because e.g. embedded is a thing - it's still beneficial to library authors because they know that, for any given feature, all supported platforms that do have it have stdlib expose it in the same way.

Re: Rust’s dependencies are starting to worry me

#585

Post by taeric »

dietr1ch wrote: post #541
taeric wrote: post #144

Earlier quoted context omitted.

I agree that I don't like thinking of libraries as the problem. But they do seem to be the easiest area to point at for a lot of modern development hell. Is kind of crazy. I'll note that it isn't just PGO/BOLT style optimizations. Largely, it is not that at all, oddly. Instead, the problem is one of stability. In a "foundation that doesn't move and cause you to fall over" sense of the word. Consider if people made a…

> Instead, the problem is one of stability. In a "foundation that doesn't move and cause you to fall over" sense of the word. Consider if people made a house where every room had a different substructure under it. That, largely, seems to be the general approach we use to building software. The idea being that you can namespace a room away from other rooms and not have any care on what happens there. I'm not sure what…

Stability in that you don't want to take on a dependency that will throw a migration at you within the next decade. Or longer. You also don't want one that will introduce enabled sweeping features in the common path.

Examples: Google's Guava for the migration department. Apache Commons would be a good example of how not to make life painful for users there.

For sweeping features, Log4j introduced some pretty terrible security concerns.

Re: Rust’s dependencies are starting to worry me

#586

Post by taeric »

dietr1ch wrote: post #540
taeric wrote: post #144

Earlier quoted context omitted.

I agree that I don't like thinking of libraries as the problem. But they do seem to be the easiest area to point at for a lot of modern development hell. Is kind of crazy. I'll note that it isn't just PGO/BOLT style optimizations. Largely, it is not that at all, oddly. Instead, the problem is one of stability. In a "foundation that doesn't move and cause you to fall over" sense of the word. Consider if people made a…

> I'll note that it isn't just PGO/BOLT style optimizations. Largely, it is not that at all, oddly. Well, it's not required to trim code that you can prove unreachable, true. But I was thinking about trying to measure if a given library really pulls it's non-zero weight, and how much CPU is spent in it. A library taking "too much time" for something you think can be done faster might need replacement, or swapping for…

Fully agreed in that this can be heavily subjective. And some things are flat out difficult with no real way of saying what is "too big."

My point on PGO/BOLT not being relevant was more that I see people reaching for libraries to do things such as add retries to a system. I don't think it is a terrible idea, necessarily, but it can be bad when combined with larger "retries plus some other stuff" libraries.

Now, fully granted that it can also be bad when you have developers reimplementing complicated data structures left and right. There has to be some sort of tradeoff calculation. I don't know that we have fully nailed it down, yet.

Re: Rust’s dependencies are starting to worry me

#587

Post by vacuity »

yubblegum wrote: post #575
vacuity wrote: post #570

Earlier quoted context omitted.

> With components and APIs, unless we resort to some universal baseline (such as a small finite semantic API like REST's "verbs") that basically can marshall and unmarshall any arbitrary function call ('do (func, context, in-args, out-args, out-err)' the Lego metaphor break down very quickly. I agree that this is generally what happens, and I would like to suggest that there is a better, harder road we should be taki…

> I agree, which is why I want us to separate the baseline components from more powerful abstractions, leaving the former for the machine (the framework) and the latter for us. Does the limited scope of HTTP by itself mean we shouldn't be able to provide more semantically appropriate interfaces for services? The real issue is that those interfaces are hard to standardize, not that people don't make them. We're likely…

I guess I'm rather invested in continuing to fight against the tide. Thank you for the discussion; it's given me things to think about.

Re: Rust’s dependencies are starting to worry me

#588

Post by LtdJorge »

voidnap wrote: post #563
FuckButtons wrote: post #367

Earlier quoted context omitted.

You can, but there’s always a tradeoff, as soon as I’ve added about the 3rd argument, I always wish i had grabbed a library, because i’m not getting payed to reinvent this wheel.

Sure. And thats how you get leftpad and dependency "supply chain" drama.

Are you really comparing clap with leftpad?

Re: Rust’s dependencies are starting to worry me

#589

Post by deepsun »

bonzini wrote: post #565
deepsun wrote: post #508

Earlier quoted context omitted.

No, there were never several unofficial libraries, one of which eventually won the popularity contest. There was always only one official. There is some barrier to add your project there, so might be that helped. It's even more pronounced with the main Java competitor: .Net. They look at what approach won in Java ecosystem and go all in. For example there were multiple ORM tools competing, where Microsoft adopted the…

> Microsoft adopted the most popular one That's still consolidation, and it also needs time. Even in Rust crates like hashbrown or parkinglot have been basically subsumed in the standard library.

Agree, after I thought for more examples. Thanks, don't know why others downvote.

Besides consolidation point, I still think that "barrier to entry" point is still valid -- if it's more effort to even publish a library, its author is probably more committed already.

Re: Rust’s dependencies are starting to worry me

#590

Post by dsr_ »

shwouchk wrote: post #528
dsr_ wrote: post #499

Earlier quoted context omitted.

You understand the problem clearly, but you haven't put your finger on the solution. It's an obvious one, but distasteful to many people.

Perhaps the distaste is blinding me. Would you care to state the obvious very clearly, for the dense ones among us?

"The dependency trees for most interpreted or source-distributed languages are ridiculous,"

Therefore, you must only use software for which the dependency trees are not ridiculous.

And that means giving up on software with ridiculous dependencies.

Post reply on HN