I was surprised that the author didn’t translate the piped representation of the first program to a procedural program with explicit calls to subprocedures. It’s bigger, but it’s dead-simple and easy to slip instructions in the middle of.
> One of the memes on Twitter is that “programming is solved now.” I’m not sure to what degree it is, but one thing is pretty clear: the act of familiarizing yourself with a language no longer matters and some of the friction that mattered for humans does not matter for agents.
>
> As a result, LLMs make language choice much less consequential than it used to be. If you don’t like the choice, you can seemingly rewrite it in another language and you can make it pick a language that you, as a programmer, are entirely unfamiliar with.
...
> I’m not sure to what degree it (programming) is (solved.)
> the act of familiarizing yourself with a language no longer matters
> LLMs make language choice much less consequential than it used to be.
...
You're reasoning as if you think it's mostly solved. How the hell are you going to read the code with any reliability or speed if you aren't familiar with the language? I realize languages have broad similarities.
In addition to this, I think one gets even more from reading after having tried to write. There's a unique feedback loop that starts happening once you start creating.
Sometimes I wonder if too much looking behind the curtain might affect you. Like seeing how the restaurant prepares your food. Or seeing that much of apple's look and feel is rounded corners.
Here's a suggestion, do you think it could be this simple? If you write a package-manager, don't execute any of the downloaded code in an automated fashion. No hooks, no build-time metaprograms. If your language _needs_ metaprogramming to function, it's a huge secondary issue that I don't know how to solve. You can try to make a meta-program annotation which disables side-effects, but the metaprogram ultimately must write memory which expands the amount of code generated. All risk is introduced when the person downloading cannot preview the content in a safe place.
Unfortunately it doesn't solve the problem because malicious code can still end up compiled into the user's program which they will promptly execute, possibly in production...
Supply chain attacks are not a problem that can be solved by a single silver bullet, however the biggest benefit comes from a combination of minimum release age + fresh 2FA required for every publish + automated scanning. This makes it considerably more difficult to pull off a supply chain attack and should be the baseline security for all package managers.
The only safe solution is to review all the code's changes (or trust someone else to do it).
Forbidding compile/build-time shenaningans is trivially bypassable and has already been bypassed in the NPM ecosystem by just making the library code itself (not the build scripts) malicious - eg. do the bad thing when the code is loaded/tested, assuming the language has static constructors.
What is your critique of their approach? Is it not the case that `go get` is the only one which doesn't even provide a way for the person downloading to run the downloaded code until it is actually executed by the consuming codebase? That seems pretty sound by comparison.
I guess you're saying, "they had to" meaning they should've seen the need and provided it? I'll say this to that (imagined) take; plenty of useful software was made without it, and they got the job done when they knew the absolute most about what a good solution would need. I totally understand being annoyed at the fact that this is the story of every evolution in Go, but I genuinely think they're picking good implementations when they decide on them.
It’s half arsed, brittle and far from user friendly.
> Is it not the case that `go get` is the only one which doesn't even provide a way for the person downloading to run the downloaded code until it is actually executed by the consuming codebase?
If you’ve added the package to your imported then odds are your next step is going to build it. Thus negating any benefit.
I think the real issue is malicious packages entering package ecosystems. Whether your package manage executes on downloads or not is moot because you’ve still got untrusted code sat in your project imports, just waiting to be accidentally executed.
> I guess you're saying, "they had to" meaning they should've seen the need and provided it? I'll say this to that (imagined) take; plenty of useful software was made without it, and they got the job done when they knew the absolute most about what a good solution would need. I totally understand being annoyed at the fact that this is the story of every evolution in Go.
I think you’re being too charitable here. I think Russ Cox just didn’t want a package manager because C doesn’t have one. But ended up relenting after everyone nagged the Go team for years afterwards.
And really what they built was the bare minimum to manage package version pinning and updates. But it has none of the visibility that central package repositories have. So how do you know if a Go package has been compromised when the only source of truth is the compromised origin?
Ultimately I think devs need to think about their dependencies and decide which ones get pinned and a serious review before pulling. If the thing has got binaries, it gets a serious review. If it does anything with cryptography, it gets a serious review... etc.
I don't think automatic updating is a good idea at all. It's just the honor-system, and trust is a security flaw.
Exploits can be shipped in any type of dependency. Remember the compression exploit that affected even SSH?
The problem is your solution depends on the honor-system. Ie “trust me, because I’m just a YAML mashaller. Why would I want to inject a crypto miner?”
That’s why package databases exist. They are meant to be centralised databases of peer reviewed and CVE checked resources. But Gos approach pushes all that responsibility onto each and every developer.
One thing it does get right, in my opinion, is removing the value of name squatting.
It's interesting how this plays out with C/C++. There's not really a package manager, and so the host system has to have vetted packages. It moves the burden on to the system maintainer.
Yup. It’s a system that worked when it was relatively safe to assume a chain of trust. But it’s not scaling to the era of AI agents writing patches, nor the increasingly number of attacks against existing foundational packages.
We really do need to rethink the security model behind open source.
Thanks for the thorough reply. I personally haven't experienced brittleness/unfriendliness, but I have only written around 10k lines of Go. Not exactly a power user, but I like to think I understand it.
> If you’ve added the package to your imported then odds are your next step is going to build it. Thus negating any benefit.
I actually think this is the benefit! I don't need to go to a website to see what changed, I can just have a look at the code. The best dependencies have a changelog. Ideally I can look at a diff.
> I think you’re being too charitable here. I think Russ Cox just didn’t want a package manager because C doesn’t have one. But ended up relenting after everyone nagged the Go team for years afterwards.
That's entirely possible.
> So how do you know if a Go package has been compromised when the only source of truth is the compromised origin?
Fair point, and probably worse in this future we're in now that NIST is drowning in CVEs and has turned away from some share of them.
NPM came along in 2010, Javascript was huge before that.
It was only when people wanted a common approach to shipping both in browser and "native" that this glitch happened. I believe a standard library and "batteries" would have abated it entirely or resulted in a slightly less-bad situation. I do think Cargo is a slightly less-bad situation in many ways, and that it can be done better.
> It was only when people wanted a common approach to shipping both in browser and "native" that this glitch happened.
Nah. Npm was invented because node had its node_modules directory. But it was tricky to find and download modules you wanted to use. Until npm, you had to add libraries to node_modules by hand. And check them in to git or something. And keep them up to date somehow. Npm added a searchable index and a tool to automatically install all your modules. Npm was only bundled alongside Nodejs many years later.
Bundling was separate. I can’t remember if browserify predated npm or not. But it was a wild idea at the time to make node modules build for the browser too. Browserify - and later webpack and friends - work with or without npm.
Sure. Maybe threshold is bit higher than moderately. But unless your language tries to sabotage itself by making code artifacts uncomposable (a la C/C++ where best way to compose libraries is through shell commands) some package manager will be inevitable.
Batteries also don't help if dependencies don't replace them. Arrayref functionality has been part of Rust std lib for a while now.
sliiiiightly obscure in that it seems to use the ULD drivers (or a variant of); HP's "unified linux driver" that talks Samsung's printing language. it's weird.
reply