Ten years of “Go: The good, the bad, and the meh”

&gt; Again, it shows how things have changed that I praised Go’s type inference as an advance in the state of the art, but now the Hacker News crowd considers Go’s type inference to be very limited compared to other languages. &quot;You either die a language nobody uses or live long enough to be one people complain about.&quot;<p>This rubs me the wrong way. Even back when Go first came out, anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go&#x27;s type system, including the inference. Just because Sun couldn&#x27;t figure out how to do it in the 90s doesn&#x27;t mean that type inference wasn&#x27;t mostly solved in the 70s. Well before many people were using it or lived any real length of time, Go&#x27;s always been a language people have - rightly - complained about.<p>That said...nothing in the original post says anything along the lines of &quot;Go&#x27;s type inference [is] an advance in the state of the art&quot;, so I might be misunderstanding the author here.

I am immensely thankful for Go.<p>The simplicity of the language and the stdlib is shockingly well thought out -- things like io.Reader are so obvious and yet not part of many other languages. The language has made me a better programmer. And the cross-compilation story is <i>chefs kiss</i>.<p>Working on a cross-platform project where in Go, I write code and it just builds. In Java, I fight with Gradle. In Swift, I fight the type system and the way everything&#x27;s constantly deprecated.<p>It&#x27;s not all perfect. I wish the generated binaries were smaller. I wish the protobuf library wasn&#x27;t awful. And better Cgo&#x2F;FFI would be nice.<p>But overall, I&#x27;ve never been so productive.

Go didn&#x27;t try to be overly clever and abstract. That rubs quite a few people the wrong way, but it also means you are less likely to have to work with people who try to be clever.<p>My first reaction when seeing Go is that it smelled of &quot;old fart&quot;. It looked straightforward and unexciting. I&#x27;m an old fart. I <i>like</i> straightforward and unexciting. It tends to lead to code that I can still read 6 months from now.<p>I want to make stuff and not endure people boring me with this weeks clever language hack they came up with that expresses in one unreadable line what could have been expressed clearly in 3 lines.

I&#x27;d categorize not being able to convert &quot;unused thing&quot; errors into warnings during development iterations as one of &quot;The Bad&quot;.<p>Just today I had a couple blocks of code which were causing erratic issues. Wanted to see if it was the second one, so I quickly commented it out. This is just an exploratory development session, no need to comply with code quality guidelines. Still, the code failed to compile because now I had to worry about 8 lines with stuff that had become unused. The stubbornness about not adding an escape hatch for, again, <i>exploratory intermediate development iterations</i> is unnerving.<p>&quot;But code should not leave unused stuff around&quot;. I agree. That&#x27;s why after a hundred iterations, in the final compilation phase for production, this kind of errors-are-warnings flag would be disabled.

The biggest go problem in practice is ironically omitted in both blog posts:<p>Verbosity of error handling!<p>There should be a shorthand for returning if last ret value is non-nil in one line. Otherwise all you code is littered with:<p><pre><code> if err != nil { return err } </code></pre> and it makes it four times as long and way less readable as a result. This needless verbosity really reminds me of Java.<p>Also, <i>go fmt</i> is not opinionated enough! There really should be one way to <i>line break</i> and max width. Right now you can&#x27;t rely on it to magically format it as it &quot;should be&quot; and fire-and-forget when typing.

The stdlib is the killer feature of go. Several times I wrote high enough performance small services&#x2F;servers that people not familiar with go were astounded with (mostly the speed of writing the code and memory usage). I made many go converts this way. And I always only had to use the stdlib (many benefits when writing within a company).

Worked with Go over 6 years; my biggest annoyance at the beginning, verbosity of error handling, has mostly gone away. In most cases the explicit error handling helped us hardening the code.<p>What does still bother me is the lack of proper enum support. I remember when Java boosted their enum support and the way it impacted the quality of the code. Sure would love to see something similar in Go.

&quot;What I got right...Using capitalization for the public&#x2F;private distinction in functions, methods, variables, and fields&quot;<p>I disagree with this strongly. Due to this when you need to change one of these things to the opposite it involves changing every use site as well. This has far reaching implications for refactoring, wrapping external code when you really do need to expose its guts, etc. Any time you need to do this in a non-manual fashion you&#x27;re required to parse all of the code exactly perfectly (ASTs and such). Even go itself has not figured out how to do this, rf is still experimental and not complete: <a href="https:&#x2F;&#x2F;pkg.go.dev&#x2F;rsc.io&#x2F;rf" rel="nofollow noreferrer">https:&#x2F;&#x2F;pkg.go.dev&#x2F;rsc.io&#x2F;rf</a>.<p>Example use case: <a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;46792">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;46792</a><p>I much prefer the non-viral public&#x2F;private attributes other languages use.

Go has turned into an Awesome language.<p>I&#x27;m one of those that cannot use a PL that has no generics... It kills the DX of Algorithms and Data Structures.<p>Now it has Generics, soft RT GC, and it might even get official Arena Allocation.<p>I &#x2F;LOVED&#x2F; the Matklad comment of |error handling converging|, indeed -- it seems that PL community evolved to &quot;any-error&quot; + annotation-at-call-site.

Copilot and the like are good for Go, because you can generate all the boilerplate code they make you write.<p>As for the success, it&#x27;s obviously the minimal set of language features, conformance to established paradigms, not being very broken and being backed by Google.<p>There&#x27;s a ton of suboptimal choices in Go, but overall it can work for many applications.

&gt; Go’s error handling is more verbose than those other languages, but structurally, there’s a lot of commonality under the surface.<p>In Go the type system doesn&#x27;t force you to check for errors, the same way as languages with null pointers don&#x27;t force you to check pointers before dereferencing them.<p>That&#x27;s the real problem with errors and null in Go, not the verbosity (though that doesn&#x27;t help)

I was very skeptical of Go, but after trying it, it quickly became my main and favorite language. I think the drawbacks of the language are easily offset by how powerful and simple it is.<p>Its biggest flaw imo, which I don&#x27;t think was mentioned in the article, is that Go did not learn from The Billion Dollar Mistake in Java: null references. You have zero protection against nil pointers, and this is likely not something that can be changed now without breaking backwards compatibility.

I learned Go on and off in recent years on the side(daily job does not need Go), I like its battery included stdlib and cross platform support.<p>I do feel its binary size is large comparing to c and c++, and multiple Go executable can not share libraries as easily as how c&#x2F;c++ uses the shared lib, when I have a few Go binaries they add up, and I do storage constrained embedded development a lot.<p>On the desktop side, I really hope Go can have a GUI in its stdlib, something like what Flutter&#x2F;Dart does: adding a Skia kind of engine and let me do GUI cross platform, that will make Go main stream like wild fire.

Go was successful because it came after decades of pretty much no language putting good networking tools in their stdlib.

Very insightful. Re: the generics point —<p>As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be simplified and made more concrete, not more generic.<p>I’m glad generics were implemented, if only to silence the chorus of people who didn’t even use Go but whined about the lack of them. Their inclusion has simplified the stdlib and led to some cool new functions. Nevertheless I think people implementing them in their own projects is basically code smell and they are a symptom of poorly thought-out code rather than excellent code.<p>Anyway. This was a good initial post and a good follow-up. Go is my favorite language out there right now for its clarity, power, and ease-of-use. And with loop variable capture coming (the biggest remaining foot gun in the language in my experience) the language is only getting better.

Great article. Go may have generics, but because old Go code doesn&#x27;t, and the standard library doesn&#x27;t, it still feels like the language doesn&#x27;t sometimes.

Comparison with Emacs: an awesome operating system that still needs a great editor.<p>Go: amazing tooling&#x2F;libs, only needs a great language :-)<p>But a few tweaks, like proper Enums and a Option&#x2F;Return Type (to avoid excessive err != nil), maybe a compilerflag to force dealing with errors (instead of _ it) - much better. If I can wish for something, then some native map&#x2F;filter&#x2F;reduce to avoid excessive for-loops…? :-)

Working with Python and Java over the years, I have this feeling that Go isnt battery included. Maybe I miss out 3rd party libraries I am very familiar with? For instance, Python has parse library to help parsing inputs without the need for RegEx. Java has lots of “common” collection libraries. I just feel exhausted coding the same from scratch in Go either because no such library exists or being told just copy and paste!

Its a shame that Go as a language is so lacking, the tooling is amazing.<p>I wish there was something like Go but with an actually good programming language attached.

A bit off topic but...<p>I need some resources for evangelizing GO.<p>I do not use it, but...<p>I have a colleague who needs&#x2F;wants to replace a PHP&#x2F;Laravel mess. They are talking up Node.js<p>I think GO would be a better choice<p>This article is close to what I need, but is there anything better?<p>The server side code they are looking to replace is handling sensitive financial information and I am very queasy using Node.js in that domain

Go is loved because of three reasons.<p>- Simple<p>- Highly concurrent<p>- Impressive networking stdlibs