
Why Go is my favorite programming language - secure
https://michael.stapelberg.de/Artikel/golang_favorite
======
kasey_junk
If I were to build a list of the reasons I use go, it wouldn't be terribly
different than this one. But interestingly, while I program go every day, I
sort of hate it as a language.

You'll note this list doesn'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).

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 "good enough"
performance.

~~~
kazinator
> _language ergonomics, power, etc are less important than having a standard
> batteries included development stack_

To programmers under twenty five. And that explains not only Go, but volumes
of computing history.

~~~
Chris_Newton
That seems a little unfair. I have better things to do with my programming
time than reinvent the wheel every time I need to manipulate common data
structures, or make an HTTP request, or query a database, or parse a CSV file,
or do some mathematics efficiently, or draw a picture showing the results of
that mathematics.

I’m some way past 25 these days, but if there is one lesson I’ve learned about
programming languages over the years, it is that a good supporting ecosystem
usually is worth more than even quite substantial improvements in the language
itself. It’s not that language improvements aren’t welcome — I think some
programming languages are _much_ better than others. However, you’re always
going to be limited in how productive you can be with a language that lacks
comprehensive libraries or good tools or enough people using it to discuss
interesting issues or hire a full team of staff, no matter how brilliant the
design of the language itself might be.

I don’t know what the worst mainstream programming languages are today, but in
purely technical terms surely C, Java and JavaScript all make the shortlist.
Compared to many other contemporary languages, these three all lack features,
often take a lot of code to get quite simple things done, and are full of easy
ways to make mistakes. And yet, in terms of how much useful software has been
written in them, they are among the most successful languages we’ve ever had.
Why? At least in part, I think it’s because they have three of the most well-
developed ecosystems around them.

------
steinuil
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.

That said, these reasons are almost all linked to tooling, which is something
that I have to admit Go gets right, but they'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.

~~~
falcolas
Ultimately, programmers fall in a bell curve. Most languages which benefit
extensively from that research target people on the right of that bell curve.
Go, with its lack of complicated mechanics targets the middle of the bell
curve.

I don't have the luxury of working exclusively with people on the far right of
the bell curve, so I'll end up picking Go with its simplicity for most
projects. I can be assured that almost anyone can pick up code written in Go,
and be productive much faster as a result.

~~~
eeZah7Ux
> Go, with its lack of complicated mechanics targets the middle of the bell
> curve.

No, it targets the less experienced - interns, as the language creators said.

~~~
terminalcommand
I don't think Go targets the less experienced. Could you provide a resource,
where the language creators have stated that Go targets interns?

Go is a safe programming language, but it is not simple. Go has very rigid
rules.

I don't see any difference in complexity between programming in C and
programming in Golang. Programming in Golang may even be harder than C.

If you format your code wrong, Golang screams at you.

If you import a package and never use it, Golang screams at you.

If you redefine a defined variable, Golang screams at you.

If you don't use a variable you defined, Golang screams at you.

C is much more forgiving :).

Golang makes dynamic memory management safe, but in nowhere easy. You still
use the good old void* via an empty interface. For an intern, garbage
collection doesn't matter, an intern is intelligent enough not to leak so much
memory so that it will get noticed :).

I sometimes think Golang resembles the early versions of Java. Creating a
safer C-like language, with great ideals. With Java the complexity kicked in
after a while. Golang still resists the urge to please everyone.

~~~
wyager
> I don't think Go targets the less experienced. Could you provide a resource,
> where the language creators have stated that Go targets interns?

"They’re typically, fairly young, fresh out of school, probably learned Java,
maybe learned C or C++, probably learned Python. They’re not capable of
understanding a brilliant language but we want to use them to build good
software. So, the language that we give them has to be easy for them to
understand and easy to adopt." \- Rob Pike

------
krylon
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.

One point the article does not mention is the documentation. I think Go'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.

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.

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'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's code to figure out if it's buggy or you're using
it wrong, it is priceless.

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. ;-)

(I'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's
not like it's impossible.)

~~~
jerf
"for all the deficiencies Go has, it is somehow highly compatible with the way
my brain works."

I have been tempted to write a blog post about "Why People Actually Can Write
Real Programs In Go." To listen to HN complain about the language you'd think
that it must be clearly impossible to ever write a program of any kind without
massively copying and pasting everywhere, when in reality I find it's actually
quite pleasant for a non-trivial subset of programs.

The short answer is that it has a lot of features that people, generally not
being used to them, work better than people may realize from the bullet points
and often work together better than people realize. Favoring composition over
inheritance is a legitimately good choice. Being able to declare interfaces
that other objects I don't control conform to has a lot of little effects that
you wouldn't anticipate in advance, to the point that while I understand the
bondage&discipline impulse to require code to declare what interfaces it
supports, I would consider that a legitimate mistake in most of the languages
that do that. (In practice, it turns out the problem of "accidental
satisfaction" basically doesn't exist. We learned that from the duck typing
languages like Python and how they never really had a problem with that.) And
while the grand concurrency stuff may seem neat, the little stuff can be nice
too; just yesterday I wrote some code that takes a list of servers to query
for some particular thing, and it was easy to write it to do them all
simultaneously; that wasn't a Grand Architecture thing, it was just a function
that casually did something that is a royal pain in many languages. (There are
also languages that can do it better; I actually know many of them. Erlang
would be roughly a tie here and Haskell could look _really awesome_ if you put
a bit of work into it. Elixir might beat Go, not sure, but I know Erlang
itself doesn't.) And there's some other things like that.

The other thing about Go is that I like it for _work_ , but not necessarily
for my hobby. The thing about all those restrictions in Go that apply to me is
that they symmetrically apply to my coworkers. As much fun as a more powerful
language can be, it becomes a lot less fun when you've got dozens of
developers trying to work in one code base in those languages; what is power
for you is power for them, too, and, well, let's just say they are not always
going to be the most expert developers in the world. I've seen... things. And
at times, I've even been the one who did the "... things". So even though I
know how to use Haskell productively and generally correctly, I'm generally
very uninterested in introducing it into the team environment that I have.
This is, IMHO, a very important point that I don't hear discussed often
enough.

Basically, if you take HN's opinion of "Go is useless and should be wiped from
the face of the Earth" as a scientific theory that predicts how useful it
would be, the theory is falsified. It is useful and some of us even enjoy it
for certain tasks. But I for one would never suggest it is useful for
everything and actually frequently warn people off from certain tasks.

~~~
pjmlp
Many of us, old timers, surely programmed in languages like Go in the past,
and were able to deliver lots of successful projects into production.

I for one was a very passionate Oberon user and Niklaus Wirth is well known
for its minimalism design goals, Oberon-07 is even more minimalist than Go.

Just because I used to program like that almost 20 years ago, doesn't mean I
still enjoy using such minimalist languages.

~~~
jerf
I absolutely agree that there have been a number of similar languages in the
past, in various variations. However, the only one I know of that may have a
claim to have gotten to Go's size or perhaps even larger (relative to the
time) is Delphi. Go is, if not the first, the first in a long time to be
something that can be practically commercially used. (I mean, you _can_ use
whatever language you want commercially, but there's definitely more barriers
to some than others.)

Also, I can't help but point out that I didn't say I enjoy it for all uses
either. I don't do my hobby programming in Go, because I don't have the issue
of other programmers doing things I disagree with or don't like. Even if I do
something stupid in another language, at least it's _my_ stupid thing and so I
tend to understand it better than somebody else trying to come in and see it.

------
wasted_intel
The "easy to learn" argument is getting old. If the cognitive load never
decreases, that's one thing, but initial ramp-up time shouldn'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't add much
when compared to other languages. Maybe that's a pragmatic choice, but it
feels short-sighted to me.

~~~
grey-area
_With the exception of channels, Go doesn 't add much when compared to other
languages._

It doesn't add things, it takes them away, notably exceptions, inheritance,
generics. I disagree that's short sighted, it's precisely for long term
maintenance that it becomes important to have less ways to do things. You may
not agree with the choices, but they are not only about being easy to learn,
more about being easy to read.

~~~
wasted_intel
People just end up inventing idioms to handle those, anyway. Go's nil-check
error handling is a prime example. That's a beautifully solved problem with
ADTs, but it's impossible without generic support, for starters. Runtime
errors, abound!

~~~
warent
Go can handle errors in a very deterministic way, and it can easily recover
from a weird panicked state. If someone's Go code has "runtime errors abound"
then they probably didn't RTFM ;)

~~~
wasted_intel
Ah, so when I think of deterministic error handling, I think of compile-time
enforcement, like that provided by a Result or Option type. Those can be
ignored too, though, although the effort to do so is a little bit more
explicit. :)

------
KirinDave
> 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.

Go programmers say this a lot and every time I see it I wince. We'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.

And so it's so confusing to me why Go programmers simply discard this
information, universally accepted as it has come to be. "The repetition is
simple," they reply, "and of course abstractions have cost."

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's so tempting to
start pattern matching the whole block of code and miss these subtleties.

This list'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.

Go has popularized a mode of writing code where not only are abstractions
unwelcome, but they're nearly impossible. As such, it is quick to learn the
syntax. It'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.

I just don't understand why anyone appreciated go's design space outside of
engineers-turned-architects trying to staff a massive tech org with engineers
they don't think very much of and have no desire to train.

~~~
treehau5
As Sandy Metz once said, "A little duplication is far better than the wrong
abstraction."

After a decade of OOP indoctrination and misuse, we see the results of this.

> Go has popularized a mode of writing code where not only are abstractions
> unwelcome, but they're nearly impossible

This lends me to believe you actually haven't written any go code for
yourself. This is the same thing every OOP-indoctrinated developer (Usually
Java or C#) has said before. I came from those languages, and this statement
is categorically false and completely unfounded in reality.

~~~
KirinDave
> After a decade of OOP indoctrination and misuse, we see the results of this.

Sure, but that's OO's fault and the lesson is not "abstractions are bad" but
rather, "OO's good at domain abstractions and bad at universal abstractions."

The takeaway should not be to discard the last 12 years of advances in
computer science and call it quits with a bad copy of Erlang's concurrency
model and a weak version of C.

> This lends me to believe you actually haven't written any go code for
> yourself.

I've written about 5000 lines. So not a ton, but enough to have shipped Go to
prod and be capable of reading it.

> This is the same thing every OOP-indoctrinated developer (Usually Java or
> C#) has said before.

Go is more OOP-focused with its weak interface{} methodology than anything I
promote or have used joyfully in the last 6 years. Even the most cursory
examination of my presence will reveal that.

Please don't put words in my mouth to tidy your argument.

------
pmoriarty
When Java was first introduced, the world was abuzz about this cool new
language which you could "write once, run anywhere". 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 "write once, run anywhere" turned out to be a myth, along
with a boatload of other reasons. The honeymoon wore off, and legions of Java-
haters were born.

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 "real programming language" 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 "Perl sucks!" mantra sprang up and the once-mighty Perl
shrank before the upstarts.

Ruby and Python are getting their turn now, and I'm starting to see some
people expressing hate towards them as well, though it hasn't quite reached
the pervasiveness of Java and Perl hate yet.

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's not to like. Well, the replies to this post are showing that for some
the honeymoon is already over.

Other languages had their day in the limelight, only to wind up being hated:
C++, Lisp, Fortran, Cobol, HTML, Javascript.

Bjarne Stroustrup observed that _" there are two types of languages, the ones
everyone complains about, and the ones nobody uses."_

Whenever some shiny new language comes out, promising to solve everyone'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.

~~~
burntsushi
> 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's not to like. Well, the replies to this post are showing that
> for some the honeymoon is already over.

As someone who has paid attention to this since Go was released, there _never_
was a honeymoon. The complaints in this thread have been the same exact
complaints people have been lodging against Go since 1.0 was released.

What you're seeing is very simple to explain. Some people love Go. Some people
like Go. Some people dislike Go. And some people hate Go.

~~~
pmoriarty
You could say the exact same thing about every computer language, but it would
miss the forest for the trees.

Certainly from the very beginning, there'll be some subset of the relatively
few people who've actually tried a new language who don't like it for some
reason or another, or object on legitimate technical grounds (the border
between these two types of objections is murky).

As the popularity of the language grows articles are written, starting in the
specialized press and (if the language is lucky) ending up even in the popular
press, getting even non-technical managers excited and using the newest
buzzwords.

With time, the recognition and consciousness of the language's deficiencies
become more widespread among a wider portion of the programming population,
and articles and discussions of such complaints become more widespread.

In the end, such complaints may become mere truisms, and the majority of the
population just parrot the truisms and stereotypes while having only a
superficial or even non-existent familiarity with the language that's
criticized.

Of course, you could say that such things were going on all along, but it
would be missing the broad ebb and flow of language popularity and people's
reactions to them.

~~~
burntsushi
Right. I understood that point. I'm saying that I think you're wrong. There
has been no ebb and flow from where I'm standing. The criticisms against Go
really haven't changed much, and neither have the people making them. On the
flip side, Go has been becoming increasingly popular, and I see no signs of it
slowing down.

~~~
pmoriarty
It's not an ebb and flow in the criticisms but in their adoption and the
awarness of them in the wider programmer population. It's that awarness that
ebbs and flows.

------
chris_st
I've been using Go for a while, and am frankly amazed at the quality of the
tooling.

I'll add something others haven't mentioned... the profiler produces an
absolutely _amazing_ 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.

0: [https://blog.golang.org/profiling-go-
programs](https://blog.golang.org/profiling-go-programs)

------
pjmlp
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.

~~~
nindalf
I'm not sure that I follow. To me, it sounds like someone saying we need to
program in C because we use git whereas we actually interact with git through
the interface they've given us, not through its source code. Even if Docker
and K8s become ubiquitous, I see no reason programmers taking advantage of
these to also program in Go.

~~~
pjmlp
It means that anyone that is working on DevOps, while having Docker/K8s on
their employer infrastructure, might eventually be asked to write Go for
whatever reason.

Given that they are written in Go, and as far as I understand it, the way to
customize them also requires using Go.

------
sandGorgon
I'm kind of wondering about why is there no production ready JavaScript/TS to
exe compiler that packages all dependencies and creates a single executable -
like go.

With the amount of mind share that js ecosystem has, I thought that would be a
thing.

The keyword being "all dependencies"

~~~
mlcdf
Something like [https://github.com/zeit/pkg](https://github.com/zeit/pkg) ?

~~~
sandGorgon
very cool! is this production ready ?

------
jernfrost
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.

------
gmoes
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.

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.

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.

To put it bluntly and I may get downvoted for this I feel Go is the “Rise of
the Expert Beginner Language”. [1]

[0] [http://www.elegantcoding.com/2012/02/software-reuse-
complexi...](http://www.elegantcoding.com/2012/02/software-reuse-complexity-
curve.html)

[1] [https://www.daedtech.com/how-developers-stop-learning-
rise-o...](https://www.daedtech.com/how-developers-stop-learning-rise-of-the-
expert-beginner/)

~~~
solidsnack9000
"The Rise of the Expert Beginner" was a great read. I do see the parallels to
the tone and tenor of some arguments in favor of Go.

One thing I wonder about is a seeming complementary anti-pattern, the "Expert
Only Language". Perhaps C++ is the only language that truly fits this
description, but one can see shades of it in Haskell, Scala & Rust. To a
limited degree, Bash and SQL exhibit similar qualities, because people can use
them for years but barely know them.

These are languages where a certain confusing richness is accepted as the cost
of doing business, and where a long period of familiarization is assumed to be
necessary before doing basic things.

------
vbernat
I wouldn'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's "flags" and Python's "argparse"
for example. And Go's "log" and Python's "logging". 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't use a third-party argument parsing
and logging package.

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.

For a language born less than 10 years ago, this is a pity.

------
nnd
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?)

~~~
fetchfetch
\- Real concurrency without having to deal with spawning multiple programs
that communicate over some higher level process

\- Good concurrency primitive (channel), although asyncio Futures in Py3
aren't that bad either

\- Strong typing

\- Easy byte-level manipulation

\- Extremely easy to learn

\- Simplistic error handling compared to exceptions (there are problems with
this I won't go into, but it's easy to learn at least)

\- Amazing tooling (gofmt forces your codebase to be consistent regardless of
who is writing it)

------
ausjke
Just use modern C++

~~~
andreasgonewild
Couldn't agree more, a much better investment of anyones time. C++ won't
suddenly refuse to solve your problems because they don't fit into an
arbitrarily limited view of the world. And some of the stuff coming out of
standardization lately is simply awesome.

~~~
_binder
Can you share some of it. Trying to get better at C++ here.

~~~
andreasgonewild
Sure thing. Bear in mind that this is my way of doing it; plenty of people
will yell blasphemy at the choices I make, and some may well turn out to be
suboptimal without 32 years of experience to back them up.

[https://github.com/andreas-gone-wild/snackis](https://github.com/andreas-
gone-wild/snackis)

------
squeeeeeeeeeee
I haven't looked at Go yet, but all these "is so easy to learn" and "generics
are bad because they're not easy to learn" 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.

~~~
secure
Only one way to find out… learn some Go? :)

As author of this article, I can only say that I wrote about Go because I
honestly like it, not because I have any agenda.

~~~
weberc2
It will take all of 2 hours tops to go from zero to writing an interesting
program.

------
DinoDano
Its the best, but I'm sad and shamed it is owned by google.

~~~
_binder
Why are you sad? It is backed up by on the biggest Software companies in the
world and the amount of free stuff Google is throwing around is mind boggling.

~~~
kuschku
It is backed up by on the biggest Software companies in the world and the
amount of stuff Google has their hands in is mind boggling.

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

~~~
thesmallestcat
It literally houses you and puts food in your mouth? I'd like to see that.

~~~
swah
Maybe they* live inside the O? Confusing.

~~~
empressplay
She =) But thanks for your sexist assumptions! They're awesome!

~~~
bauerd
Did you just assume personhood? You might be responding to a Markov chain for
all we know.

~~~
empressplay
Are you saying Markov chains can't be sexist?

~~~
coldtea
Seeing that they are mere algorithms, yes. Being X implies intention. At best
they can accidentally put out something sexist as a result of their input.

