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

571–580 of 593 posts

Re: Rust’s dependencies are starting to worry me

#571

Post by mexicocitinluez »

FredPret wrote: post #463
mexicocitinluez wrote: post #434

Earlier quoted context omitted.

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

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.

Re: Rust’s dependencies are starting to worry me

#572

Post by mexicocitinluez »

buzzerbetrayed wrote: post #469
mexicocitinluez wrote: post #434

Earlier quoted context omitted.

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

Case in point. Imagine if a carpenter or house builder was shitting out slop that had no taste. And then laughed at people who pointed it out. Would you hire them to build something for you? This is a problem with SE culture.

> Imagine if a carpenter or house builder was shitting out slop that had no taste

What are you even talking about? How does this even remotely relate to software development? Are you telling me a function that adds 2 numbers has "taste"?

Re: Rust’s dependencies are starting to worry me

#573

Post by mexicocitinluez »

buzzerbetrayed wrote: post #469
mexicocitinluez wrote: post #434

Earlier quoted context omitted.

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

Case in point. Imagine if a carpenter or house builder was shitting out slop that had no taste. And then laughed at people who pointed it out. Would you hire them to build something for you? This is a problem with SE culture.

Actually, the problem with SE culture is people think they're way smarter than they really are simply because they grew up being called a genius by knowing how to turn a computer on and off.

Re: Rust’s dependencies are starting to worry me

#574

Post by jcgl »

jlarocco wrote: post #309
endorphine wrote: post #278

What actually surprised me in Rust, is the amount of fragmentation and abandoned libraries. For example, serde_yaml is archived and there are two other libraries that do the same (?) thing. It seems like there's a significant effort required to search for and decide which (if at all) library to use. This is not so much pronounced in Go.

Maybe that's the double edged sword of making the package manager so integrated into the language.

How is cargo more integrated into the language than Go’s? I’ve little to no experience with Rust, but Go’s package management seems pretty fully integrated to me.

Re: Rust’s dependencies are starting to worry me

#575

Post by yubblegum »

vacuity wrote: post #570
yubblegum wrote: post #548

Earlier quoted context omitted.

I used to be firmly in the component oriented camp. The reality of the matter is that the conceptual (mental) model doesn't really represent the reality of composing with reusable components. All Lego components have the same simple standard mechanism: friction coupling using concave and convex surface elements of the component. Unix pipes are the closest thing we have to a Lego like approach and there the model of "…

> 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 in general agreement in terms of technical analysis. Let's focus on the concrete metric of 'economy' and hand-wavy metric of 'natural order'.

Re the latter, consider the thought that 'maybe the reason it is so difficult to standardize interfaces is because it is a false utopia?'

Re the former, the actual critical metric is 'is it more ecomical to create disposable and ad-hoc systems, or, to amortize the cost of a very "hard" task across 1 or 2 generations of software systems and workers?'

Now the industry voted with its wallets and blog propaganda of 'fresh engineers' with no skin in the component oriented approach in early '00s. That entire backlash that included "noSQL" movement was in fact, historically, a shift mainly motivated by economic considerations aided by a few black swans, like Linux and containarization. But now, the 'cost' of the complexity of assembly, deployment, and orchestration of a system based on that approach is causing information overload on the workers. And now we have generative AI, which seems to further tip the economic balance in favor of the late stage ad-hoc approach to putting a running system together.

As to why I used 'natural order'. The best "Lego like" system out there is organic chemistry. The (Alan) Kay vision of building code like nature builds organisms is of course hugely appealing. I arrived at the same notions independently when younger (post architecture school) but what I missed then and later realized is that the 'natural order' works because of the stupendous scales involved and the number of layers! Sure, maybe we can get software to be "organic" but it will naturally (pi) present the same perplexity to us as do biological systems. Do we actually fully understand how our bodies work?

(Just picking old professional scabs here)

Re: Rust’s dependencies are starting to worry me

#576

Post by BrouteMinou »

oddmiral wrote: post #561
whstl wrote: post #496

Earlier quoted context omitted.

This won't solve supply chain issues.

Linux distributions are built this way. Distro maintainers selects libraries and versions to include, to create solid foundation for apps.

Which still doesn't solve the supply chain issues...

Re: Rust’s dependencies are starting to worry me

#577

Post by slashdev »

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…

I don’t want a large std lib. It stifles competition and slows the pace of development. Let libraries rise and fall on their own merits. The std lib should limit itself to the basics.

Re: Rust’s dependencies are starting to worry me

#578

Post by pclmulqdq »

caspar wrote: post #569
delusional wrote: post #510

Earlier quoted context omitted.

> At best, they are asking for hobby projects to advertise themselves as such That's also work. You don't get to ask the hobby programmer to do your work of vetting serious/maintained projects for you. As the professional with a job, you have to do that. If some rando on GitHub writes in their readme that it's maintained, but lies. You're the idiot for believing him. He's probably 12 years old, and you're supposedly…

To add to this, in the gamedev space there are a bunch of middleware libraries that are commonly paid for: fmod/wwise, multiplayer networking sdks, etc.

Thinking about this a bit more, it seems that the reason there isn't a good way to sell licenses to software libraries generally is license enforcement. Unity and Unreal have a licensing system built-in that they enforce against gamedevs. Normal server software has no such thing.

That means the only threat you have as a producer of code (once the code is handed over) is the threat of withdrawing service. That means the only ways to sell licenses are:

* Build your own licensing service (or offer SaaS)

* Sell the code for a high price upfront

* Sell service contracts

Re: Rust’s dependencies are starting to worry me

#579

Post by canadianfella »

athrowaway3z wrote: post #301
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…

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)

[dead]

Re: Rust’s dependencies are starting to worry me

#580

Post by lcnPylGDnU4H9OF »

andybak wrote: post #481
lcnPylGDnU4H9OF wrote: post #445

Earlier quoted context omitted.

Just to explain this confusion, the term “web server” typically refers specifically to software that is listening for HTTP requests, such as apache or nginx. I would use the term “application server” to refer to the process that is processing requests that the web server sends to it. I read “web server” in their comment as “application server” and it makes sense.

Yes. That's the same distinction I would expect. Although I'm not sure that the database stuff is the role I'd usually look for in the application server itself. Maybe it's a language community thing.

Ah, yeah, I did mean “application”. You’re right about the “application server” being a weird place for db connections.
Post reply on HN