5 ms·

This isn't entirely fair to Deno but it always amazes me how people start out with "we don't need packages! Just do direct imports" and eventually end up with "

This isn't entirely fair to Deno but it always amazes me how people start out with "we don't need packages! Just do direct imports" and eventually end up with "okay fine fine here's a package manager". Packages are great! Don't dismiss them just because in edgecases they're bad. In fairness, the two examples, Deno and Go, are successful projects, so maybe it's not a bad initial strategy.

johannes1234321 4y ago
Is deno successful? I (in my limited world) don't know anybody using it and don't see it mentioned in job descriptions etc. And to comparing to other languages: It's not like "ok, projects became to big we need better package management" or something, but to me reads more like "there's too little deno stuff and migration prevents people from going here, so let's try to embrace the other runtime's stuff so maybe more people can use our runtime without having to start from scratch"
- IshKebab 4y ago
  I think there's quite a big gap between success and being more popular than NPM. Plus it's only a few years old. Job adverts are usually several years behind what companies actually use and companies are behind what hobbyists use. I'd say it is on a successful trajectory. The main issue with it was NPM compatibility so I think this is a very very wise move, even if it is pragmatic rather than ideal.
- qbasic_forever 4y ago
  It's not even 5 years old, give it some time for people to pick it up and use it. Python was created in '91 but even by '96 it still wasn't widely used.
speedgoose 4y ago
The lack of packages in Golang is super annoying though. And I wonder about the mess it will be when something better than git will be popular.
- yencabulator 4y ago
  Go modules are defined in terms of Zip files. Multiple version control systems work today. But don't let facts stop you hatin'.
  - speedgoose 4y ago
    My bad. And I’m not hating Golang, I only find the modules not that great.
qbasic_forever 4y ago
Deno still won't have a package manager, at least in the style of npm. You don't need to learn a bunch of CLI and janitor a package.json file. You just add an import to your source code and you're done. Pulling in a npm package is the same as pulling in code from github, it's just a special URL. That's it... that's the 'package manager'.
- hardwaregeek 4y ago
  I wouldn't bet against a regular package manager existing in the near future. We've seen this story with Go :P
  - yencabulator 4y ago
    I'd still say Go doesn't have a "package manager". The dependencies are fetched, cached & built as you need it, but there's nothing comparable to "npm i"/"npm uninstall", dpkg/rpm/apk/etc, as such. If you want, you can just import example.com/foo/bar in your source, and the rest is just reproducability (version & hash) and caches.
- SomeCallMeTim 4y ago
  Except that, as the ecosystem grows, you eventually have packages that are complex enough that they have imports, and those packages have imports. And now because you've hard-coded imports at every level, you can end up with a dozen different versions of the same import, causing potential conflicts between the various components of your app. Package managers evolved to be the way they are _because they're useful._ It's not like people said "let's add all of this complexity for fun!" Direct imports failed as a solution for Go, and they already have been acknowledged as an incomplete solution for Deno (import maps are already a larval form of package.json, but without the ability to inherit child import maps, which means it's still broken, but presumably it will eventually be fixed). Not having a standardized place where you can see the dependencies of a project, and not being able to distinguish which are _development_ vs _runtime_ dependencies, is also rather broken, and would require a package analysis tool that's far more complex than a package manager to use to trace the dependency tree reliably.

johannes1234321 4y ago

Is deno successful? I (in my limited world) don't know anybody using it and don't see it mentioned in job descriptions etc. And to comparing to other languages: It's not like "ok, projects became to big we need better package management" or something, but to me reads more like "there's too little deno stuff and migration prevents people from going here, so let's try to embrace the other runtime's stuff so maybe more people can use our runtime without having to start from scratch"

IshKebab 4y ago
I think there's quite a big gap between success and being more popular than NPM. Plus it's only a few years old. Job adverts are usually several years behind what companies actually use and companies are behind what hobbyists use. I'd say it is on a successful trajectory. The main issue with it was NPM compatibility so I think this is a very very wise move, even if it is pragmatic rather than ideal.
qbasic_forever 4y ago
It's not even 5 years old, give it some time for people to pick it up and use it. Python was created in '91 but even by '96 it still wasn't widely used.

speedgoose 4y ago

The lack of packages in Golang is super annoying though. And I wonder about the mess it will be when something better than git will be popular.

yencabulator 4y ago
Go modules are defined in terms of Zip files. Multiple version control systems work today. But don't let facts stop you hatin'.
- speedgoose 4y ago
  My bad. And I’m not hating Golang, I only find the modules not that great.

qbasic_forever 4y ago

Deno still won't have a package manager, at least in the style of npm. You don't need to learn a bunch of CLI and janitor a package.json file. You just add an import to your source code and you're done. Pulling in a npm package is the same as pulling in code from github, it's just a special URL. That's it... that's the 'package manager'.

hardwaregeek 4y ago
I wouldn't bet against a regular package manager existing in the near future. We've seen this story with Go :P
- yencabulator 4y ago
  I'd still say Go doesn't have a "package manager". The dependencies are fetched, cached & built as you need it, but there's nothing comparable to "npm i"/"npm uninstall", dpkg/rpm/apk/etc, as such. If you want, you can just import example.com/foo/bar in your source, and the rest is just reproducability (version & hash) and caches.
SomeCallMeTim 4y ago
Except that, as the ecosystem grows, you eventually have packages that are complex enough that they have imports, and those packages have imports. And now because you've hard-coded imports at every level, you can end up with a dozen different versions of the same import, causing potential conflicts between the various components of your app. Package managers evolved to be the way they are _because they're useful._ It's not like people said "let's add all of this complexity for fun!" Direct imports failed as a solution for Go, and they already have been acknowledged as an incomplete solution for Deno (import maps are already a larval form of package.json, but without the ability to inherit child import maps, which means it's still broken, but presumably it will eventually be fixed). Not having a standardized place where you can see the dependencies of a project, and not being able to distinguish which are _development_ vs _runtime_ dependencies, is also rather broken, and would require a package analysis tool that's far more complex than a package manager to use to trace the dependency tree reliably.