[mort96]

I'm not the person you asked, but for me, it's the package identifiers. Demo puts URLs to web infrastructure in source files, like Go. In my opinion, this is a huge mistake. There should be a mapping from logical package identifier to web infrastructure, and this mapping should happen outside of the source files. I believe in this very strongly.

[sheept]

Deno supports import maps, which are the mapping outside of the source files.

But yes, URL imports have a variety of other issues (duplicated dependencies, no resource integrity), though Deno solved them in later versions (npm registry support, lock files).

The only benefit of Deno is its permissions system, which has been great for safely letting agents write and run scripts on my file system.

[kibibu]

This hasn't been entirely correct since late 2024

https://deno.com/blog/your-new-js-package-manager

[mort96]

Thanks, this is a good correction. I haven't looked seriously at Deno since way before late 2024. The "URLs as package identifiers" issue is what initially attracted me to Bun over Deno, but it may not be relevant anymore.

[ok_dad]

What’s the downside? Go does library versioning very well, IMO, but I like to hear other opinions.

[mort96]

The core issue is philosophical. Whether you happen to have public infrastructure which provides a web front-end for your git repository, and what exact server that web front-end happens to be hosted on, ought to be completely incidental to compiling source code. But since you ask, Go is the best example of how this can go terribly wrong in practice, IMO. Here are just a few scattered pain points I've encountered:

* In order to follow convention, you need to decide on git web hosting infrastructure before you start writing code. The tooling asks you for a URL the moment you run 'go mod init'. My preferred way of doing things is to start work on a project just on my computer and then maybe put it on one or more online git web host eventually, if the project goes anywhere. That order doesn't work with ideomatic Go. To work around this, I write mostly non-ideomatic Go where I use the name of the project instead of a URL as a package name.

* I view hosting infrastructure as incidental. I may throw a project on GitHub. I may change my mind and move it to Codeberg. I may move it to my own git forge. I may get tired of hosting my own git forge and move it to sr.ht. With Go, each of these moves requires a huge "touch a bunch of lines in every file" style commit if you're using the ideomatic "git web host as package identifier" style required to work with 'go get'. In other languages, it requires at most a readme change, and for dependencies, it requires at most a git submodule or package manifest change.

* Go requires that you use a Go-compatible git web host. Because Go decided to make URLs look like 'example.com/foo/bar/baz/qux', it has no way to determine which part of that is the git repo and which part is a subdirectory of the repo; should it 'git clone example.com/foo/bar/baz.git' and look at the 'qux' subfolder or should it 'git clone example.com/foo.git' and look for 'bar/baz/qux'? The only solution is for Go to make an HTTP request to 'example.com/foo/bar/baz/qux?go_get=1' and parse the response HTML and look for a Go-specific meta tag which tells Go what part is a git repo. This is an immense "layering violation" and extremely ugly hack in my opinion. This feels so unnecessary too, since this is an easily solvable problem: just make URLs look like 'example.com/foo/bar/baz:qux', so that Go knows to look for 'qux' in 'example.com/foo/bar/baz.git'.

* Private repos are a horrible experience. You need to convince Go to not look them up in Google's package checksum database, you need to convince Go to not get them from Google's caching infrastructure, you need to make a ~/.netrc file with credentials, you need a git host web frontend which understands and supports the way Go + .netrc makes authenticated GET requests. If any of these things are misconfigured, you get a cryptic error message about how terminal prompts are disabled on Google's servers. It's all very brittle and hard to debug, and the guidance has changed drastically over time (editing your global .gitignore to rewrite relevant HTTP sources to use SSH used to be the advice, but that had its own significant problems).

* It has the "feeling" of being decentralized since it's all just git URLs, but in reality, Go's tooling depends heavily on Google's centralized package cache and checksum infrastructure which has been introduced over time to smooth over foundational issues with the design.

I was once part of separating a complex project out of a company and moving it to its own infrastructure on a different domain name and git host. The Rust and C++ repositories were a breeze, just change the URL in a CI job. The node.js repositories required changing some references in the source code from one NPM org name to another but were otherwise painless. The Go repositories were absolute hell.

I have considered writing a blog post about all this.

[quectophoton]

Don't forget:

* No relative imports.

* The `require` directives from the `go.mod` files of your dependencies are always ignored.

Those two combined, mean that there's no easy way to fork a dependency. It's doable, but some of the maintenance overhead could have been avoided.

We don't even get a `go mod tidy` flag that lets us say, "yes, I understand the risks, just copy any `replace` directives that you find in my dependencies". With a flag like that, even if the `replace` directive is still copied everywhere, at least it's automatically copied during a routine `go mod tidy` invocation.

They already have `// indirect` comments, so those could have a `// indirect, replaced by X` comment or something like that.

[ok_dad]

Yea I’ve had troubles with relative imports when working on two or more go projects that had to be designed together.

[umanghere]

I completely encourage you to write this as a blog post, you’ve articulated all of the concerns I had with Go’s package management wonderfully.

[pjmlp]

All great examples why I only touch Go when it cannot be avoided, like Docker related projects.

[ok_dad]

Thanks, I am lucky to avoid those issues working with go, but now I’m annoyed that those decisions were made, I have honestly never thought about the trouble that assigning URLs as import locators could cause but yea that would be a pain if we ever had to deal with any of that.

Thanks for your time writing that. A blog post would be great.

[flohofwoe]

> Demo puts URLs to web infrastructure in source files, like Go.

This is optional, but also really, really handy for standalone scripts that don't need to come with a package-lock.json or deno.lock file (if you're not aware, Deno did a lot of changes to package management in later versions).