The Brexit comparison doesn't hold water — Brexit is widely viewed as a failure, yet Go continues to gain popularity year after year. If Go were truly as bad as described, developers wouldn't consistently return to it for new projects, but clearly, they do. Its simplicity isn't a rejection of expertise; it's a practical choice that's proven itself effective in real-world scenarios.
This is optics versus reality. Its goal was to address shortcomings in C++ and Java. It has replaced neither at Google and its own creators were surprised it competed with python, mostly on the value of having an easier build and deploy process.
If we're using "did not meet the stated goal" as a bar for success, then Java also "failed", because it was developed as an embedded systems language and only pivoted to enterprise applications after being a dismal and abject failure at the stated goal.
If Java is not a failure then neither is Go.
If Go is a failure then so is Java.
Personally I think it is inaccurate to judge a mainstream, popular and widely adopted language as a failure just because it did not meet the goal set at the initiation of the project, prior to even the first line of code getting written.
Go has replaced Java and C++ in numerous other environments.
We use a boatload of off the shelf go components; but i don't see it making any progress at replacing java at my bank. We are extremely happy with where java is these days...
Really bad example if you ask me. Banks are literally the last institutions that will make a change.
> It has replaced neither
Except that it did. Just because people aren’t rewriting borg and spanner in go doesn’t mean it isnt default choice for many of infra projects. And python got completely superseded by go even during my tenure
And haven't people actually rewritten Kubernetes in Go? I vaguely recall it was originally written in Java.
I would say this is another thing that would take quite a while to flesh out. Not only is it hard to have this conversation in text-only on hackernews, but HN will also rate limit replies, so a conversation once started cannot continue here to actually allow the discussion participants to come to an understanding of what the they all mean. Discussion will just stop once HN tells a poster "you're posting too often".
Hopefully saving this comment will work.
Go, unlike Brexit, has pivoted to become the solution to something other than its stated target. So sure, Go is not a failure. It was intended to be a systems language to replace C++, but has instead pivoted to be a "cloud language", or a replacement for Python. I would say that it's been a failure as a systems language. Especially if one tries to create something portable.
I do think that its simplicity is the rejection of the idea that there are experts out there, and/or their relevance. It's not decisions based on knowledge and rejection, but of ignorance and "scoping out" of hard problems.
Another long article could be written about the clearly not thought through use of nil pointers, especially typed vs untyped nil pointers (if that's even the term) once nil pointers (poorly) interact with interfaces.
But no, I'm not comparing the outcome of Go with Brexit. Go pivoting away from its stated goals are not the same thing as Brexiteers claiming a win from being treated better than the EU in the recent tariffs. But I do stand by my point that the decision process seems similarly expert hostile.
Go is clearly a success. It's just such a depressingly sad lost opportunity, too.
> It was intended to be a systems language to replace C++
More specifically, it was intended to replace the systems that Google wrote in C++ (read: servers). Early on, the Go team expressed happy surprise that people found utility in the language outside of that niche.
> but has instead pivoted to be a "cloud language"
I'm not sure that is really a pivot. At the heart of all the "cloud" tools it is known for is a HTTP server which serves as the basis of the control protocol, among other things. Presumably Go was chosen exactly because of it being designed for building servers. Maybe someone thought there would be more CRUD servers written in it too, but these "cloud" tools are ultimately in the same vein, not an entirely different direction.
> or a replacement for Python
I don't think you'd normally choose Go to train your ML/AI model. It has really only gunned for Python in the server realm; the very thing it was intended to be for. What was surprising to those living in an insular bubble at Google was that the rest of the world wrote their servers in Python and Ruby rather than C++ like Google – so it being picked up by the Python and Ruby crowd was unexpected to them – but not to anyone else.
> I don't think you'd normally choose Go to train your ML/AI model. It has really only gunned for Python in the server realm
I don't think anyone ever claimed Golang will displace Python in the ML area. But in a world where Golang and Elixir exist (two languages with stacks that make starting a new web / API projects extremely easy, almost trivial), not to mention old-timers like Ruby, the amount of people reaching for Python for web / API projects is depressingly high. "Sunk cost fallacy", "one-trick pony", "Stockholm syndrome" and a few others come to mind when thinking about the programmers doing it.
> I do think that its simplicity is the rejection of the idea that there are experts out there, and/or their relevance. It's not decisions based on knowledge and rejection, but of ignorance and "scoping out" of hard problems.
Ok, I'll ask the obvious question. Who are these experts and what languages have they designed?
> Another long article could be written about the clearly not thought through use of nil pointers, especially typed vs untyped nil pointers (if that's even the term) once nil pointers (poorly) interact with interfaces.
You're getting worked up about something that's hardly ever an issue in practice. I suspect that most of your criticisms are similar.
I think there's two layers to the typed vs. untyped nil issue (which is really about nil pointers in an interface value vs. the zero value of interface types).
The first is simple confusion, such as trying to handle "all nils" the same way. This is not necessary, though I have seen some developers coming from other languages get hung up on it. In my experience, the only real use for "typed nil" is reflection, and if you're using reflection, you should already know the language in and out.
However, the other aspect is that methods with pointer receivers on concrete types can have default behavior when the receiver is nil, while interfaces cannot. In the expression foo.Bar(), you can avoid a panic if foo is *T, but when foo is an interface, there is no way around the panic without checking foo's value explicitly first. Since nil is the default value of all interface types, even if you create a dummy/no-op implementation of the interface, you still risk nil panics. You can mitigate but never truly remove this risk.