[change442200]

I'm a dev for more than 10 years. Much Python, C#, Java, JS/TS, Kotlin, a bit of Rust and was recently forced to use Go.

Writing out source code by hand: Nothing beats TS or Kotlin. Not even Python.

But what surprised me with Go after a couple of month (and please, nobody should judge a language until having done a serious project): Taking everything into account, from installing to looking for libs, writing code, testing, compiling, revisiting code after a couple of month ... Go is an absolute dream in terms of overall efficiency.

Writing out error-checking or for-loops is a one shortcut in GoLand. Getting a table-test template for a function as well. People complaining about having to type this stuff out should learn a proper editor.

[Cthulhu_]

Whilst I agree with your comment, I would like to point out / express my personal opinion that having to rely on your editor to churn out boilerplate like error checking is a smell; it reminds me of ye olde Java where Eclipse could generate hashCode and equals. Later on I always used Lombok, and if I were to work in Java again I'd push hard for Kotlin, which has stuff like that built in. I know Scala does as well but it's a can of worms, it has too many options and no two developers will write the same code.

[api]

I've never needed to have an editor churn out Go error handling, and I don't find it that hard. It could be better, but not much better.

Exceptions are not less complex. They just move the complexity around. Exceptions as typically implemented also don't play well with event driven or concurrent models.

The thing I actually like about Go errors is that it makes you think about them right when they happen, while an exception encourages dealing with errors "later" which often means "never" or "as an afterthought."

Go kind of has exceptions, but panics are intended only for very extreme cases like out of memory errors that crash most applications and are often not recoverable. Using panics for non-fatal errors is bad Go code.

One reason I think people don't get Go is that it occupies a language niche that formerly was not occupied by any language. It's like Python meets C, a "low level scripting language." It's designed to be productive and pragmatic but fast and compiled and capable of dealing with pointers or even embedded ASM.

[erik_seaberg]

I want learning to pay off in clarity. I don't want a language in which the best developers have no choice but to write the same bloated boilerplate that the worst developers would have written.

On codegen, I've never seen an IDE that will help everyone read what it generates. If we must generate code, do it during the build and then throw it away, don't make it something to maintain and review.