undefined

points

[-]

The industry hasn't grown out of OOP. Go look at any major production codebase businesses rely on and it's fully of objects and classes, including new codebases made very recently.

Package managers aren't going anywhere. Even languages that historically bet on large standard libraries have been giving up on that over time (e.g. Java's stdlib comes with XML support but not JSON).

Unfortunately, LLMs are also not cheap enough to just create whole new PL ecosystems from scratch. So we have to focus on the lowest hanging fruits here. That means making sandboxing and containers far more available and easy for developers. Nobody should run "npm install" outside a sandbox.

by c7b16 minutes ago|

parent|

[-]

It's a condensed statement. There was a time when I would start a new programming project thinking about class hierarchies, maybe drawing some UML diagrams. I don't do that anymore, and I don't believe it's very common for greenfield projects anymore, but educate me if that's wrong. We've kept some of the good ideas from OOP like namespaces and interfaces and we use them in slightly different contex stnow, where OOP may even still be technically possible, but it's not the primary way of doing things anymore. I believe, or at least hope, we will see a similar kind of evolution for package managers. Where it's still possible to import other people's code, but things like left-pad or is-even is no longer how it's commonly being used, even if it may still technically be possible.

by pjmlp4 hours ago|

prev|

[-]

Rust is quite bad on this, having to rely on external crates for error handling or macros is even worse than what async runtime to pick up.

Yes, I mean crates like anyerror and syn.

by weregiraffe5 hours ago|

prev|

[-]

But you can't expect the language std to supply you with every package under the sun.

by c7b5 hours ago|

parent|

[-]

I don't have an answer what the alternative is going to look like. But smarter people than me may find something. C/C++ are doing fine without package managers. Go at least has a more capable standard library than Rust. But I'm not sure if Go's import github approach is the answer.

One idea I've been entertaining is to not allow transitive imports in packages. It would probably lead to far fewer and more capable packages, and a bigger standard library. Much harder to imagine a left-pad incident in such an ecosystem.

by rounce2 hours ago|

parent|

[-]

> Go at least has a more capable standard library than Rust.

Many Golang projects I see in the wild will import a number of dependencies with significant feature overlap with sections of the standard library, or even be intended as a replacement for them. So it seems that having an expansive stdlib isn’t sufficient to avoid deep dependency trees, it probably helps to some degree but it’s definitely not a panacea.

by uecker2 hours ago|

parent|

prev|

[-]

The solution exists, and those are curated package repositories as we have in Linux distributions. In C I can simply install a -dev package and use some library which sees some quality control and security updates from the distribution.

The problem is that the UNIX shell model got very successful and is now also used on other platforms with poor package management, so all the language-level packaging system were created instead. But those did not learn from the lessons of Linux distributions. Cargo is particularly bad.

by pjmlp4 hours ago|

parent|

prev|

[-]

In C and C++'s case, the batteries included is POSIX + Khronos.

by well_ackshually4 hours ago|

parent|

prev|

[-]

>C/C++ are doing fine without package managers.

They're not either, every one of these projects contains a gigantic vendor/ folder full of unmaintained libraries, modified so much that keeping up with the latest changes is impossible so they're stuck with whatever version they copied back in 2009.

by jkercher19 minutes ago|

parent|

[-]

You make that sound worse than it is. On the overall topic, you have 0 supply chain risk, and the whole thing is local. Also, your code from 2009 is still valid. That would be a foreign concept in some languages like Python.

by baq3 minutes ago|

parent|

[-]

you have your supply chain risk still, it's just frozen as of 2009 and whatever you vendored back then is as of today swiss cheese; also you'd better have the compiler suite vendored, too (as you should with this strategy).

there's nothing stopping you from using python from 2009 except why would you want to do that to yourself - but the same strategy applies. the reference python implementation is written in C, after all.

by foresto4 hours ago|

parent|

prev|

[-]

A stdlib doesn't have to provide everything under the sun in order to be helpful here.

Languages with rich standard libraries provide enough common components that it's feasible to build things using only a small handful of external dependencies. Each of those can be carefully chosen, monitored, and potentially even audited, by an individual or small team.

That doesn't make the resulting software exploit-proof, of course, but it seems to me much less risky than an ecosystem where most programs pull in hundreds of dependencies, all of which receive far less scrutiny than a language's standard library.