Making go more like other languages might be nice if you like those other languages. But then, there are probably valid reasons for go language designers to not

Making go more like other languages might be nice if you like those other languages. But then, there are probably valid reasons for go language designers to not have gone down that path. I can work with Go when I have to. But it's not my main language. I appreciate the low barrier to entry. There's a ruthless pragmatism to the language that just means that whether you like it or not, that's how you do things in Go. Go-fmt is a great idea. Shuts down discussions about style that are fundamentally a waste of everybody's time. The suggestions that the author makes are unremarkably reasonable and at the same time controversial to people used to the Go way. People get entrenched that way. It's like tabs vs spaces or curly braces vs. begin/end (or parentheses). Enums are a good idea though. Should be entirely controversial. But clearly people have dismissed that idea because it is such an obvious and easy thing to do. I'd be curious about the reasons for that. Error handling has been controversial since the language emerged with people loving it and hating it. IMHO it would clean up the language a lot if they acknowledged the simple reality that the most copied bit of go code is basically people deciding to not do anything substantial with the error other than logging it. Having the option to do something productive is nice. Making it required to spell out that you are not going to is silly. Java had a similar thing with checked exceptions. That's thankfully missing from Kotlin (which I use a lot) and it streamlines code quite a bit without really affecting stability. You still deal with the error somewhere. Just not right here right now. I mention Kotlin here because I'm eagerly awaiting Kotlin native getting to the point where it becomes stable enough so people can write command line tools in it like people do with Go. JVM based Kotlin or Kotlin script are just not great for that (startup overhead, dependencies). Kotlin native actually works well on IOS currently but it is a bit lacking for command line usage; mainly because of lacking functionality in the library ecosystem. Just not a huge priority for Jetbrains apparently. But very fixable.