[jesseschalken]

Go has plenty of hidden code paths in defer, panic and recover. You can minimise the use of those things, just like in other languages you can minimise use of try-catch in favour of a Result sum type, which is already better than Go's "multiple return that you have to pretend is a sum".

[potato-peeler]

Which is what should be discussed about go, rather than if-err clauses. That is hardly an issue in go. But Go has these little quirks which, if not careful, can become a problem. But instead most go critiques discuss only the error handling syntax. Look at the other comments.

The article is on point on the strengths of go, and in many cases, those other languages you say, you will find it really hard to do the same thing with the ease with which you can do in go.

What the article glosses over, is the footguns with working with the language. No compile time nil checks, implicit interfaces, lack of sum types, like you said, which more so often leads to bloated structs, member visibility which is just private and public. You can find more.

But these problems were not the main focus of go. Go was build because google devs wanted a simpler way to manage and deploy their software across thousands of services, not having to wait forever for their code to compile, not worrying about writing cpp code in the BEST possible industry standard, ability to do parallel processing of hundreds or thousands of workloads without choking your cpu, managing dependency hell. These were actual roadblocks. And google was not the only one facing these problems. Go solved all of it. Which language was solving this before go?

[pjmlp]

Go was developed because two UNIX guys, and one Oberon guy, that didn't like C++ decided to create their own thing, and their manager decided to support them as their 20% project.

Nothing else.

The narrative of Google wanting Go never happened, it gets sold as such by many Googlers.

Even Kubernetes was originally written in Java, before some Go folks joined in and drove the rewrite into Go, which besides the Android build system are the only two key projects using Go.

[potato-peeler]

https://go.dev/doc/faq#creating_a_new_language

[pjmlp]

Yes, and?

Most of that was written by the Go team, not Google management, and even has the famous Rob Pike take on it.

The You Tube download rewrite from Python to Go, wasn't a management decision, rather yet another case of Go team taking language marketing into their own hands.

You will find posts from me on golang-nuts pre-1.0 days, as I was hopeful it would turn out differently back then, so I don't need education on how Go came to be.

[potato-peeler]

> Most of that was written by the Go team, not Google management, and even has the famous Rob Pike take on it.

I am unable to understand your point or you seem to be making arguments that have nothing to do with the article nor with my earlier replies. I wonder why. Are you expecting sundar pichai to announce golang to his shareholders in his quarterly call? Which language does that?

This article and my replies are technical in nature. You need to have a technical response to a technical problem. You cant get emotional everytime. Which language allows me fast builds, lightweight and high performance concurrency, strong stdlib and tooling, easy cross compilation with static binaries, simple syntax, decent performance and by that i mean not worrying too much on memory management, easy onboarding and large scale maintainability? I am willing to try that tool.

[pjmlp]

Because your narrative is wrong, it wasn't a Google project, it was a group of Google employees that rebeled and were lucky to have their line manager support, given being UNIX idols.

Google upper management was, and is, perfectly fine with Java, Kotlin, C++ and Rust, for the most purposes.

I won't suggest any "technical" answer, because clearly you only want Go.