398 ms·

The Odin programming language does this! It has also decided not to provide a package manager.

Ygg2 28d ago
Spoiler alert! JavaScript has no language provided package manager. If Odin gets moderately successful someone will probably reinvent it.
- leecommamichael 28d ago
  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.
  - Ygg2 28d ago
    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.
  - josephg 28d ago
    > 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.
hnlmorg 28d ago
Go took the same approach and ended up having to implement a halfarsed one when everyone started implementing their own.
- leecommamichael 28d ago
  Has Go not had the most secure ecosystem? 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.
  - hnlmorg 28d ago
    > What is your critique of their approach? 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?

Ygg2 28d ago

Spoiler alert! JavaScript has no language provided package manager. If Odin gets moderately successful someone will probably reinvent it.

leecommamichael 28d ago
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.
- Ygg2 28d ago
  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.
- josephg 28d ago
  > 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.

hnlmorg 28d ago

Go took the same approach and ended up having to implement a halfarsed one when everyone started implementing their own.

leecommamichael 28d ago
Has Go not had the most secure ecosystem? 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.
- hnlmorg 28d ago
  > What is your critique of their approach? 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?