Why Go is my favorite programming language

If I were to build a list of the reasons I use go, it wouldn&#x27;t be terribly different than this one. But interestingly, while I program go every day, I sort of hate it as a language.<p>You&#x27;ll note this list doesn&#x27;t actually have much to do with the language per se, the only point directly related to that is that go has a short list of reserved words (which is true of most languages).<p>So for future language designers (or existing language designers that want to increase the popularity of their language) it seems like things like language ergonomics, power, etc are less important than having a standard batteries included development stack coupled with out of the box &quot;good enough&quot; performance.

I really dislike Go as a language, it has very few means of abstraction and it feels depressing that people think you have to throw out decades of PLT research to achieve perceived clarity like this.<p>That said, these reasons are almost all linked to tooling, which is something that I have to admit Go gets right, but they&#x27;re not intrinsically linked to the language itself and its feature minimalism. I wish there were better languages that had such nice tooling, but unfortunately not all langs have the luck of being backed by Google.

I have said it before and I will say it again - for all the deficiencies Go has, it is somehow highly compatible with the way my brain works.<p>One point the article does not mention is the documentation. I think Go&#x27;s documentation is excellent, it does not overwhelm the reader with its volume, but mostly anything one might want to know about the syntax and semantic can be answered by carefully reading through the documentation that comes along with the development tools.<p>Also, there are some pretty neat static analysis tools for Go out there, and since they are mostly developed in a development-environment-agnostic way, they tend to be usable from a relatively wide range of editors and IDEs. But even just using go vet and golint regularly goes a long way to rooting out all those tiny but tedious bugs and ensure a degree of consistency in naming conventions.<p>I still do not see why somebody in their right mind would willingly prefer camelCase over using_underscores, but the fact that my code is laid out in the same way as that of third-party libraries means it is surprisingly easy to dive into somebody else&#x27;s code and make sense of it. The fact the Go community tends to favor simplicity over brevity can get annoying at times, but when you have to read somebody else&#x27;s code to figure out if it&#x27;s buggy or you&#x27;re using it wrong, it is priceless.<p>There a many things Go could do better (or at all), but if there is no way to implement some feature without sacrificing simplicity, I prefer simplicity. I you want C++, as the saying goes, we know where to find it. ;-)<p>(I&#x27;ll admit though that the C# designers have done an impressive job at adding lots of features without the language collapsing under its own weight. So it&#x27;s not like it&#x27;s impossible.)

The &quot;easy to learn&quot; argument is getting old. If the cognitive load never decreases, that&#x27;s one thing, but initial ramp-up time shouldn&#x27;t be a large determining factor. The MVC pattern, ADTs, functional programming, and so many other useful concepts were foreign at first, but have a substantial impact on how you think and work. With the exception of channels, Go doesn&#x27;t add much when compared to other languages. Maybe that&#x27;s a pragmatic choice, but it feels short-sighted to me.

&gt; There is a cost to introducing an abstraction layer. Go code is usually rather clear, at the cost of being a bit repetitive at times.<p>Go programmers say this a lot and every time I see it I wince. We&#x27;ve had all sorts of flights of fashion and fancy in the programming world, but one observation has emerged that seems closer to fact every time we test it: more code is more bugs. The more code you write, the more chance there is for bugs.<p>And so it&#x27;s so confusing to me why Go programmers simply discard this information, universally accepted as it has come to be. &quot;The repetition is simple,&quot; they reply, &quot;and of course abstractions have cost.&quot;<p>So what is the cost? Because I can tell you the state of affairs right now. I find Go code exhausting to debug, because there is effectively no universal way to handle errors other than to copy-paste if-nil statements. Occasionally, slightly different error handling logic creeps in and it&#x27;s so tempting to start pattern matching the whole block of code and miss these subtleties.<p>This list&#x27;s discussion here... Well sometimes I get the impression that Go programmers are more interested in never having the opportunity to make a conscious mistake, in exchange for making lots of unconscious mistakes.<p>Go has popularized a mode of writing code where not only are abstractions unwelcome, but they&#x27;re nearly impossible. As such, it is quick to learn the syntax. It&#x27;s not really any quicker to learn how to write good robust multi-threaded code though. I still think the Java standard library consistently delivers a better result for equivalent work, at the cost of learning and extra (standard) library.<p>I just don&#x27;t understand why anyone appreciated go&#x27;s design space outside of engineers-turned-architects trying to staff a massive tech org with engineers they don&#x27;t think very much of and have no desire to train.

When Java was first introduced, the world was abuzz about this cool new language which you could &quot;write once, run anywhere&quot;. It took some time, but as it grew in popularity, articles started appearing about how much Java sucked because it was slow and bloated, required a ton of boilerplate code, and eventually because &quot;write once, run anywhere&quot; turned out to be a myth, along with a boatload of other reasons. The honeymoon wore off, and legions of Java-haters were born.<p>Perl suffered a similar fate. When it came out unix was just surging in popularity with the internet boom and a lot of people were thrilled to have a single language you could learn which combined the features of common command-line tools like sed and awk, and that was a &quot;real programming language&quot; that was more powerful than shell scripting, and which grew to have a ton of useful libraries in the form of CPAN. Years later, and Python and Ruby started getting popular, the &quot;Perl sucks!&quot; mantra sprang up and the once-mighty Perl shrank before the upstarts.<p>Ruby and Python are getting their turn now, and I&#x27;m starting to see some people expressing hate towards them as well, though it hasn&#x27;t quite reached the pervasiveness of Java and Perl hate yet.<p>Go was next. People were excited about this cool new language from Google, a place filled with great engineers, and from the mind of Rob Pike, of Unix and Plan 9 fame. It was supposed to be like a simpler and more elegant form of C. What&#x27;s not to like. Well, the replies to this post are showing that for some the honeymoon is already over.<p>Other languages had their day in the limelight, only to wind up being hated: C++, Lisp, Fortran, Cobol, HTML, Javascript.<p>Bjarne Stroustrup observed that <i>&quot;there are two types of languages, the ones everyone complains about, and the ones nobody uses.&quot;</i><p>Whenever some shiny new language comes out, promising to solve everyone&#x27;s problems in some domain, and people start jumping on the bandwagon and singing its praises to high heaven (which seems to happen ever couple of years), I try to take a deep breath and step back. There will likely come a day, before too long, when they too will be subject to hatred and scorn, just as all the other popular languages before them.

I&#x27;ve been using Go for a while, and am frankly amazed at the quality of the tooling.<p>I&#x27;ll add something others haven&#x27;t mentioned... the profiler produces an absolutely <i>amazing</i> graph of the run-time call tree[0]. This makes it incredibly easy to not only see where the code is spending its time, I can easily the context, and where else time is being spent. I recently sped some code up (5x!) using this.<p>0: <a href="https:&#x2F;&#x2F;blog.golang.org&#x2F;profiling-go-programs" rel="nofollow">https:&#x2F;&#x2F;blog.golang.org&#x2F;profiling-go-programs</a>

I think regardless of how each one of us sees Go, its adoption among DevOps (Docker, K8s), Apple and Microsoft means that just like with C and JavaScript it will become unavoidable to use it for certain tasks.

I&#x27;m kind of wondering about why is there no production ready JavaScript&#x2F;TS to exe compiler that packages all dependencies and creates a single executable - like go.<p>With the amount of mind share that js ecosystem has, I thought that would be a thing.<p>The keyword being &quot;all dependencies&quot;

Wow this is extemely close to my own reasons for having a preference for Go. Very well articulated. The clarity of Go code can not be empasized enough. To be fair my favourite languages are Julia and Swift but that neither can really math Go in clarity and simplity.

I know a guy who used to teach Haskell at a university who now runs a development shop at a startup that uses Go. From I recall his main reason for choosing it was to hire cheaper less experienced developers. I remember talking to him about Go and he remarked something like: If you want to clean modular code don’t use Go.<p>Not to disparage less experienced developers but I think teams of developers of any experience level need to have code governance and oversight regardless of the technologies and that a good team with good practices can create good code bases even with more complex and expressive languages. I know another colleague who did this with Scala and was able to properly mentor more junior developers by leading by example. I have not used Go. I have done and lot of Java and a bit of Scala and have many times leveraged generics to create a very high degree of reuse. Without them clearly you get a lot of boilerplate code which makes a codebase larger which leads to another type of complexity in my opinion. So the question is which scenario increases your codebase complexity and that probably boils down to what domain you are developing in. I explore some ideas relating to that tradeoff here [0]. Go has a specific use case that it targets which I believe is services and certain aspects of concurrency.<p>Clearly the Go language and environment have value in the industry, however, as a language it offers little for people who want to have an opportunity grow and learn about more advanced concepts wrt to PLT and CS in general. I have a friend who is a Go fanatic and I try to encourage her to push her limits, but she feels and she can bang out service level code very quickly and she can as she is quite talented. Of course you can do that with Spring Boot as well. Regardless of your language you should always be trying to grow as a developer otherwise you risk becoming obsolete.<p>To put it bluntly and I may get downvoted for this I feel Go is the “Rise of the Expert Beginner Language”. [1]<p>[0] <a href="http:&#x2F;&#x2F;www.elegantcoding.com&#x2F;2012&#x2F;02&#x2F;software-reuse-complexity-curve.html" rel="nofollow">http:&#x2F;&#x2F;www.elegantcoding.com&#x2F;2012&#x2F;02&#x2F;software-reuse-complexi...</a><p>[1] <a href="https:&#x2F;&#x2F;www.daedtech.com&#x2F;how-developers-stop-learning-rise-of-the-expert-beginner&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.daedtech.com&#x2F;how-developers-stop-learning-rise-o...</a>

I wouldn&#x27;t list the standard library as a great strength of Go. While some parts of it are quite good, some others are terrible. Notably, logging and argument parsing are pretty bad. Compare Go&#x27;s &quot;flags&quot; and Python&#x27;s &quot;argparse&quot; for example. And Go&#x27;s &quot;log&quot; and Python&#x27;s &quot;logging&quot;. The Python versions are not perfect but are at least quite usable. In Go, I have yet to see a project with more than 1k lines of code that won&#x27;t use a third-party argument parsing and logging package.<p>For logging, each package will use its own logging mechanism. Sometimes, you are lucky and you can pass your own logger (with a random interface as the interface is not part of the standard library either). Sometimes not.<p>For a language born less than 10 years ago, this is a pity.

What would convince an avid Python user to switch to Go st this point? Let’s narrow down the scope to an API backend to be more specific (isn’t that’s where Go’s performance thrives?)

Just use modern C++

I haven&#x27;t looked at Go yet, but all these &quot;is so easy to learn&quot; and &quot;generics are bad because they&#x27;re not easy to learn&quot; articles on HN, I have to wonder if this language is really so great or people push it because of the politics of people making it.

Its the best, but I&#x27;m sad and shamed it is owned by google.

I love Go! It houses us and puts food in our mouths. It also powers our side projects. Go is awesome!