Python Is Easy. Go Is Simple. Simple != Easy

Language design is always easier in retrospect. It is harder than it looks, and often harder than the people designing a language realize before it is too late.

I think it was a good choice to take smaller steps and try to not be too ambitious too soon. Sure, Go isn't the most sexy language from an academic point of view, but it has a certain conservative and pragmatic approach that does work. It does generally result in code that is a lot easier to read and maintain than is my experience with C, C++, Java, C# and a few other languages I've worked in.

Go is an engineering language - not an academic exercise.

Take, for instance, the approach to generics. They could have designed that in from the beginning, but they showed restraint and didn't. That probably took a fair bit of courage. It is my impression that they hadn't figured out what generics should look like in Go, so they postponed until they had a better feel for how it ought to be done. Rather than risk making choices that would be hard (impossible?) to rectify later.

When you add something to a language there is always the risk that you make it worse.

(I'm not making any qualitative judgements on Go generics since, frankly, I don't feel qualified. I make very sparing use of it because it really isn't that often I actually need to make use of it)

People tend to forget that Java didn't have generics until 1.5 (or 5.0 or however they prefer to version it now) - about 9 years after first being launched. And to be frank, that was not a fun experience at all. Not so much because there was something wrong with the design, but because suddenly a lot of people went overboard and started designing really hairy types that could be hard to figure out and use.

If you consider C++: C++ spent 20+ years flailing wildly and the result was that you got lots of different C++ "traditions", subsets and practices. Sometimes within the same company. Depending on which era or tradition a C++ codebase is from you may have to adjust to a wholly different way of programming from what you are used to or prefer. And as for generic programming: in what world is STL a neat solution? And to this day, compilers are slow, they produce rubbish error messages, the toolchain still feels like a 1970s ad-hoc mess, and there is no definitive way to build things, resulting in lots and lots of additional complexity when trying to tame the horrific tool chain.

Sure, they could have put loads of stuff in Go from the beginning. But I think they would have gotten a lot more wrong if they had. I really appreciate that they are evolving the language slowly and conservatively.

One day is not enough to even get a superficial understanding of any language.

People tend to always exaggerate how little time it takes to learn a language to a meaningful degree. Sure, the first day I tried Go I was able to accomplish something useful, but it took me a few months to develop a basic understanding of how you use Go in an idiomatic manner. I'd say it took at least a couple of years before I could say I "knew" Go.

And it wasn't exactly love at first sight. My initial impression of Go was that it was a bit too much like C, and, coming from Java, I was a bit confused about how you structure things. That takes time to figure out for any language. What sold me on Go eventually was that for my uses (writing multi-protocol server applications that run on multiple architectures), it resulted in code that was very readable and productivity more than doubled because Go is a lot less fussy to work in than Java. Both in terms of encouraging more minimal designs and having a lot less fragility.

I don't think it is. We had a production outage because someone was putting things into a map with the wrong key. Tests passed because they read (using a right key) and checked that they got a valid value. In this case an empty string was "valid". (Basically it deserialized correctly.) Sure the tests could have been better but this also wasn't the only bug due to default values. Imagine if 1% of the time the result of addition was randomly 5, it would cause havoc. Default values are the same. Sure, often they are a reasonable value, but when values that the coder didn't expect enter the system you are going to have a bad time. If the map reads failed tests would have failed, but also the crashing service would have been reverted and the problem found before it caused any real trouble. Not silently corrupting out data for a week.

The other option isn't null, the other option is an error. Ideally the code fails to compile. 99% of the time I would rather have an error than have my code silently be wrong. Failure is almost always better than corruption. (Don't get me started on Go's fmt lib that barfs crap into the output if you have your format string wrong, at least that is easy to lint for most of the time) And build failures are almost always the best because then the wrong code can't even make it to production.

> not repeating Tony Hoare's billion dollar mistake yet again

This is the killer for me. After using Swift for a while, I no longer have the tolerance for languages that don’t have proper option types (and perhaps more importantly, which don’t use option types pervasively and by-default.) It’s just 100% the wrong way to design a language nowadays. Option types are table stakes.

It doesn't even have to be ML-style option types. Kotlin is a great example of an alternative implementation that arguably has much better ergonomics for procedural and object-oriented code.