Hacker News Reader

> Later comes along Go. No dependency management at the start. There ended up being two ways of specifying dependencies. At least one included putting github.io/username/package into your code. That username changes and all your code has to change. Awful design.

"github.io/username/package" is using a domain name, just like Java. Changing the username part is like changing the domain name--I don't see how this is any worse in Go than in Java.

If you don't like that there's a username in there, then don't put one in there to begin with. Requiring a username has nothing to do with Go vs. Java, but rather is because the package's canonical location is hosted on Github (which requires a username).

I don't know why so many programmer's use a domain they don't control as the official home of their projects--it seems silly to me (especially for bigger, more serious projects).

Slight difference is that it wouldn't break existing builds if you changed namespaces in Java. The maven central repo does not allow packages to be rescinded once they are published.

So that old version of package xyz will still resolve in your tagged build years from now even if the project rebrands/changes namespaces.

> I don't know why so many programmer's use a domain they don't control as the official home of their projects

Not only that, but a commercial, for-profit domain that actively reads all the code stored on it to train an AI. Owned and run by one of the worst opponents of the OS community in the history of computing.

At least move to Gitlab if you must store your project on someone else's domain.

If youre project is open source, won't everyone who wants it just scrape in anyway?

Note that in Java it is merely a convention to use domain names as packages. There is no technical requirement to do so. So moving to a different domain has no impact whatsoever on dependency resolution. Many people use non-existent domain names.

To be honest I really like how Java advocated for verbose namespaces. Library authors have this awful idea that their library is a special little snowflake that deserves the shortest name possible, like "http" or "math" (or "_"...).

It may be a convention but in practice if you want to publish your package to Maven Central you need to prove ownership of your group ID domain. (Or ownership of your SCM account, which is in essence another domain).

Interesting, I contribute to a project that releases on Maven Central but the package name has never been registered as a domain.

Java did a lot of things right beyond the language and VM runtime, both of which were "sturdy" by the standards of the early 1990s. Using domain names for namespaces was one nice touch. Having built-in collections with complete built-in documentation was another excellent feature that contributed to productivity.

Yes, #3 in particular is important for many large corps where one team develops a library that may be pulled in by literally thousands of other developers.

The dependency management side of Maven is great. OTOH, I was astounded to learn today that Maven recompiles everything if you touch any source file: https://stackoverflow.com/a/49700942

This was solved for C programs since whenever makedepend came out! (I'm guessing the 80s.)

(Bonus grief: Maven's useIncrementalCompilation boolean setting does the opposite of what it says in the tin.)

Build and test caching is one of the few compelling advantages that Gradle has over Maven. It's a shame that this is still an issue.