> Look at the bios of the Go authors.

Appeal to authority fallacy. Furthermore, this was evident several times when discussions about things like generics came up. I think they even admitted it at some point.

> Just goes to show how out of touch with established programming language research and practice the golang authors are.

When you said that, was also the appeal to authority fallacy.

Which authority? I observed other languages like Kotlin, Scala, Rust, D, C#, Java, C++ and saw what they have in terms of program design and features.

"Established programming language research". That's a set of authorities, even if you didn't name them.

Kotlin, Scala, Rust, D, C#, Java, and C++ are not language research. They're existing practice.

It's more like an appeal to a consensus if you will, since those languages converged on a set of good established practices (that came out of research obviously) that have actually shown to make a positive difference (e.g. Rust, Scala, Kotlin, and soon Java and C#, have sum types, and pattern matching), and the way they deal with errors (Result type in Rust - where the compiler actually forces you to deal with errors unlike golang, and exceptions in the rest, which again, don't let errors slip through accidentally unlike golang).

The golang authors threw away all that (and are still dismissive of things like sum types) because of, well nothing really to back it up. The same reason they have null pointers whereas all new languages moved away from them, and some like C# are being retrofitted to address them. I think the rationale they gave to having null pointers is that "they're part of the underlying machine" or some ridiculous reason like that, which further proves my point that they're out of touch with established programming research and practices.

> The golang authors threw away all that (and are still dismissive of things like sum types) because of, well nothing really to back it up.

Because of multiple decades at Bell Labs, which was the computer science research facility at the time. And because of multiple decades of experience using many languages to write a huge amount of real-world software. And because of specific problems that they found with using C++ in their specific environment.

Look, you don't think go was the right way to go. That's fine. You even base it on having used go and not liking it. It's good that you're basing your opposition on experience, not just theory. But don't claim that the go authors are ignorant of programming language theory just because of the direction they chose. They are not ignorant at all, and they chose the direction they did with full knowledge of what others were doing. It may turn out to be a mistake, but it wasn't from ignorance.

> And because of multiple decades of experience using many languages to write a huge amount of real-world software.

I'm genuinely interested to see the real-world software you're talking about. Other than UTF-8 (and that's mainly a spec), what's there to show? No, Plan9 is barely used. Most of their work was in C either way.

> And because of specific problems that they found with using C++ in their specific environment.

They found problems with C++, sure, so they made a language that addresses problems with C++ that other languages already did, without looking at what said languages did (e.g. Pascal - and even Java and C# - for fast compile times, and C# and ML-languages for generics). Again, they admitted that they were narrow sighted and mainly looked at C++, not what other languages that actually addressed issues with C++.

The golang authors are not language designers, that's always something to keep in mind whenever looking at what (mostly bad) decisions are being made in the language. The issue is, people are just looking at the brand behind the language and are not thinking objectively, leading to more unmaintainable code bases to deal with. Perhaps it's a good thing for software engineers though, who are going to be paid to clean up this mess :)