
Why Go gets criticized so much - jorgecastillo
http://npf.io/2014/10/why-everyone-hates-go/
======
sievebrain
I don't hate Go. I do strongly dislike posts with clickbaity titles that have
an admission the title is wrong in the very first sentence.

The rest of the article is little better. It can be summed up in one line:
_People who dislike Go are upset because they incorporated their favourite
programming language into their identity, and the success of Go challenges
their own choices_.

Although I don't hate Go, I also don't like Go much, but it's not because it
challenges my identity. I am not a Haskell or Scala programmer. I've used a
whole bunch of languages in recent years, none of which are especially clever.
I dislike Go because I agree with the criticisms of it and I'm afraid I might
end up having to maintain code written in it one day. That wouldn't be much
fun.

Fortunately, so far I've been able to avoid maintaining PHP or COBOL so
hopefully my luck will hold and I'll be able to dodge Go too.

~~~
jb613
"I dislike Go because I agree with the criticisms of it and I'm afraid I might
end up having to maintain code written in it one day"

and:

"I also don't like Go much, but it's not because it challenges my identity"

You are EXACTLY who the article is talking about. One of Go's selling points
is maintainability. Go's inherent bias towards maintainability challenges your
identity.

~~~
sievebrain
Selling points are not facts, they're just arguments people who are trying to
sell something like to make.

Go's users and designers make all sorts of claims about it. As it happens,
I've evaluated them and find that I often disagree with them.

For instance, Go projects often don't specify the versions of their
dependencies and choose to just clone the code into their own source tree
instead - if you're lucky. If you aren't then the project simply depends on
whatever is found in the dependencies git master branch. I find this to be
poor practice from several perspectives, maintainability amongst them.

~~~
jb613
"Selling points are not facts"

except when talking about maintainability, you are not talking about facts.
Show me the "fact" that Go is hard to maintain.

~~~
sievebrain
I never said code written in Go is hard to maintain. I said I don't want to
maintain it, because I don't want to debug or write Go myself. You're arguing
with a straw man.

~~~
jb613
the article is suggesting that when people say they don't want to debug or
write in Go is because it challenges their previously formed beliefs in what
they believe they need from a language. The fact that there may be another way
or that projects are increasingly succeeding, challenges their identity.

------
Lewisham
Disclaimer: I work at El Goog.

I recently moved teams so that I could use Go exclusively. It's often been
said that Go solves the problems Google developers have, and it's 110% true.
It's much easier to get things working, and it's much easier to write things
like Protocol Buffers. But the key for me is that Go isn't fun in the sense of
"wow, I'm so smart that I managed to one line this thing", it's fun in the
"wow I read this code and I can understand what's happening and hack on it to
do something else."

I've worked on teams with monolithic Java code, and it's nigh-on impossible to
understand what's happening and where you are in the logic flow. I don't have
that problem in Go. I even delve into the standard libraries to see how the
original Go devs did something, and I both understand it and think it looks
like code I would have written too. I never get that feeling from any other
language, where I feel like the standard libs are written by hyper-intelligent
aliens.

When I exclaimed this internally, I got the sarky comment "It's almost as if
the things Go leaves out makes it easier". And that's the core of it. Would I
like generics? Sure; I do miss map(). But that's it.

Go is opinionated. People that don't like Go don't share the opinion. That's
OK. It's taken me a long time to realize there is no One True Language that
can do everything (it was soon after steveklabnik said something along the
lines of "I don't know why you'd want to write a web app in Rust"). Once you
get there, you won't hate Go anymore, nor indeed any other language.

Apart from C++. Screw that ;)

~~~
sievebrain
The reason Google's Java codebase is impossible to understand is not the
language, it's mindless application of 'best practices' like dependency
injection on an industrial scale. Guice is open source, anyone can go look at
it. Just imagine a big complex server in which the "new" keyword wasn't used
anywhere because everything was handled by the dependency injector. You get
these things:

1\. Things that should be compile time errors turning into runtime errors.

2\. An IDE that can't navigate anywhere or usefully analyze the code because
everything has interfaces between it.

3\. Things being mocked out in unit tests just because they can be, meaning
lots of superfluous code and tests that pass when they should fail.

There's nothing about Java that mandates this style of programming. It's the
result of years of programmers trying to be clever and finding ways to do
things better without being sufficiently cynical about new trends and
fashions. Given that Java is 20 years old, there has been plenty of time for
people to find ways of making simple things complicated.

Go will suffer this phenomenon too because it's not to do with the languages
themselves, it's to do with programmers who have safe corporate jobs finding
ways to make themselves stand out from the pack by inventing and spreading
'best practices'. If anything, Go will suffer it worse, because the language
itself is so limited, so there's more potential for bizarre hacks disguised as
cleverness. Like that Go profiler that worked by rewriting source code to
insert stuff between every single line of code.

~~~
doppioandante
Very recently I have begun to work as programmer, and having to work with PHP
I looked at phpunit and unit testing (first time I do it semi-seriously). The
guidelines for mocking that I have found are about dependency injection
(phpunit has some helpers, but I think that's it).

What is the alternative to it?

~~~
sievebrain
The problem isn't with the idea of using mocks in testing. The problems start,
as often the case, when people start religiously applying a design pattern and
end up over using or abusing it.

The problematic thought process goes like this:

1\. Gee, my tests are really slow and flaky and hard to run because they talk
directly to a database. I know! I'll swap out my real database connection with
an in memory database.

2\. Things are better, but they're still slower than I'd like. Maybe I can
just write a wrapper around my database code, make it implement an interface,
and then provide a custom implementation just for my unit tests. Instead of
having my class construct a database connection directly, I'll make it passed
in as a parameter. Then they'll be nice and fast!

3\. Whoa, now my tests run instantly! How great. This mocking pattern is
awesome. I want to mock everything! But hmm, I have a lot of objects and they
often depend on other objects, like services of some sort. And I was told in
school that God Objects and global variables are bad. So I can't use those
because I want to be a good programmer and good programmers don't use those.
This is making my code kind of a mess because now every time I want to
construct an object it takes lots of parameters when before it didn't.

4\. <reads some article on hacker news> Hm, this dependency injection library
sounds like what I want. Instead of constructing my objects directly, I ask an
"injector" to do it for me. And it will then consult a table of bindings, and
then find or construct the dependencies, and then build the object I want,
recursively. All I have to do is [insert long complicated process here].

5\. Meanwhile, some other programmers look at what's going on. Interesting!
They say. Those programmers know what they're doing and they're converting
their whole codebase to use dependency injection. They claim it's a best
practice to make testable code. We want our code to be testable too, we should
do the same thing. Plus, we can call this refactoring and code maintenance and
get paid for doing essentially brainless work, instead of having to take risks
on developing new features or fixing bugs.

The story ends like this: pretty quickly this newfound "best practice" is
spreading throughout your codebase like a fire, and now when you deploy your
app, you get an error whilst the app is running. You then try to figure out
what's causing the error but 25% of the time you try to follow a method call
you end up looking at an interface instead of code, and when you try to figure
out what implementation of that interface your app called you have to read and
decipher tons of binding definitions.

The correct place to stop in the above story was at point two. And the reason
is not just code readability. Once you start over-using mock objects, you can
start to discover that your mock is implementing what you _think_ that service
does, not what it _actually_ does, and you can end up with code that's
actually buggier than code written with traditional fat test dependencies
would have been. Fail.

~~~
doppioandante
Thank you, very detailed explanation.

------
gizmo
I think there is a better explanation for why people dislike Go. All
programming languages currently used for the web have gigantic downsides.
They're slow. They have terrible package management. They have poor standard
libraries. They have no static typing. They have no visual debuggers. They
have no good IDE support. They don't integrate well with frontend code. Some
programming languages are more flawed than others, and no programming language
fails on every front, but they're all pretty objectively terrible.

Then Google announces Go. A cross-platform systems programming languages for
high quality web services. That sounds great! I can't wait to see what Google
came up with.

So when people saw Go disappointment set in. It has some great properties, but
the language is not expressive. So Go web frameworks (like Revel) generate Go
code at compile time to get the dynamic parts working. Just like we did in the
70s to work around C's shortcomings. Want a container for a specific type?
Code generation! It's so clumsy. The lack of exceptions makes writing correct
code really tedious. A web service is not a device driver where every edge
case has to be carefully considered. Bailing out with an exception is fine. Go
disagrees.

I think the disappointment in what Go _could have been_ explains the vocal
dislike. There are only a few companies in the world that can create a new
programming language and ensure it becomes popular. Don't get me wrong. Go
isn't a bad language. It's just not the language that will push the web
forward, and Google was in a unique position to create a programming language
that would.

~~~
innocentoldguy
Elixir is fast, has good package management, has a good standard library,
exceptions are easy to read and debug, etc. Elixir doesn't have static typing,
but it is functional, so it doesn't really matter as long as your initial
assignment is correct. I can't really comment on IDE integration, since I
never use anything but Vim.

Maybe the static typing and IDE support are enough to make Go awesome for
some, but they don't really matter to me as much as concurrency, hot-plug code
deployments, the actor model, and stability.

~~~
phieromnimon
Elixir has optional typespecs that can be statically analyzed with a tool
called dialyzer:
[http://learnyousomeerlang.com/dialyzer](http://learnyousomeerlang.com/dialyzer)

------
pjc50
_People who dislike X are upset because they incorporated their favourite Y
into their identity, and the success of X challenges their own choices._

True for football teams, political parties, games consoles, superhero
franchises, religions, food choices, colour schemes, preferred spelling
variants, ...

~~~
jhall1468
Sometimes, sure. But none of those are our jobs (except if you are a football
player, politician, etc).

Computer programming languages are our jobs. It's okay to have preferences. I
(a full time front-end webdev), think Python is probably the best language out
there. But it doesn't define me, because that's just silly.

~~~
luchadorvader
I agree that a language doesn't define you but what I wonder if a person's
favorite language has some correlation to certain personality traits. I would
be lieing if I didn't say I get more enjoyment from some languages where other
people don't. Perl vs Python for example, pythons core values are to try and
make it only one way to achieve something, whereas Perl tries to give you
multiple ways to achieve something. I would guess that Perl may appeal more to
artistic people and Python would appeal to more engineering type of people.
This isn't a claim, more just something I think would be interesting to
investigate.

~~~
EugeneOZ
Ok, I write every day in Rust and JavaScript (and not just jumping monkey in
JS, but a lot of code). They are almost orthogonal languages. Will it fit your
theory? :)

~~~
luchadorvader
Are they both your favorite languages? Also there will always be exceptions.

~~~
EugeneOZ
Sorry for long reply. No, I prefer Rust, but right now it's impossible to use
Rust on frontend. I also know there are people who love Python, Scala, Nim, D,
Ocaml and I don't think they are wrong - it's just languages with different
flavours and there are people with other preferences, so it's awesome to have
alternatives. They are not better or worse than me if they use other
languages, I'm more than sure about it. But when we talk about PHP, Go, Perl -
yes, I think people could make better choice.

------
Kutta
Poor post. One of the worst thing you can do in a debate is to psychoanalyze
your opponents, ascribe their stances to some sort of personality trait, and
ignore the object level. More mundanely, it's just ad hominem, "haters gonna
hate".

What little object-level substance is to this post is laughable. Basically:
since Go doesn't have modern language features but it's evidently popular and
works, all the people who like modern features are upset since it turns out
the modern features aren't needed, after all. Half irrelevant, half assertion
out of blue air.

------
tomp
It's so easy to dismiss legitimate criticism of _any_ issue as "hate" and
"people are emotional" and "their identity is threatened".

At the end of the day, there _is_ legitimate criticism of Go, just as there
_are_ legitimate advantages of using Go. As an additional fact, Go's core
developers (and some users) have repetedly been dismissive of this criticism.

~~~
chillingeffect
Yes, this article tries to make it sound like issues with Go are _solely_ due
to identity, but that's not the case.

If I like to use soap and analgesics, is that part of my identity or just
common sense application of technology?

~~~
lpr22
There are studies that suggest using analgesics may negatively affect your
judgement, so there's that.

------
xg15
I haven't used go so far and much of its criticism might be overblown - but to
be honest, that article made me immediately dislike the author.

The basic argument of the article is that "People who dislike Go are upset
because they incorporated their favourite programming language into their
identity, and the success of Go challenges their own choices".

That can be summed up as "People who dislike Go do so because they have been
hurt psychologically".

Apart from being disrespectful to the community of other languages, this
basically makes it impossible to give a counter-argument: Whatever kind of
argument you bring, in the end you would simply add support to the author's
theory because, in fact, you _have_ been trying to criticise the language, so
you must be hurt. I don't see how that contributes to a fruitful discussion.

------
woodcut
I've been working in Go now for over a year and its honestly made my day-to-
day life as a software engineer enjoyable. What gets me down about working in
this industry is toiling away on products only to never see them released or
being frustrated by absurd compile times, poorly tested components and
abstract cathedral architectures. I worked on large C++ projects for around 7
years and i don't care for another flame war about curly brackets or which
reimagining of a string is more ascetic. I also worked in Ocaml and some
Erlang and yeah while great in principle they lacked the out-the-box tooling
and standardisation of practice that I absolutely love about Go.

If someone creates a ML variant with a day-to-day experience as clarified as
Go then I will gladly jump on board.

~~~
ZenoArrow
> "If someone creates a ML variant with a day-to-day experience as clarified
> as Go then I will gladly jump on board."

What about F#?

[http://fsharp.org](http://fsharp.org)

As a side benefit, it's appears to be the top paying tech worldwide ...

[http://stackoverflow.com/research/developer-
survey-2016#tech...](http://stackoverflow.com/research/developer-
survey-2016#technology-top-paying-tech)

... as well as one of the most highly regarded languages by those who use it
...

[http://stackoverflow.com/research/developer-
survey-2016#tech...](http://stackoverflow.com/research/developer-
survey-2016#technology-most-loved-dreaded-and-wanted)

Even if you end up not liking it, I'd say it's worth a try.

~~~
woodcut
I hadn't really given F# serious consideration, i know it's based off of OCaml
but looking at it now i'm not particularly enamoured by the idea of managing
threads, or doing async programming. Yes it does have an actor model but it
looks limited to just a message box.

I think Microsoft Orleans is the most interesting functional language based on
.Net
[http://christophermeiklejohn.com/papers/2015/05/03/orleans.h...](http://christophermeiklejohn.com/papers/2015/05/03/orleans.html)

------
jd3
``Go is not meant to innovate programming theory. It’s meant to innovate
programming practice." – Samuel Tesla

[http://go-lang.cat-v.org/](http://go-lang.cat-v.org/)

And as usual, [http://9front.org/who/uriel/](http://9front.org/who/uriel/)

~~~
mkesper
And as usual, [http://9front.org/who/uriel/](http://9front.org/who/uriel/)

Can you give some background?

~~~
jd3
spiritual leader of cat-v. good taster.

[http://uriel.cat-v.org/profile](http://uriel.cat-v.org/profile)

[http://plan9.bell-labs.com/wiki/plan9//uriel/index.html](http://plan9.bell-
labs.com/wiki/plan9//uriel/index.html)

[https://en.wikipedia.org/wiki/User:Lost.goblin](https://en.wikipedia.org/wiki/User:Lost.goblin)

[https://www.reddit.com/user/uriel](https://www.reddit.com/user/uriel)

[https://news.ycombinator.com/item?id=4654125](https://news.ycombinator.com/item?id=4654125)

[https://www.facebook.com/archangel.uriel](https://www.facebook.com/archangel.uriel)

[http://www.mozdev.org/pipermail/eu/2003-July/000001.html](http://www.mozdev.org/pipermail/eu/2003-July/000001.html)

[https://www.reddit.com/r/catv](https://www.reddit.com/r/catv)

[http://www.advogato.org/person/uriel/](http://www.advogato.org/person/uriel/)

~~~
copperx
I've never known anyone who's favorite movie was Three colors: blue. Maybe
I've found my spiritual doppelganger.

------
anonyfox
Go itself is a cool tool. Crosscompiling stuff, a great standard library, nice
toolkits like gorilla and marshalling from/to structs/json/xml comes in handy
for small everyday tasks and the primitive imperative style combined with
easy-to-use goroutines and quite good performance ... together its a very
great tool.

But I just can't stand the "the go way!" people who defend every fault the
language itself has with this mantra. I use go sparingly for small scripts and
little services, but would never _ever_ use it for big projects. Yes, for
programming rookies in a team its very easy to get started to make valuable
contributions, but I for myself just want a more adult language with rich
expressiveness and actual static typing (interface{} vs. generics _sigh_ ). I
understand Go as a "compiled PHP" with all the pros/cons one would associate,
and accept that it aims to be a "C as it should be".

I do not hate Go in any way, I use it when appropriate.

(PS: I recently realized for myself that Rust will be the ultimate game
changer, just give it a few months/years to grow mindshare organically. It's
everything but a beginner language, though.)

~~~
brndn
What is an "adult language"?

------
kazinator
> _Go is the only recent language that takes the aforementioned 40 years of
> programming language research and tosses it out the window [ ... ] no
> pattern matching, there’s no borrowing, there’s no pure functional
> programming, there’s no immutable variables, there’s no option types,
> there’s no exceptions, there’s no classes, there’s no generics._

Some of this stuff is quite a bit older than 40 years. That only brings us
back to 1976. Exceptions are around mid 1960's or so (PL/I, Lisp). Functional
programming, Lisp again, 1958. (Java-like) OOP Classes? At least as far back
as Simula-67. Simula-67 is where C++ gets "virtual" from.

------
EugeneOZ
Article didn't convince me to think following arguments are wrong:

* Go is a language stuck in the 70’s.

* Go ignores 40 years of programming language research.

I tried to use Go and was shocked how they can use it without package manager,
without generics, with so brittle concept of channels, with executable
comments in code and with so authoritative model of taking decisions about
language evolution.

So I still think criticism of Go is valid and authors are still deaf to it.

~~~
ufo
What are executable comments?

~~~
EugeneOZ
[https://news.ycombinator.com/item?id=9522973](https://news.ycombinator.com/item?id=9522973)

------
dudul
Couldn't this argument be made about all languages? People into dynamically
typed languages would have statically typed languages for the same "don't
touch my identity!" reason.

I personally don't "hate" go. To be honest, I have barely read 20 lines of go
ever. But I do not like the idea of a language _specifically_ designed to
limit my possibilities. I want to keep seeing "programming" as an art and a
creative activity. Not as a factory-like process where there is only one way
to do thing, all developers are inter-changeable, etc.

I _get_ why it's interesting for big corpos like Google. I just don't have to
_like_ it :)

~~~
blueprint
Nature works in the same way that it limits us to the fact that an effect can
only be obtained by its commensurate cause. Anything is possible through that
law as long as the appropriate cause can be formed.

~~~
talles
What??

~~~
blueprint
In math, answers are made by questions. In life, the quality of your answers
is determined by the quality of your questions. So make a concrete question
based in reality if you want a specific, real answer that you can confirm
against proof.

~~~
talles
Wow, you did all that nature analogy to say that the misunderstanding lies in
the question and not in the answers?

~~~
blueprint
That's incorrect. I was talking about your useless "What??"

------
rdtsc
It is a bit more nuanced. Go's dislike is a function of how vigorous the hype
for it was vs. how much it actually delivers + a few other things. In general
I see it as this function:

    
    
      def dislike(hype, results, community, usage): ...
    

Note the usage, if technology is not used, it won't be disliked. So dislike is
a good sign sometimes. Community attitude matters, how are creators and
developers treating others, how are well are docs presented, but also how
mature and behaved are the advocates of the technology. That is something
creators can't necessarily control.

Other hyped technology is/was node.js. I've heard people say crazy things
about, it is the best technology, everyone should drop everything and join the
winning team etc etc, async programming is the future and if you are still
using threads you are stuck in the past and so on. So it was hyped quite a
bit. And then it would have been ok, if it actually delivered, if packages
weren't broken and half-assed, if servers under load actually didn't crash and
so on. If people who used it where a bit more mature, if there wasn't drama at
every step and so on. So it ended up disliked quite a bit.

PostgreSQL is hyped, people are saying this is the end and all database and so
on. But it is not disliked, and the reason is it actually delivers results. It
handles JSON blobs, it does other things right, it doesn't catch on fire,
doesn't throw your data to /dev/null. So it not disliked.

As for Go, I haven't used Go, so I don't have much of a comment, but noticed
an interesting nuance with how some technologies just happen to be disliked
while others, even if hyped are ok.

------
alexandrerond
Seems most people don't understand that Golang is filling a niche that was not
covered by anyone: fast, type safe, portable, memory-managed, simple.

Every language sucks at something. Switching from Ruby/Python to Golang feels
like losing magic powers, yes, but some problems are better tackled without
that magic and type safety comes as a plus.

Ruby/Python/C/Java/Scala/Erlang/Elixir/JS/Haskell/Lisp/Clojure/Rust all have
different niches. We should really get over it.

------
Touche
> Go is the only recent language that takes the aforementioned 40 years of
> programming language research and tosses it out the window.

> The mere existence of Go says “your views on what makes a good programming
> language are wrong”.

As someone that dislikes Go, that's not it. It's because Go doesn't "own" the
fact that it thrown language research out the window.

If Go advocates waved their imperative programming flag proudly I would just
ignore the language completely.

------
jganetsk
I'm one of these ML-derived ideologues this article disparages. I hate Go
precisely because of the reasons outlined in this article. In my perspective,
OCaml and occupies mainly the same niche that Go does (same balance between
high-level and low-level, same skepticism of the object oriented orthodoxy,
etc). OCaml is a much better language than Go for so many reasons that I will
not go into here.

I'm also a Googler. Rather than inventing Go, if Google instead would have
made OCaml its "Go", the world would be a better place than it is today. If
the same tooling were built around OCaml, with some problems of its
implementation fixed (multicore/parallelism, etc), there would be no
complaints.

------
spriggan3
I don't hate Go. I think the language is half what it could have been if
designed more carefully. I don't doubt Go designers skills, I just think they
just stopped half way for various reasons. Which makes Go a bit frustrating.

However, I hate the Go community, which doesn't hesitate to humiliate people
trying to use language in unconventional ways (Martini...) and mock people
that come with a valid criticism of the language (rigid type system, lack of
dynamic linking, package management...).

So good language despite its flaws, horrible community. Now is it useful? It'd
be like asking if Python is useful despite its flaws, yet Python has a great
community unlike Go.

~~~
ngrilly
> humiliate people trying to use language in unconventional ways (Martini...)

The author of Martini, Jeremy Saenz, didn't feel humiliated:

[https://codegangsta.io/blog/2014/05/19/my-thoughts-on-
martin...](https://codegangsta.io/blog/2014/05/19/my-thoughts-on-martini/)

> lack of dynamic linking

You can build and link shared libraries since Go 1.5:

[https://golang.org/doc/go1.5#link](https://golang.org/doc/go1.5#link)

> package management

The Go team is listening to the community about package management and is even
willing to make changes:

[https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-
rw5t9MxJ...](https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-
rw5t9MxJwkfpx90cqG9AFL0JAYo/edit)

I agree that Go is a conservative engineering project, which can explain some
answers you read on Go mailing lists, but I think you mischaracterize the
community.

I would add that I'm tired of people repeating that the Go core team is
stubborn and doesn't listen to critics about the lack of generics, even though
they have provided substantiated answer on this topic:

[https://news.ycombinator.com/item?id=9622417](https://news.ycombinator.com/item?id=9622417)

I'm wondering who is not listening to who?

~~~
spriggan3
> You can build and link shared libraries since Go 1.5:

That was not my point and you know it. you can't load shared library at
runtime with Go. Like you can do in most languages out there.

> The author of Martini, Jeremy Saenz, didn't feel humiliated:

Yeah, he didn't feel humiliated so much he stopped writing about and
programming in Go and interacting with the Go community all together because
it's full of bullies.

> The Go team is listening to the community about package management and is
> even willing to make changes:

The Go team is listening to nothing.

> I would add that I'm tired of people repeating that the Go core team is
> stubborn and doesn't listen to critics about the lack of generics, even
> though they have provided substantiated answer on this topic:

That doesn't make them more open to changes, anybody can do an AMA for PR.

Go community is blind to its own shortcomings and the language issues, you
just proved my point yet again.

~~~
ngrilly
> you can't load shared library at runtime with Go.

I've read again the documentation, and you're right: it's not possible as of
Go 1.6.

> Yeah, [Jeremy Saenz] didn't feel humiliated so much he stopped writing about
> and programming in Go and interacting with the Go community all together

It's true that I don't see Jeremy posting stuff on its blog, Twitter, GitHub
or elsewhere since a few months, about Go, or about anything else. But how can
you assert it's related to the Go community being harsh?

> That doesn't make them more open to changes

I'm a bit of a programming language geek because I like beautiful theoretical
things. This is why I keep an eye on OCaml, Haskell, Erlang, Elm, Clojure,
etc. I sometime share the frustration with Go being verbose and naive. But I
also needs to get things done, and want my code to be readable, understandable
and maintainable in 10 years. Go is an interesting tradeoff, betting less on
the advances of PL theory, and betting more on good engineering (the excellent
work on the garbage collector being a good illustration).

Yes, I'd like some kind of shortcut for error handling (like the try! macro in
rust), I'd like to be able to define custom generic functions and containers
like the built-in ones, I'd like being able to declare non-nullable pointers,
and I'd like to be able to create "share-nothing" goroutines with a "let it
crash" philosophy. But I'm not willing to have these things if they break the
language main benefits, especially its simplicity.

Maybe the Go team is not open to the changes we're discussing because they
just don't align with their goals?

------
pacala
ML is also simple, pragmatic and from the '70s.

------
fixermark
"Go actively tries not to. There is no pattern matching, there’s no borrowing,
there’s no pure functional programming, there’s no immutable variables,
there’s no option types, there’s no exceptions, there’s no classes, there’s no
generics…. there’s a lot Go doesn’t have."

But one of the things it does have is users. It's almost like language
popularity is strangely orthogonal to that laundry-list of ideas that the
language theory community have invested a great deal of time in. I'd
hypothesize that for someone who is excited about those ideas seeing use (and
therefore somewhat justifying the time invested in pursuing and polishing
them), a language like Go skyrocketing in popularity relative to its age
([http://www.infoworld.com/article/2981872/application-
develop...](http://www.infoworld.com/article/2981872/application-
development/java-reigns-go-language-spikes-in-popularity.html)) --- a language
that looks at decades of PhD thesis work and says "tl;dr we have work to do
over here" \--- must be downright infuriating.

------
pythonist
Good points, and also correct answer. Identity is hard to question. But when
you try Go without prejudice, it's just fun (and productive) afterwards.

~~~
isido
With golang, it is incredibly easy to get productive fast. It's like
modernized, safe C with good standard library and trivial deployment. Those
are pretty good selling points for getting stuff actually done.

Using Haskell for similar stuff is more tedious, even if a actual coding is
more fun. I can see (and sometimes feel myself) the cognitive dissonance here.

~~~
sievebrain
I think the issue here is that you're comparing Go to C and Haskell.

C is decades old. Haskell was designed to help you write correct programs,
rather than simplicity of use or productivity (or that's how I'd characterise
it).

If you compared Go to C# or Java 8 or Scala, it'd probably look a lot worse.
Deployment isn't so difficult that Go has any advantage in my experience:
install a JVM on the server, ensure your build system is producing a fat jar,
run it. Done.

With Capsule you can even make self-executable JARs that have a little shell
script attached. Then you can run the program like any other UNIX app. chmod
+x and ./execute it. Fully self contained, and can even update itself
automatically.

~~~
jjuel
I use C# at work, and I use Go at home. I really do like C#, but there is a
reason I am using Go at home. I find I am more productive, and can develop
better code faster with Go even though I am very new with Go.

~~~
sievebrain
I'm curious which parts of Go you find more productive than C#. Visual Studio
slows you down?

------
LeoNatan25
Hate is a very strong word. I don't see a point in "hating". Strong dislike,
however, I can see, and I think my reasons for not liking Go are "Go ignores
40 years of programming language research", "Go is a language for blue collar
(mediocre) developers" and "that other people were falling for it." I guess I
have a similar dislike for every technology which is primarily meant to make
the life of the developer, rather than push the end product's quality. I guess
I have a dislike for this culture, that has been brewing in recent years, in
general. But is that my "identity"? I don't know. All I do when I see these
types of technologies, is roll my eyes, and move on; it means I have to be
more picky in my job picky when looking for jobs. People are taking this way
too seriously.

~~~
AnimalMuppet
> I guess I have a similar dislike for every technology which is primarily
> meant to make the life of the developer, rather than push the end product's
> quality.

I would suggest that this is short-sighted. After all, the end product is
created by the developer. Making the developer's life easier and end product
quality are not contradictory goals.

------
jfaucett
The gap between the premises and conclusion of this argument seems broad to
me...

Here's the summary: (leaving out some smaller arguments i.e. scala/rust vs Go
language philosophy)

1\. Go challenges peoples identity.

2\. Challenging peoples identity makes them respond emotionaly not logicaly.

3\. Other people are being deceived into liking Go.

4\. People become more vocal as they attempt to sway the deceived from their
erroneous path.

5\. (conclusion): Therefore, everyone criticizes Go so much.

Notice all the premises could be true, but they would not strongly imply the
"so much" part i.e. "a lot". It would just mean some people would respond more
vocally/emotionaly, certainly not everyone.

Anyway, I think there's still some missing premise(s) which would explain why
there is "a lot of" criticism for Go, if that is the case - I have no idea as
I'm not involved with Go at all.

Anyone care to fill those in for me?

~~~
jb613
One premise that I think the author is wrong about is #3 (people being
deceived into liking Go). My experience is that a number of folks liking Go is
due to past experiences and recognizing Go's completely different approach
resolves at least some of those deficiencies or the problems those practices
eventually led to.

But, I think the main point of the article is that Go's complete 180 on many
things challenges the beliefs of some and hence their identity. We see it
every time a discussion on Go pops up.

------
jrobn
One of Go's selling points is always it's a pragmatic language. But after
using it for awhile and implementing a few web apps and APIs in it. I've
crossed it off my list for web app or API development. It's great at making
standalone CLI tools, however.

I've since moved to using Elixir (erlang) for web app stuff (even some
scripts) and I am much happier. I'm not in love with Elixirs syntax, but it's
nice and includes meta programming. Elixir is a much more pragmatic language
in my opinion. Once you use things like pattern matching (what could be more
pragmatic) you can't go back. Raw performance is nothing to write home about
but in my use cases elixir does a great job of hitting the sweet spot.

~~~
spinlock
What's the performance of Elixir been like for you? We're looking into it
because of the actor concuttrncy model which we think will be much more
performant than our current ruby or clojure solutions.

~~~
jrobn
It's great at IO. Period. Get a request, pipeline it, transform it, call out
to a database, get some data back, fire off emails, talk to third party
APIs....

All of those can be structured as processes. All of those can be independently
fault tolerant. All of those can be inspected while they are running...in
production. Seriously, for HA APIs or web apps it feels like a no brainer.

I just wouldn't us it for things that are CPU bound, like image processing for
example. Try implementing something that is a bottleneck in your system in
elixir and then throw some data at it and see how it performs.

Elixir + Phoenix is a real treat for web app devs.

~~~
spinlock
Fantastic. Thanks for the response.

Our use case is talking to an API, doing a little bit of processing then
writing to a database. It's all IO with barely any processing (just a few
string substitutions to "normalize" the API responses).

------
tylermac1
Note: This is from Oct '14

------
xlm1717
>Obviously, not everyone hates Go.

Well, at least the author saves me the time reading the rest of the article.

------
JulianMorrison
Why would anyone think Go and Rust are bitter rivals? They're great tools for
different things, with a broad margin of overlap.

~~~
falcolas
Ultimately, they share a space - compiled, memory safe, and aimed at server-
side development.

The way they differ is mostly in how they approach memory safety, which gives
them different performance characteristics.

~~~
heinrich5991
Rust isn't solely aimed at server space: E.g. we have servo, a browser engine.

~~~
copperx
"aimed at" and "used for" are never disjoint sets.

------
CyanLite2
Go is one of the fastest runtimes out there, on nearly every platform,
produces one clean static binary, fixes the concurrency/async problem that
makes other lanaguages so terrible to code in, and has one huge company
backing it. But then they miss the boat on simple stuff like generics.

Everyone hates Go because it solves the problems that most other languages
suffer from. And if they (Google) make a few improvements it would probably
the The Killer Language of Choice out there. But instead they suffer from the
elite smugness and won't adapt.

~~~
bitmapbrother
Elite smugness? Hardly. Russ Cox has stated repeatedly that he's not against
the implementation of generics in Go. Adding generics to a language is a very
complex process and you have to be careful with the method you select because
you're stuck with it forever. When they find a proper way to implement
generics in Go then they'll do so, but they're not going to be pressured into
creating a bad implementation.

[https://news.ycombinator.com/item?id=9622417](https://news.ycombinator.com/item?id=9622417)

~~~
ngrilly
And Erik Meijer wrote "Often I wonder if generics are actually worth their
weight."

[https://twitter.com/headinthebox/status/705963164815327232](https://twitter.com/headinthebox/status/705963164815327232)

------
k__
I never used Go, but the main issues seemed to me that Google promised a C/C++
alternative and failed. Instead they made a Ruby/Node.js alternative.

I mean, telling C/C++ devs GC is the hit and parametric polymorphism suck?
What did they expect...

Don't know if I'm right, but that's the gist I got from all the comments and
news about Go.

------
innocentoldguy
While I agree with the premise of the article, I don't think this is why I
don't use Go. I don't hate Go, but I also don't think it brings anything new
or elegant to the party. Languages like Rust and Elixir are exciting to me. Go
just feels like a rerun of everything I've done before.

------
f0code
I've been using Go for several months and love it.

"People shouldn't like things I dislike." \--waaaah

------
beyondns
I like Go. I've little project
[https://github.com/beyondns/gotips](https://github.com/beyondns/gotips) The
essence of Go in some little piece of code:

select { case <-time.After(queryTimeLimit): cancel() <-done // wait
fmt.Printf("time out") case err :=<\- done: if err != nil { panic(err) }

}

//
[https://github.com/beyondns/gotips/blob/master/tips32.md#17-...](https://github.com/beyondns/gotips/blob/master/tips32.md#17
---use-context-api)

------
agounaris
I like functional languages but I strongly dislike their communities. Mainly
because they treat everything like a nail... Golang on the other hand focuses
on solving real problems not inventing things like metaisomorphic
multipolymorphism etc...as always technology is fair! Go check out the "real
life" projects in go and the adaptation they enjoy.

------
xigency
I would say Go is a very unintuitive language. And not in an especially useful
way.

Honestly, it comes across as a language designed by someone only incidentally
aware of programming. This isn't an argument, this is the first impression.

At the risk of sounding stupid, and not really having a say in the argument
for or against Go, I will say I tried to learn how to program Go on my own by
trying to "guess" how to write a program. (A time waster, I had seen code but
mainly glossed over it.) The program I tried to write was "Hello, World" and
the way I tried to guess was using the Go website's sandbox.

The result: [https://play.golang.org/p/oc-
cxnjJiI](https://play.golang.org/p/oc-cxnjJiI) (Best case:
[https://play.golang.org/p/NJpwhLUPA_](https://play.golang.org/p/NJpwhLUPA_))

I'm sure the same thing would happen trying to learn C++ from a compiler's
cryptic error messages, but C++ is not Go.

One thing I dislike about Go is the culture or lack-there-of surrounding it.
Especially in the canonical Hello World example, which chooses to use
Japanese/Chinese language in an unnecessary way. A little presumptuous.
Especially since it's used in a one-off sort of way with no explanation.

I also think it's interesting that it's the survivor of the Go and Dart
launches, when I never saw the purpose of Go when it was launched, compared to
a special set of libraries for C.

------
jokoon
There are many good things in go, but some very weird stuff too.

Good things are multiple return values, lack of semicolon, optional braces for
if and for, insanely fast compile time.

Bad things are forced curly brace style, complicated function declaration
syntax, variable declaration which is too different from C in my opinion (type
after the variable name).

I'd honestly prefer a language which is even closer to C or C++ in its syntax,
with native maps, sets, queues, tuples, etc (pythonic stuff) without
necessarily having templates or inheritance. I put a lot of value in syntactic
sugar over overblown abstract stuff. Using plain struct with data oriented
programming will be more than enough in most of the cases.

We are still waiting for C++ modules, which obviously might be lagging because
C++ has an ISO standard and a lot of existing code which involves backward
compatibility, but I think we need a new language that could be faster to
compile, just like go is.

~~~
hibikir
Types after variable names are here to stay though: they are in no way
something new, and make a hundred times more sense when there is type
inference: If writing down the type is optional, then it should go last.

Given that some level of type inference seems to be the future of strongly
typed languages, I expect variable ahead of type to become more and more
popular among language designers.

------
Gonzih
I did not like go until I tried it out on small pet project. Now I know how to
enjoy it.

~~~
akhilcacharya
Same. I hated the idea of it before I started to use it _and_ started to use
some of the tooling (like goimports, gocode, etc) with the go-plus package on
Atom.

I think tooling really makes the difference in this case.

------
mwsherman
Attributing a person’s preferences to identity is just ad hominem. That
doesn’t even imply it’s wrong or mean-spirited; it just means that it’s
“preferable” to talk about a person’s motives. Very Kahneman.

------
sargas
If you replace "Go" with "JavaScript" the whole blog would also apply. Except
there are way more JS lovers than Go lovers out there. And these two groups
almost seem to never overlap.

------
amelius
Offtopic: Can we please use "GoLang" for the language, so we can use "Go"
unambiguously for the game?

Especially in titles, where there is little context.

~~~
coldpie
I do find the name extremely unfortunate. It's impossible to search for, as
"go" is an extremely common word (bad for search engines) and substring (bad
for ctrl-F find). I tried searching for shared web hosts that provide Go
support and just gave up. Kind of hilarious to see a first-party Google
language be impossible to search for.

~~~
sesutton
Using "golang" instead of "Go" nearly always gives the correct results in my
experience.

~~~
coldpie
That's true-ish, although it seems unlikely that most marketing departments
who would be putting together a web server page would use "golang" over "Go".

Edit: This would be solved if the language was called "golang," which is
precisely the original poster's point.

------
nobullet
I have a strong feeling that there is a marketing campaign going to promote
Go. It is promoted so hard that it became annoying. :(

------
innocentoldguy
The main problem with Go, and this is a deal breaker for me, is that it forces
opening curly braces onto the same line, instead of putting them on a line by
themselves. This is clearly wrong, and flies in the face of curly good taste.

~~~
RodgerTheGreat
If it's clearly wrong, can you articulate a reason? There is at least one
(mild) argument in favor of opening a curly brace on the same line: code takes
up less vertical space, allowing a programmer to view more of their program on
a given screen at once.

~~~
kazinator
I use both styles in the same code:

    
    
      if (simple_condition) {
    
      } else {
    
      }
    
      for (long and stuffed;
           expressions;
           here)
      {
      }
    
      if ((complicated ||
           multi_line)
          && condition)
      {
      }
    
      void function()
      {
      }
    

In an if, all the "else if" and "else" clauses have to follow the same style.
If any is braced, they all have to be.

By the way, is grandparent _kidding_ about Go enforcing this?

The only language I can think of which enforces curly brace placement is Awk.
(And only in its pattern-action pairs):

    
    
       BEGIN {
         function()
         {
            if (foo)
            {
            }
         }
       }
    
       /regex/ {   # can't move this curly to next line
         action
       }

~~~
kazinator
RATIONALE: why the two styles? Why

    
    
      if (simple_condition) {
        code;
      }
    

but:

    
    
      if ((complicated ||
           multi_line)
          && condition)
      {
        code;
      }
    

?

Simple: it's because in both cases, the "code" follows a previous line from
whose first non-whitespace character it indents by the indentation level:

    
    
      if (...
      [INDENT]code
    
      {
      [INDENT]code
    

This is just wacky:

    
    
      while (blah
             blah
             blah) {
        code
      }
    

"code" isn't "indenting off of" anything. It is not related to the indentation
of "blah" in any way, but appears to be "deindenting" from it!

So, rather than dogmatically doing one thing or another, it's better to
consider all the alternatives, their relative advantages and disadvantages,
and integrate them into an elegant whole.

------
dismal2
why everyone loves clickbait

------
zxcvcxz
I like Go but I hate my self for it.

~~~
yvsong
Hating oneself is the highest form of love. -- Bill Maher on gay Republican
politicians.

------
gepoch
Very sorry to make an aesthetic complaint, and Raleway is a fine font for
certain applications, but blogs that use low contrast fine raleway for the
body text just kinda make me want to read something else.

------
GreaterFool
I would burn Go with fire and salt the earth because it's the bloody compiler
will refuse to compile my valid code if I have unused imports or variables. It
makes programming in Go a terrible experience and that's why I won't touch it.

~~~
Jabbles
You'll love goimports then.

[https://godoc.org/golang.org/x/tools/cmd/goimports](https://godoc.org/golang.org/x/tools/cmd/goimports)

Hook it to your editor's save command and never worry about imports again.

On the other hand, stop leaving unused variables around...

~~~
artursapek
I hate debugging someone else's code that has unused variables in it as much
as this guy seems to hate the go compiler.

~~~
GreaterFool
Any normal compiler usually allows overriding these options. I normally write
Haskell and it has it all: unused variables, unused imports, name shadowing,
non-exhaustive pattern matching, everything. But these things are _warnings_
in my dev build and _errors_ in the release build. That's a sane way to do it.

~~~
Jabbles
Except some people wouldn't enable -Werror, and the quality of Go code would
suffer on average.

Plus, now your compiler has _options_.

~~~
artursapek
Yeah. I'm a fan of mandates when it comes to things like compiler options.
Everyone should just suck it up and work with the same constraints. Warnings
are just errors without balls.

