>Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans.

Several quite opinionated industry titans who appeared to ignore most things they didn't themselves invent in AT&T for UNIX or in Plan 9, and based on their own preconceptions of "programming at scale" as a pet project (not based some formal Google-initiated research on its practical needs).

Algol and ADA were indeed created by "experience of several industry titans", in a process examining the field of applications and use cases for the languages.

Go was not really that, whatever the story says.

> and based on their own preconceptions of "programming at scale" as a pet project

Based on their experience working at Google. It wasn't just "preconceptions". (True, it also wasn't an examination of the field of the form that led to Algol and Ada, but it wasn't just preconceptions, either.)

>Based on their experience working at Google.

Yes, but that's their experience working at Google as 30+ years industry veterans and thought leaders (one would guess, mostly left to do their own thing, as prestige hires).

Not as regular developers doing everyday Google grunt-work...

Well, the founding myth of go says that it started from a conversation during a 45 minute C++ compile. I doubt that that was Rob Pike's personal "thing" project - he hadn't been there long enough to have a personal project that size. That was some big multi-person multi-year thing.

They had the limbo language in plan9, which has similar features and quirks. It seems most probable that the outcome of the 45 minute conversation wasn't "let's build a language from scratch", but rather "let's iterate on limbo".

You can get the details here,

"Creating the Go programming language featuring Rob Pike & Robert Griesemer"

https://changelog.com/gotime/100

There are other sources as well, this was just the one that quickest came to mind.

Actually it was, and they had a manager that covered up for them, allowing them to keep working on the project.

"Creating the Go programming language featuring Rob Pike & Robert Griesemer"

https://changelog.com/gotime/100

Had not been for him and Go would never gone beyond a prototype side project.

That isn't what I was claiming, though. I was claiming that the impetus for creating go was the issues raised by working with Google's regular code, not issues raised by working on Rob Pike's pet project at Google. Whether go became their pet project was outside the scope of my claim.

The only issue was waiting for builds and having to deal with C++ code, something that Pike shares the same opinion as Linus.

> Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans

This claim keeps getting repeated with absolutely nothing to back it up, other than repeating what the golang authors claimed.

I work on a large golang code base, and it's quite horrid. The IDE experience is terrible. It's hard to navigate the code base, due to things like types unintentionally implementing interfaces because they happen to match on some of their function declarations. No proper visibility rules (only "public" and "package private"). interface{} everywhere because of no generics (I'm aware that's being worked on). Single character variable names are popular because the golang authors write code that way and it's seen as "smart". No reserved "this" or "self" keyword to declare methods means that every type will have its own single letter self variable which you have to look up every time. Error handling is terrible, and I've seen many insidious cases of mishandled errors. Null pointers are still a thing. The list goes on.

Edit: not to mention things like the language is against quick prototyping (heavy friction due to things like unnused imports or variables, and a very verbose language), as well as the lack of mature libraries such as JDBI or Dapper.

> No reserved "this" or "self" keyword to declare methods means that every type will have its own single letter self variable which you have to look up every time.

Python lacks a reserved keyword for this use, and I can count the ones not using “self” in instance methods and “cls” in class methods that I’ve encountered on the fingers of my left foot.

But, yeah, weak convention plus no keyword promotes needless chaos.

This sounds like really bad code was allowed to be checked in, not the fault of the language. You can make terrible code in almost any language.

The above does not match my experience in maintaining large go codebases because of proper code reviews and expectation of writing maintainable code.

Nope, we have a very rigorous linting and review process. It's the shortcomings of the language.

how are your complaints about your bad variable names shortcomings of the language and not the code you accept?

Because it's literally in the standard library of golang, and everyone copies its style.

There is no law that requires the use of the same variable naming style as std. Also,

> interface{} everywhere because of no generics

It would be good to know the domain here. Looking at my own fair share of Go code in productive systems (probably around 100-200 KLOC, written over the last 6 years), interface{} is really really rare. It appears in some library functions which genuinely accept basically any type, in the same way as json.Marshal(), fmt.Printf() or sql.Stmt.Execute() in std.

Other than that, I don't think I've ever had a case where I used interface{} instead of defining a more specific interface (plus adapter types to implement that interface on foreign types if necessary).

The only big mess that I've come across in Go land is kubernetes/client-go. I can't wait for generics to replace this metastasizing heap of autogenerated code.

> There is no law that requires the use of the same variable naming style as std. Also,

While that's technically true, it doesn't work out in practice because people look to the standard library as "the way" to write golang. It's basically an implied rule and I haven't seen anyone not folllow it so far.

> It would be good to know the domain here

Both infrastructure level work as well as CRUD type work.

> interface{} is really really rare

We have to use them everywhere for things like JSON parsing, config file handling, and pagerduty integration. Not to mention wrappers around SQL handling (e.g. batch inserts, pagination, etc.)

Generics will fix some things in the language, but not all. There are too many issues with it like the ones I already mentioned. It's still a very cludgy language to work with.

> JSON parsing, config file handling

I assume you're not referring to things like json.Marshal(), where the function argument is legitimately of type interface{} since it really accepts any value.

Hence I'm going to assume that you're referring to situations where a value can have one of multiple types (e.g. a float value that sometimes gets provided as a string). It's true that people sometimes unmarshal into interface{} and then type-assert in those scenarios, but that use of interface{} is a code smell that should be flagged in review. The proper way is to unmarshal into a custom type with a json.Unmarshaler implementation that accepts all possible input formats (and vice versa for json.Marshaler if encoding is required). This is a real-world example from one of my codebases: https://github.com/sapcc/limes/blob/d833228e976ac1ddc4b95779...

Algebraic types would solve the issue in the example you're giving. However, those don't exist in golang either.

Having worked with the people doing those standard libraries, you're pulling justifications out of your butt for bad practices.

Just as a start: variables names should always be clear by context. You only see the one letter ones if its literally the next line or similar use case. Also, bare interface{} should basically never be the case for a function signature.

None of the code you've described thus far would pass a proper review.

Code bases in reality still do what I'm describing, and they pass code reviews. Kubernetes is one example of the atrocities caused by the language.

>Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans.

So have all languages, with wildly different philosophies about how to do that. We collectively just don't have any idea what we are doing. Clearly nobody has stumbled on a big win or one particular language would start dominating the industry due to the productivity bump.

I actually don't think this is true, which is kind of nuts. Programming languages generally fall into two categories:

1) They were either designed by one or two eccentrics, and thus contain a few great guiding principles and many questionable ideas, which invariably come back to bite large projects; or,

2) They were designed by a committee who tried to make the Final Universal Language that would solve every possible problem, resulting in a kitchen-sink mess of a language with a 400-page specification that no one reads.

Most mainstream languages made some attempt to serve software-at-scale; for example, OO used to be the obvious thing that would make software more maintainable, so most languages support it at least in part. But if you look at a language like C++, it's obvious that many of its features were added simply because they were cool or increased expressiveness (e.g. operator overloading) without regard for long-term maintainability. Even things as mundane as "implicit 'this'" are clearly harmful to readability, with specious benefit.

AFAIK, Go is the only language that really takes engineering seriously: https://talks.golang.org/2012/splash.article If there are similar articles for other mainstream languages, I'm certainly curious to read them and see how they hold up today!

> AFAIK, Go is the only language that really takes engineering seriously:

Ada is the consummate engineer's programming language. And with Spark, even more so. Unfortunately, the compilers were super expensive at a critical stage in its evolution. And the DoD thing.

And I've never used Rust professionally (unlike Go), but it has all the applicable points in the article you list (obviously no garbage collection). But in Rust, these features are often implemented in a more robust manner than in Go (eg, like Go, Rust avoids exceptions and uses error values, but instead of returning a special-cased interface, it returns a regular sum type, which allows for proper type checking of the error handling, and which is also composable since it's also a monad). And unlike Go, Rust got package management down from the start. Go's package management has gotten better, but it's still not as good as Rust's through Cargo (to be fair, Cargo is best of class).

I think what is actually going on is that Rob Pike's ideas about how software engineering should work resonate strongly with you, while Anders Hejlsberg, Don Syme, James Gosling, Christ Lattner, and Rich Hinkey does not resonate with you.

I think it would be a difficult argument to suggest that those other people do not have similar engineering chops, or haven't been around a long time.

But if you are right we should see Go winning in the marketplace more and more in the future in a way unprecedented for programming languages.

I don't mean to suggest that at all -- I have great respect for those people, particularly Rich Hickey, whose framing of "simple" vs "easy" is vital to these discussions. But it's clear that a language like Clojure is not a good fit for million-line, decades-old codebases. Java wasn't explicitly designed for large-scale engineering either; it's north star was Write Once, Run Anywhere. In short, I think there are very few languages that prioritize engineering to the exclusion of other features, and Go is one of them.

Ada is another; it was explicitly designed for large-scale engineering, but hasn't seen nearly as much success as Go. I'd like to learn more about why it failed. Perhaps it was the language itself, or maybe it was merely a timing issue, or the fact that it was backed by the government. This comment has some good info: https://news.ycombinator.com/item?id=7825008

Why Ada failed has been discussed ad nauseum including on here. Early compilers were $$,$$$ per seat and proprietary, they're still easily $,$$$ per seat. Good open source compilers came later, there's still a strong disparity between the FOSS and commercial compilers and tooling.

The language was a mandate from US DOD which rubbed a lot of people the wrong way. It largely sat in the same space as Fortran and C, C was free (or much less expensive) and more readily available even when it did cost.

Cosmetic: People strongly dislike the verbosity of Ada. Some parts are reasonable to consider changing (but really are just cosmetic) like begin/end versus {/}. Other verbose portions are hard to change without fundamentally altering the language. You want to print integers and strings and you don't want to have to use Integer'Image(X) all over the place?

  with Text_IO;
  use Text_IO;
  with Ada.Integer_Text_IO;
  use Ada.Integer_Text_IO;

Now Put and Put_Line can be used with both strings and integers. Oh, you want to print more types? More withing for you. I don't mind it, you don't need to print in every package, but it is very cumbersome.

If you want to write a quick CLI tool, Ada is not your language (though I've done it), go for Perl, Python, Ruby, sh/bash, or even Go. C and C++ can be easier for that purpose. But once you start scaling it's a very good language.

The only way to get Ada in the mainstream now is to make it much cheaper and greatly improve the FOSS compilers and tooling, and have SPARK/Ada support an increasingly large subset including approaching feature parity with respect to memory safety as Rust. That's being worked on, but it's a non-trivial problem.

> https://talks.golang.org/2012/splash.article

The shortcomings listed in that talk are mainly against C and C++. Other serious languages and platforms like Java, C#, and also Rust have solved these issues.

>So have all languages, with wildly different philosophies about how to do that.

I think what you refer to as differing philosophies are in fact differing goals, and the goal of Golang is very different from pretty much all other modern languages: simplicity.

I think boiling everything down to 'they are all trying to do it better' misses the fact that the 'it' they are trying to do better is very different in some cases.

> simplicity

This has to be quantified. Simplicity in the language, perhaps. It definitely does not translate into simplicity of resulting programs, and the ease of being able to reason about them, or write them.

Having spent about 3 years each in Java, C++ and Golang, and getting a good amount of time with Python, I have to disagree with your final few points. Golang's simplicity in the spec itself DEFINITELY gives down stream benefits, simplifying a lot more beyond itself. That includes writing and reasoning about code.

Having worked on several large golang code bases, its verbosity is tedious to deal with. It doesn't lend well to IDEs (e.g. it's so easy for a struct to accidentally implement interfaces it doesn't mean to because of structural typing). Error handling is always a mess, it doesn't have enums, and so many issues to list here that Java doesn't have.

The golang authors' weird obsession with not having any methods on strings for example, makes it horrendous to work with them (e.g. can't chain someString.trim().toUpper().endsWith("...")).

Don't get me started on the supposed fast compile times. Parsing is fast (but so almost any other language that is not C++ or Scala), but linking is horrendously slow. Modifying and re-running individual unit tests takes seconds at a time due to relinking. In Java, it's in a blink of an eye because there is no linking.

Having to use functions on built in types like strings.HasSuffix(strings.ToUpper(...)) isn't that bad to me. If I'm chaining a bunch of function calls on a single string, I'll want to separate them on different lines for readability anyway. It'll be creating and destroying a few implicit copies either way, so I have never really felt any pain from that.

Java has no linking, but you have to go through the JVM. Golang produces native binaries. Not really a fair comparison. That being said, my brain is normally a way larger bottle neck than linking time for unit tests.

I'll cede the gripes with enums and error handling (although I hated the way Java exceptions always ended up way too overloaded way more), but I find the typing a really good balance between strong and weak. It's strong enough that you have to be doing something really weird to mess up, but weak enough to be flexible.

It is your position that Go is the only language aiming for simplicity? Are you relatively young?

No, I don't think it is the only language aiming for simplicity. I do, however, believe it has been the must successful at it.

Young at heart :)

> Clearly nobody has stumbled on a big win or one particular language would start dominating the industry due to the productivity bump.

This is what happened with Python. It provided a distinct productivity advantage over C & C++, and now no one writes web apps in C++ anymore. Granted, it's not just Python anymore, but newer languages learned from Python's success.

First we had web apps written in Java, then Perl, PHP.

Python's popularity for web app development came way later (django was released in 2005)

Python was originally written as a reaction to C & C++. It didn't really hit the mainstream for web apps until much later, granted, but when we compare it to the languages it was originally competing against, the difference is pretty clear.

Garbage collection got a clear productivity gain over not garbage collection. But it isn't clear that the various takes on GC languages, Python, Java, C#, Go etc have led to any one clear winner.

> Python, Java, C#,

Notably, we've had garbage collection for nearly as long as we've had programming languages - so this has been going on much longer than the examples you give would suggest.

I'd argue that Java ultimately failed to innovate over C++ in the way that Python did. It added GC, but it's still clunky and hard to work with. In that sense, it's more of a pre-Python language, even though it's a few years younger than Python.

I don't think you mean that, or you misunderstand how Javascript or PHP came to be.

If I didn't understand how javascript came to be, I would be suggesting that javascript must be the best language!

From my experience having to debug and fix up / change things in old go codebases, it's an absolute nightmare.

The lack of abstractions often force you to read a lot of code you don't care about.

The language is so simple that reading complex code is actually hard.