[skohan]

Go isn't for programmers, it's for managers. Because of the simplicity of the language, it's easy to get people onboarded with, and it's fairly difficult for a single team member to go astray and move the codebase in a direction which will be unmaintainable. It's a kind of lowest-common-denomenator language which is easy to read, debug, and maintain, even for a mediocre programmer.

That said, I think you are right about explicit nullability. A language like Go with this feature, as well as named arguments and limited ADT's could be very compelling for Go's use case.

[throwaway894345]

> Go isn't for programmers, it's for managers

And yet it's a top-5 most-loved language among programmers and there's no real evidence that it's popular among managers (discussed in detail here: https://news.ycombinator.com/item?id=27175297). Moreover, lots of open-source software exists in Go--if only managers like the language, what's the theory for why all of this software (including major software, like Kubernetes) exists? Is it managers building it in their spare time? Even then, those managers are acting as programmers (not managers) in that capacity.

With respect to the implication that only managers care about the pragmatic aspects of software development (collaboration, onboarding, readability, debugability, maintainability, etc), where did this meme come from? I get the meme that there are many programmers who value abstraction above all else, but I'm not familiar with the meme that all programmers are abstraction maximalists.

[danesparza]

"Go isn't for programmers, it's for managers"

I completely disagree with this statement. Some of the most high-performance modern platform-level code written is currently written in Go.

It was a Google presentation that examined their efforts to convert their download site to Go (from C/C++) that got my attention. It's easier to read, has a simpler mental model, and faster than its C/C++ cousin.

[skohan]

I'm not sure that the points you raise contradict my thesis. Could it not be the case that a language designed primarily for making large software teams easier to manage would also lead to high-quality software at large organizations?

[rob74]

If the thesis is that "Go is for managers", then yes. I would wholeheartedly agree to something like "Go is not for developers who want to write clever code that others (or they themselves in a few months' time) may have trouble understanding". But Go also works for large teams (communities) of open source developers who don't have what you would usually call "management", so saying it's only for managers is definitely too narrow a statement...

[skohan]

I basically agree; I think claiming "go is for managers" was a bit flip of me to say, but what I generally mean is that Go is more optimized for operational concerns than for the joy of programming. It's also not a pejorative: there's a lot of good reasons you might choose Go and why you might like it as a programmer.

[cies]

> Go isn't for programmers, it's for managers.

Doesn't Java fit the same bill? (although it was kinda modern at the time)

> I think you are right about explicit nullability

Sadly it's really hard to shoe-horn this onto Go, now that the std lib is widely used. Same for proper sum types (which can then be used for multiple return values).

But the continuation of the nullability mistake puzzles me the most... And that wile Go's be designed by big name lang gurus: what were they thinking?

[skohan]

> Doesn't Java fit the same bill? (although it was kinda modern at the time)

Yes, I think Java was an earlier attempt at this.

> Sadly it's really hard to shoe-horn this onto Go, now that the std lib is widely used. Same for proper sum types (which can then be used for multiple return values).

I agree, I think these types of features are much easier to design around than to add into a mature ecosystem later

> But the continuation of the nullability mistake puzzles me the most... And that wile Go's be designed by big name lang gurus: what were they thinking?

Is it just a timing thing? It seems like explicit nullability came onto the mainstream a few years after Go debuted, but maybe it was already discussed in academic circles before then.

[cies]

> Is it just a timing thing? It seems like explicit nullability came onto the mainstream a few years after Go debuted, but maybe it was already discussed in academic circles before then.

I know OCaml[1] has it ('93) and Haskell[2] ('90). Also the claim that implicit nullability is a mistake was made in 2009[3] (around the same time Go was released).

Given the seniority of the designers of Go, I expect they had knowledge of this.

https://en.wikipedia.org/wiki/OCaml

https://en.wikipedia.org/wiki/Haskell_(programming_language)

https://en.wikipedia.org/wiki/Tony_Hoare

[tome]

ML had "it" in 1973!

... if "it" is even a thing. I would say that it's not, rather implicit nullability is the thing. It's just not something you'd do in a typed language unless you really specifically chose it. That's how Hoare could claim it was his billion dollar mistake. Implicit nullability was a thing he (and subsequent language designers) opted in to.

[eplanit]

I think that you have confused Go for Java.