[d1str0]

This doesn’t answer the question at all. Also it’s very disingenuous. The designers of Go were very much aware of the the last 20 years of language development. They decided on a subset that catered to software engineering between teams of people spanning a length of time.

It purposefully leaves out lots of features and cutting edge design philosophies because many Of those make things difficult when sharing code between multiple developers Spread over a long length of time.

Go’s philosophy has always been close to KISS. Don’t provide all these cutting edge tricks and tips because you can accomplish the same thing in a far clearer and maintainable way by doing it simpler.

[loudlambda]

This is the story I keep being told, but it doesn't seem to match with the reality of a language. Two example off the top of my head:

Loop variables are captured by "reference", not by value, so it's very easy to create bugs where you capture accidentally capture the wrong thing and don't have the value you'd expect.

Nulls, the billion dollar mistake. Most languages are quickly moving away from nulls (and pointers for that matter), or creating constructs that make them much safer (such as what typescript is doing). Instead go doubles down on both of these. In the last decade of programming in kernel level c, python, ruby, c++, java, typescript, scala I've never worked with code that crashes so much and is as buggy as go.

Both of these problems could have been addressed fairly easily without bloating the language. Google has people on the c++ committee; it very much feels like the creators of go had too much hubris to walk down the hall or across the campus and kindly ask a good language designer to shoot holes in their design.

Another example is "iota". How does that make code sharing easy at scale? Any time I see iota, I have to start manually counting lines, and remember the rules for if blank lines or comments bump the counter, and it completely circumvents the ability to quickly grep for a value seen in a log message. It is completely antithetical to teams of people and spans of time and whatnot. It seems more like a team of three people who randomly had ideas and ran with them without thinking the consequences through very well, or consulting the wisdom of others.

[sacado2]

> Nulls, the billion dollar mistake.

That "billion dollar mistakes" is an excellent marketing expression (nobody wants to make billion-dollar mistakes! We should avoid that null they talk about! It looks so expensive!) but I don't know how actually true it is. Do we have any kind of scientific paper that proves languages without null lead to way less expensive software than languages with null?

I'm not talking about memory unsafe languages like C or C++, but situations where, in a memory-safe language, a null pointer exception in production happened to cost a shitload of money.

I'm pretty sure I never had a nil dereferencing in production with my go code. Invalid array access, off-by-one-errors, yeah, sure, way too many, but very few languages can prevent them at compile time. But nil dereferencing? I can't remember that.

[SureshG]

Kotlin is one example where it's difficult to make that mistake. Kotlin does provide nullable type and everything can check at compile time and it so good. So if write code in pure kotlin (java interop has null issues) you can avoid null pointer errors. It's really good.

[sacado2]

I totally agree it's great and tend to enjoy languages that don't provide the user with unchecked nulls. It's a cool tool, but I don't think it's worth a billion dollars. If I had to choose, I'd rather take non-mutability by default rather than compile-time enforced checking of null pointers.

[sytelus]

I'd read some post where Go designers boasted about how they simplified compiler code by cutting down a language feature. It seemed to me they were obsessed about keeping compiler simple which resulted in half-assed language that was then re-casted as achievement in minimalism. I've felt that Go is optimized for compiler designers as opposed to actual developers.

[diamondo25]

As a Go programmer myself, the syntax of Go is simple yet effective. You are in control of what should be done, and Go will make sure all edgecases are covered in _defined_ behaviour like a managed language would. In C, reading out of bounds is legal (except when the address is not accesdible). In Go, you will get a panic (that you can still catch, but its pointing out an invalid program state).

[haxus_the_great]

But how noteworthy is that? I'm sure programmers coming from C will appreciate it, but well-definedness is kind of… the bare minimum you'd expect from a modern language, especially a fairly high-level one like Go.

[smabie]

I dunno, I feel like Go was created to commoditize the work of programmers. Make everyone write the same stupid and repetitive code, over and over again. No one will ever be able to fuck it up, and no one will ever do anything interesting with it. You can onboard new hires who don't know the language in literally an hour. When reading the code, everyone will understand what each line does but there will be so many lines in the codebase that most people won't actually have time to understand the entire project (which is probably how the managers prefer it, actually). The performance will be pretty okay, since the language isn't high level enough to not be aware of the performance of the code you're writing. Great for companies with a gazillion coders. Like Google.

Programming in Go is like trying to tie your shoes with one hand. You can do it, and its okay (I guess), but you can always see how things could be so much easier.

Maybe this is a bit much, but I find Go offensive: designed for the maximum amount of typing and least amount of thinking. Even Java looks like a powerful language in comparison.