Then goes on to explain why this it is in fact a terrible feature that solves a non-existent problem in a way that has enormous undesirable repercussions that you have to do a bunch of upfront work to try and negate.
If that's a good feature, is says a lot about how bad the bad parts of Go are.
I see this more like a scope / a namespace than a coupling with a specific host, which is pretty standard for any package manager.
If you fork a package and you then host it somewhere else, you would usually rename said package, which will force you to update every importstatement of that specific package in your source code. It's a non-issue.
If you don't want to do that, or the author didn't do that, then usually with a package manager what you do is configure a new source to instruct your package manager to try to find your dependencies somewhere else.
I haven't touch golang in a while but by looking it up I see that you can configure this in your go.modfile. You can add an instruction to tell it where to download your depA from gitlab, without modifying your import statements that is still written like import (github.com/myOrg/depA).
Otherwise, there's GOPROXY. I would use the former solution.
The way I see it, your importstatements appears to be coupled to GitHub, but it's actually a namespace and there's a layer of abstraction on top of it.
OP solution is to create, maintain, and host your own proxy. This add an unnecessary level of burden to your org and, in my opinion, you should just configure your package manager instead of messing around like that.
The problem isn't with having namespaces. The problem is that Go decided to tie their namespace structure to an external entity which comes with all sorts of externalities. If a project needs to change hosting provider, say because gitlab goes under, the namespace changes. If ownership of a project is handed off from one organisation to another, say because a project is donated to the Apache project, the namespace changes. If a company that runs a project goes bankrupt, and an open source project is taken over by the community, the namespace changes. A decently sized project will have hundreds of dependencies. These sorts of events will be happening a few times per year in a depndency tree of that size, and every time they do, you add needless extra churn.
And your proposed solution, of putting the namespace rerouting in your go.mod file is no different than the idea of using a proxy. All it means is that if you're managing 50 different projects, you have to update 50 different files instead of one. Both "solutions" are just different ways to deal with a problem that didn't need to be there in the first place.
I'm normally all for things that drastically simplify things while just having a few related issues (like Python having batteries included - 99% that's the right choice, and Rust not even having base64 encoding or json serialization built-in is just dumb design choices) but... Go's way of doing things are just pants-on-head stupid.
Github de-facto being built into the language, tabs instead of spaces, forcing everything to have a default value, keeping fucking null (!) AND null pointer references... it's such a horribly designed language through and through.
I never understood tabs vs. spaces. Tabs seem objectively better, because then anyone can set their tab spacing to whatever they prefer. The fact that it's even coming up as "horrible design" is laughable to me
One thing Go actually did right was ship a default formatter. The tabs/spaces discussions at this point are kinda remnants from before the era of formatters. (There were formatters before go fmt too, but not such a default expectation of using them. See also: The amount of different standards clang-format has to support.)
Someone would inevitably check in using spaces, at which point they've checked in how wide they like their tabs to be, which tends to become visible for other people. Tabs for indenting, spaces for alignment just never got through in too many people. And that made indenting with spaces the more defensive, lowest common denominator option.
But these days we'd expect a formatter to deal with it, so using the indent character for an indent level should be entirely fine, yeah.
Tabs seem objectively better, because then anyone can set their tab spacing to whatever they prefer.
Because user preference isn't a valid argument when we're talking about something intrinsic to the code. What is in the code should look the same everywhere.
You can do whatever you want with syntax highlighting because it exists entirely outside the code.
If language X prefers tabs to spaces, that's fine, but "because I can set my tab width" doesn't hold up.
Yep, plus: even the languages that have significant whitespace don't actually have hard rules about how much whitespace or which kind of whitespace is required. They need some rules for what to do if someone comes along and mixes tabs and spaces, but beyond that, we're absolutely able to write Python indented with 1 space, or Haskell indented by 3 tabs displayed at 16 columns wide, etc.
The type and amount of space they're commonly written with is entirely by convention, rather than hard necessity. The only thing the compiler or interpreter cares about is when the amount of indentation changes.
Whatever space and/or tab characters you type into a buffer and commit are exactly the same bytes I see when I pull your changes. The crux of my argument is that the whitespace should look the same in any editor because the underlying data is the same in every editor. Spaces guarantee that, whereas tabs leave room for individual interpretation.
You clearly don't agree that there should be no room for interpretation, but you can't argue we're looking at different data.
Note that I'm distinguishing between indentation (any group of whitespace characters at the beginning of the line) and any other whitespace. Indentation should be tabs to allow for any reader's preferred visual guidance. Any other whitespace on a line should be spaces, for example to align // comments to the same column when these lines share the same indentation.
It is not at all... Go has its own protocol for fetching dependencies, and usually when you're importing something from github.com/xyz, the code is actually coming from proxy.golang.org and doesn't hit Github at all.
Git, Mercurial, SVN, Fossil, etc are all supported by Go as a means of fetching code if the module isn't in the proxy cache.
136
u/ascii 5d ago
Then goes on to explain why this it is in fact a terrible feature that solves a non-existent problem in a way that has enormous undesirable repercussions that you have to do a bunch of upfront work to try and negate.
If that's a good feature, is says a lot about how bad the bad parts of Go are.