
Why Go Is Not Good (2014) - kushti
http://yager.io/programming/go.html
======
joshbaptiste
[https://news.ycombinator.com/item?id=7962345](https://news.ycombinator.com/item?id=7962345)
<< 527 days ago, 356 comments

~~~
bargl
Thanks for the link. I'm kinda happy this resurfaced because I missed it on
it's first go around (pun intended) and I am happy I read the article. Its
nice to see some of these language features that I want to see in my language
as well.

------
cmrdporcupine
While many of these points (on generics especially) are completely legitimate,
this article will fall on deaf ears. My impression of the Go community (both
within Google and outside of it) is that there is a very ... moralistic? ....
sense of "You don't really need that, we know best" going on.

It aims to be a pragmatic language. But IMHO the anemic nature of the type
system is a practical handicap that they have made a point of pride out of not
addressing. It leads to boilerplate code and fragile code.

I am no academic language snob -- I like Rust, and have been known to like me
some C++ templating, sure, but I can understand a critique of complicated type
systems that laypeople cannot understand. But after my brief exposure to Go, I
was very very frustrated. I don't think it really solves the problems it says
it's solves.

~~~
grabcocque
Any critique of Go seems to be met with angry pitchforks in this place.

As you say, the Go developers seem to have developed a kind of bunker
mentality where they interpret legitimate criticisms of the language design as
personal attacks, and respond by wearing Go's shortcomings as a badge of
honour.

It's not, I think, entirely healthy.

~~~
bndr
> Any critique of Go seems to be met with angry pitchforks in this place.

You can say that about any language. The people that like the language will
always defend it. e.g. PHP, C, Ruby. They all have flaws and yet when one
talks about their shortcomings, the people get defensive.

~~~
m0th87
I think the point they're making is that the Go community is unusually
pitchfork-ey. Having used Go since pre-1.0 days, I certainly agree; there's a
very strong sense of, "if you want <feature X>, you're doing it wrong" \-
despite legitimate concerns, like the ones outlined in this article.

~~~
amyjess
I've heard this same criticism levelled at the Clojure community, as well.

Honestly, I can't think of any language community that's developed such a
reputation for pitchforkiness towards suggestions as the Go and Clojure
communities.

~~~
smw
What a strange argument. The difference is that clojure is about as extensible
a language as it's possible to have.

A macro system in a homoiconic language allows you to implement many types of
semantic sugar or things that would be full-on 'language features' in other
languages as a simple library. See core.async:
[https://github.com/clojure/core.async](https://github.com/clojure/core.async)

~~~
amyjess
Steve Yegge has written a lot about this. Much of his writings on the subject
are in these mailing-list posts:
[https://groups.google.com/d/topic/seajure/GLqhj_2915A/discus...](https://groups.google.com/d/topic/seajure/GLqhj_2915A/discussion)

Make sure to expand all of his posts on the thread, because he goes back and
forth for a while.

Much of it has to do with the community's attitude towards macros: there's an
attitude of "macros are bad and you shouldn't use them", and people who write
macros are often jumped on by the community.

Here's one sentence of Steve's that sums it up:

> When people announce: "hey, I made a loop macro!" the response absolutely
> can NOT be: "why can't you just write it as a series of maps and
> reductions?"

And another:

> If Clojure people all said "of course you can use macros! Of course you can
> use CL-style loop facilities! It's your code, do what you like! Feel free to
> use nonlocal exits all you like!" \-- well, then it would be a lot closer to
> a Yes language.

The problem is the way the community treats people who don't follow the
prescriptive norms of the core Clojure people (norms which are often in
conflict with the broader Lisp community).

~~~
lispm
Using 'macros' is no substitute for having taste.

The Clojure developer had a certain vision for a new language - otherwise he
could have just continued to use Lisp (which he earlier used for a few years).
It might be useful to respect that and develop Clojure along this vision.

Something like Common Lisp follows a different vision. Common Lisp was a large
community effort and the language EXPLICITLY had been designed to be morphed
by the user into widely different shapes. That's why it reserves characters to
the user, why it has a programmable reader, why it has procedural macros, ...,
and why CLOS has a Meta Object Protocol. Probably that was also too much
flexibility.

But even with Common Lisp, because it gives you little guidance how to use it
and there are a gazillion programming styles possible, you need to develop
taste. You can design ugly code and extensions and you can learn to develop
better code and extensions. Common Lisp supports LOOP, because it was already
there (it was introduced with Interlisp in the 70s, then brought to Maclisp
and Lisp Machine Lisp) and there wasn't a better alternative at that time.

The 'best' iteration construct in the Lisp world is Jonathan Amsterdam's
Iterate. But that would also not fit well into Clojure... But Iterate fits
well into Common Lisp and works nicely as an alternative to LOOP.

------
evmar
This sort of gratuitous takedown is unfortunately crack for HN -- pages and
pages of "here's how this popular thing is not like this other thing I like",
without any thought given to why things are they way they are. Go is missing a
lot of my pet features too but I know its authors are smart so I don't just
immediately jump to assuming they don't know what they're doing.

Thought experiment: write a proposal that works through adding algebraic data
types (or even just special-case the error handling as option types, if that
is easier) to Go. I've tried it; I found that doing so brings up a bunch of
other problems that don't make it an obvious solution. (E.g. you'll want a
"match" operator. And then that means you need all statements work as
expressions. And you'll have to change how zero values work, which are
pervasive throughout the language.) And I really like algebraic data types in
Haskell.

At some point if you really want Haskell you should just use Haskell. Or Rust.
And then you will find out that those languages have problems too, and you
will understand that engineering is a question of tradeoffs, not of feature
checklists like this blog post.

~~~
pcwalton
> E.g. you'll want a "match" operator. And then that means you need all
> statements work as expressions. And you'll have to change how zero values
> work, which are pervasive throughout the language.

You don't need to make everything an expression for pattern matching to work.
See Bjarne's C++ proposal: [http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2012/n344...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2012/n3449.pdf)

You might have to change zero values, although you could make algebraic data
types all be nullable if you wanted to avoid doing that.

~~~
evmar
Thanks (as always) for your informed comments!

I agree that you can make pattern matching work without expressions. My
intuition is rather that it's not especially useful, because you need some way
to make use of the result of the match.

Either you embed the rest of the function into the branch of the match
statement, or you're back to stuff like:

    
    
        foo := ... # Some zero value ...perhaps nil?
        match get_foo() {
          Some(x) => foo = x
          None => return
        }
        # now use foo here
    

That is, to make _use_ of the result of the pattern match you need a way to
get the value out of the pattern match which puts you back in the kind of code
where there's no pattern match. You could make just "match" be an expression
but now the arms of your match must be expressions which runs again into the
problem of Go being a statement-oriented language -- for example, you might
want to construct a struct in your match arm but if you can't fit the struct
construction into a single expression you're stuck again. (It's a similar
problem to Python's lambda.)

There might be some other nice way to make this work, of course! All I am
suggesting that if one does the effort of making a concrete proposal you'll
find that any small feature like this brings in a bunch of related ideas (like
Rust's semicolon) and is not as simple as "just add option types".

------
fixermark
"Go does not support operator overloading or keyword extensibility."

Very much working as intended, I believe. Experience from languages that
support those features has shown that what we gain in the very few situations
where those extensions make sense (such as defining mathematical operations on
vectors using the same symbols that are used in vector mathematics), we lose
in too many developers thinking they have a clever shortcut that an existing
operator would be perfect for, to the detriment of readability and
comprehensibility.

This is also the era of code-analysis-by-search-engine, and operator
overloading harms that feature significantly. If I need to find all instances
of vector addition in my code and I'm searching for '+', I'm going to have a
bad time.

~~~
coldpie
This is a well-written objection and I completely agree. Operator overloading
is consistently one of the worst ideas I see in programming languages, C++
being the prime offender. Programmers think they're being clever when they
write crap like

    
    
      boostfs::path path("/some/path");
      path /= "yourfile.txt";
    

Meanwhile, reading your code without being familiar with boostfs::path, my
brain grinds to a halt while I try to understand what in the hell dividing by
a string is supposed to do.

This is one of those "well intentioned" features that turns into a quagmire in
practice.

~~~
masklinn
> Operator overloading is consistently one of the worst ideas I see in
> programming languages

Except when not having it is the worst. Working with BigDecimal in Java is
hell because it does _not_ have operative overloading, meaning while you avoid

    
    
        boostfs::path path("/some/path");
        path /= "yourfile.txt";
    

you get saddled with bullshit like

    
    
        x.add(x.add(ONE).pow(2).subtract(x))

~~~
coldpie
Eh, there's already no language symbols for exponentiation (unless you're
really going to overload XOR in which case you're already part of the
problem).

~~~
pcwalton

        func SameSideOfTriangle<N>(p0 Point2D<N>, p1 Point2D<N>, a Point2D<N>, b Point2D<N>) bool where N: Number {
            ba := Point2D(b.x.Sub(a.x), b.y.Sub(a.y))
            p0a := Point2D(p0.x.Sub(a.x), p0.y.Sub(a.y))
            p1a := Point2D(p1.x.Sub(a.x), p1.y.Sub(a.y))
            cp0 := ba.x.Mul(p0a.y).Sub(p0a.x.Mul(ba.y))
            cp1 := ba.x.Mul(p1a.y).Sub(p1a.x.Mul(ba.y))
            dot := cp0.x.Mul(cp1.x).Add(cp0.y.Mul(cp1.y))
            return dot >= 0
        }
    

Versus:

    
    
        func SameSideOfTriangle<N>(p0 Point2D<N>, p1 Point2D<N>, a Point2D<N>, b Point2D<N>) bool where N: Number {
            ba := Point2D(b.x - a.x, b.y - a.y)
            p0a := Point2D(p0.x - a.x, p0.y - a.y)
            p1a := Point2D(p1.x - a.x, p1.y - a.y)
            cp0 := ba.x * p0a.y - p0a.x * ba.y
            cp1 := ba.x * p1a.y - p1a.x * ba.y
            dot := cp0.x * cp1.x + cp0.y * cp1.y
            return dot >= 0
        }

~~~
coldpie
I didn't mean to imply that it is _never_ useful, just that it's not worth the
baggage in my experience.

Genuinely asking: Why does this function need to be generic over Numbers?
Couldn't you implement it once or twice for whatever actually-numeric types
you need? How many different Point2D template instantiations do you actually
have?

~~~
pcwalton
In my project, i32, u32, f32, and f64. Possibly others.

And that's only a small function (only one part of what's needed to check
point-triangle intersection!) Copying and pasting e.g. Sutherland-Hodgman
clipping or 4D/5D matrix math would get unsustainable quickly.

------
the-tomster
The author says that "all the problems listed here have already been solved"
by Rust and Haskell. Great, so let's stop complaining about Go and use those
languages instead.

Go has specifically rejected the complexity that these features introduce,
both in the implementation of the language and the writing of programs in it.
If you want those features, just use a language that has them. Some other
people might not care about those features, and prefer the simplicity of Go,
and that's fine too.

~~~
wwweston
> The author says that "all the problems listed here have already been solved"
> by Rust and Haskell. Great, so let's stop complaining about Go and use those
> languages instead.

I applaud your advocacy. Using other languages is pretty much my personal
plan.

The problem, though, is that like everybody else in the industry, I don't work
in a vacuum. Other people may be making platform decisions for projects I work
on.

Complaining about Go's limits seems like a good additional strategy to
minimize the chance that I'll have to work around them again in the future.

~~~
gendoikari
I don't think the whole industry chooses its tools randomly. I think that in
the long term, if a tool emerges from the dust it's because of some actual
reasons. If the simplicity of Go will win against the complexity of Rust, for
example, I think we should think about the reasons. In my opinion the problem
it's not about Go limits, but instead is about our perspective as developers
using our tools. We do really need complexity? We do really need oop
everywhere? If the answer will turn out to be "no", I will need to change my
attitude toward Go.

~~~
wwweston
> I don't think the whole industry chooses its tools randomly.

It may not choose entirely randomly, but that doesn't mean that it chooses
_reasonably_. You mentioned OOP everywhere -- a philosophy that's driven
several dominantly popular languages and has been seen as a mark of
professionalism. If the industry is any guide, Go's break from the norm here
already calls that decision into question.

(I happen to think this is one of several areas in which the industry is
wrong, but then again I don't see the industry at large as particularly
rational.)

> We do really need complexity?

No software developer wants complexity, every software developer is trying to
manage and limit it to the extent of their resources.

The question is whether _language_ simplicity leads to _software_ simplicity.

It seems apparent Go's designers believe this is the case, and have offered a
simple-ish language on a feature diet that avoids much in terms of type
expressivity or facilities for abstraction that rise to the level of
augmenting the language itself.

I think this can work for some problem domains, particularly one that is
closely-fitted to built in types and libraries. But once your problem domain
isn't close to native language facilities any more, you're forced to write
more and more code to get around the limits of the language's expressivity.
That ends up being more machinery and surface area to keep track of
interactions between... which, in my experience, is where complexity creeps in
rather than having to understand language features.

~~~
gendoikari
If rationality were a requirement for progress, progress wouldn't exist. The
beautiful fact of evolutionary processes it's that rationality is not
necessary. But I digress...

Needs change with time. In the current context, if Go is an improvement in
some tech areas I think it will get some degree of success. Otherwise I think
will decline after the first hype.

By the way, I agree with you about writing more code to overcome language
limits. The hope here is that using idiomatic Go you will end up, no matter
what, with a reasonably understandable code base, even for libraries and
tools. It's a goal, I don't know if reachable or not.

------
Zikes
I like Go. It's fun, it's fast, and it's introduced me to a lot of programming
concepts I had never used before.

The one thing that seems to be missing from these discussions is that Go fits
in an unexpected niche. I come from a web development background. I grew up on
Perl, ASP, PHP, and Javascript. I dabbled a bit in C in college, but I always
felt like I was fighting to avoid shooting myself in the foot with it. For me,
Go was a huge step up, with an extremely friendly and approachable syntax,
comprehensive standard library, and great toolsets.

On the flip side, we've got a bunch of C/C++/Java developers who would rather
compare it to what they've been using for decades. I've no doubt it's missing
a slew of very important features from that perspective. Go does seem to be
capable of many of the same things as those languages, so those criticisms are
likely valid, but for those of us that aren't trying to use it as a low-level
systems language it's still pretty great.

Go could probably be improved in a lot of ways, but at the moment it serves my
needs really well. For me, Go is good.

~~~
mike_hearn
I think the main question then is, why don't you take a look at more modern
languages than Go and see if you have the same experience (fun, fast,
introduces to new programming concepts)?

You could start by checking out
[https://kotlinlang.org/](https://kotlinlang.org/) \- it targets the JVM so
the tools are much better than what Go has and the library ecosystem is much
larger. The language is a straightforward imperative style language that will
remind you of Go. It also will take just a few days to learn, at most. But it
has a slew of features Go does not have which have been proven in many of the
world's biggest and most popular languages.

~~~
Depado
Targeting the JVM seems like a trending practice nowadays. But I can't really
see why it's so great. You'll need to install the JVM to your platform before
you can execute anything. You'll also need to install it on your server to
serve a web application. I don't know how that works but it sure adds some
complexity to the deployment.

~~~
mike_hearn
If by "install" you mean "unzip", sure.

People like JVMs because they provide a lot of services that are really
useful, such as:

• State of the art garbage collectors, which you can tune for throughput or
low pause times (there's a fundamental tradeoff here, there's no one-size-
fits-all GC algorithm)

• Visual debugging that always works, including remotely

• Stack traces that always works

• Advanced profiler and monitoring tools

• Very robust and portable build systems

• Extremely fast compiles (this is touted as an advantage of Go, but I never
find myself waiting for a compiler when working with Java or Kotlin).

• Giant standard library and even larger ecosystem of well designed and
documented libraries to do many different tasks

• Language interop - you can normally use libraries written in one JVM
language from others. This obviously helps with the former point.

• In some cases (e.g. actor frameworks and big web servers) code hotswapping
and dynamic loading.

The Go runtime lacks a good chunk of these useful features: the last time I
worked with a Go shop they told me debugging hardly worked, because error
handling was "propagate an error code" they never had stack traces in their
logs for failures, profiling was primitive or not available at all depending
on platform, the standard library was small (compared to the JDK), and
language interop was "it can call C". Also the GC sucked, though I heard they
have a better one now. But it's still a one-size-fits-all approach, which has
well known problems.

~~~
Zikes
It seems to me that the majority of those features are a result of Java being
20 years old. It's entirely possible Go could achieve or surpass those
features by its 20th birthday.

------
aikah
> I like Go

Me too, and that's precisely why I kept complaining for a time about these
exact stuff until I moved on to something else.

People don't complain about the stuff they do not use, they actually complain
about the stuff they have/want to use everyday. But that's a good thing for
the remaining users on go-nuts, most people that complained moved on, which
means that a good chunk of them stopped using Go. I really really wanted to
use that language, the "you don't need that in Go" patronizing tone on the
mailing list made not want to use it anymore.

------
pbnjay
Go's biggest strengths for me around the tools and ecosystem, and code
readability. I very rarely find myself wanting generic code, and when I do
using empty interfaces make the code difficult to read.

I don't want to start an imperative-vs-functional war or anything, but I've
noticed many of the people complaining about Go seem to be functional
programming aficionados. Is this because of how much they like embedding and
abstractions, or is it because they're trying to put the square Go peg into
the round FP hole?

~~~
dradtke
The things I tend to miss most in Go are the functional operations, so I'm
inclinced to agree. On the flipside, when I'm programming in Rust or Haskell,
I can spend a couple hours optimizing a particular expression until it feels
"right", which sometimes never happens. It's incredibly fun, but it's not as
much of a problem in Go, since it's not as fun to tweak.

------
iffycan
As feedback on the article itself, I kept getting confused. The author
describes a wish:

> If I write a function to sum a list of numbers, it would be nice if I could
> use it on lists of floats, lists of ints, and lists of anything else that
> can be summed.

I agree with the author and continue reading, expecting to see an
implementation of that function in each language. I keep reading and re-
reading to try to figure out how the first two code samples (Rust and Haskell)
are summing a list. I feel like an idiot, because I can't figure out how that
code is possibly summing a list. Thankfully, the next paragraph explains it,
but a heads up would have made it more clear.

The article continues with pairs of Rust and Haskell -- as a reader, I'm
thinking, "Yes, yes, but show me how this compares to Go." Finally, when I get
to `Go's Solution: interface{}` I feel like I'll be able to compare the
languages... but instead of implementing an already-mentioned problem, a new
problem is introduced:

> Let's say you wanted to write a function that printed a hash code for
> objects that could be hashed.

As a reader, I have too many things in my head now.

I think the author probably has valid points to make, and I will now finish
reading the article. Hopefully some of this feedback is helpful (I'm not
trying to be a jerk).

~~~
wyager
Thanks for the feedback!

I did that in an effort to be fair to Go. You _can_ write a generic Hashable
interface in Go, so I started with that. The very next example is why you _can
't_ make a generic sum over a list in Go. I didn't want people to get the idea
that Go didn't support any sort of genericism at all.

------
tjholowaychuk
I think this post neglects the fact that one of Go's biggest strengths has
almost nothing to do with the language. A huge portion of every-day logic is
implemented very well, and very consistently in the stdlib.

Personally I don't want to go pick through half-baked third-party packages,
mix and match concurrency models or GC. I have experienced enough of that in
Node and it's not pretty. Having it all consistently implemented in the stdlib
is a great feature.

Go not being cute was also something I found attractive, I'm not particularly
worried about how much I type, because typing has never been a bottleneck. I
prefer that code is easy to comprehend. My biggest problem with Go as a
language is the arbitrary nature of some aspects when it comes to
assignability etc.

When Rust or Haskell can say the same I'll definitely invest in them but until
then it's just not a problem. I don't think it's about one language being
academically better than the other, it's what is best right now for the job
you're doing. I want those languages to do well of course, more options the
better, but for now Go ticks the right boxes for a lot of people.

~~~
x1024
But... Python already exists? Sorry to go all old-school on you, but the
quality of Python's stdlib has literally been a part of pop culture for more
than half a decade: [https://xkcd.com/353/](https://xkcd.com/353/)

~~~
thegeekpirate
> But... Python already exists?

He never said Go was the only language which had a wonderful standard library,
only that it's

> one of Go's biggest strengths

------
bfrog
After having been the primary author on a large go program, I'd personally
never choose it again. It fails to help solve several major issues where other
language like swift and rust seem to solve them wonderfully.

Just looking at the Option<> type in Rust alone makes you wonder just how many
places have you really forgotten to check or write tests to verify you check
for nil values. Probably too many. That one thing is enough of a win over most
languages today that I'm sold on the concept entirely.

Can we all agree to raise our pitchforks and torches in the general direction
of the terribleness that is null?

And how would someone implement Option<> if not for type generics. Because of
the lack of type generics in Go your stuck writting run time tests for things
like type conversions and nil value checks. A complete waste of precious
developer time. Thats the real loss. Time.

------
issaria
This post seems to rising from ash. Definitely saw it on HN year ago.

I don't want to say the word "perfect language", but there is no such language
that can meet the demands of every nerd on the planet, the goal of the Go
programming language is stated clearly, compiling speed overweight the needs
for generics, that's why LLVM is not considered for the go compiler.

Also the language is considered feature complete, if one doesn't want to met
with "angry pitchforks", do the homework, e.g. the generics topic has been
picked up over and over, that it's not funny anymore, if you are interested,
the amount of debate online can take days to read.

~~~
doodpants
One of my big peeves is when a blog does not have a date stamp at the top of
each post. Some have the date at the bottom of the post, which is less
convenient, but at least it's there. Others don't have a date stamp at all,
but you can guess when the post was written by looking at the date of the
earliest comment, or the date is included as part of the permalink URL.

Will Yager's blog seems to have no possible way of determining when a post was
written. Which is especially frustrating since the very first paragraph of the
post in question includes the phrase "at the time of writing". Well, when was
that!?

------
AYBABTME
Can we get over "it doesn't have feature XYZ"? Everybody knows it doesn't have
generics and that it would be convenient. Doesn't make the language
intrinsically bad.

There should be a point where a problem has been talked about ad-nauseum. I
think people saying this will fall on deaf ears misunderstand that the Go
community has been there, done that. We all know it, we'd like to have it and
the Go team knows about that, and they stated why it's not there yet (because
the tradeoffs available to them aren't interesting enough to make a decision
with either implementation).

Until this changes, I think we can all just get over it.

------
Kapura
I've used Go for a few projects and I think that people who point out all of
the things that Go doesn't have and Go doesn't support misunderstand the
language.

The problem is that most big languages today are hammers, and they can are
used to hit all sorts of nails to fasten all sorts of unholy planks together.
Go is a screwdriver. Still good for construction, but you need to be using it
in the correct way and you can't wail away at the problem the same way you're
used to. Hammer people try to pound the screw in and get frustrated at the
resistance they encounter. Perhaps they should instead ask themselves why the
choices have been made, what possible benefits come from using a different
tool. And you know what, maybe they just prefer hammers. Nothing wrong with
that.

~~~
danieldk
_I 've used Go for a few projects and I think that people who point out all of
the things that Go doesn't have and Go doesn't support misunderstand the
language._

This is the standard Go defense. 'It's not Go, it's you.'

I have written some larger projects in Go, and I am in full agreement with the
article - Go is a relatively weak and repetitive language, similar to pre-
generics Java.

So, why does Go gain so much traction? While it may be a weak programming
language, this is often compensated by excellent tooling and easy
deployability. Plus dyed-in-the-wool Unix users (me inclusive) never liked the
JVM baggage that comes with JVM languages.

~~~
fromMars
Java's verbosity makes me want to puke. Go wins over java on this point alone.
I wish go had generics, but, overall, I enjoy writing Go, because I can do
most of the things I did in java while feeling like I am writing python.

I like other languages like Haskell (haven't looked at Rust), but I can't use
it on the projects for a variety of reasons.

~~~
mike_hearn
Modern Java (e.g. 8+) would seem to be much less verbose than Go, as well as
being more type safe, once you take the if (err != nil) boilerplate that seems
to infest all Go code into account.

If you didn't do any Java for 10 years then maybe Go looks good in comparison,
but I don't see how with the modern stuff, especially when you compare IDEs,
debuggers, profilers and other tools.

But if you want something much more concise than Java, look at Kotlin or
Scala.

~~~
srameshc
I tried Scala and Akka. And then I found Go Concurrency. And then I decided to
stick to Go. Scala and Java 8 are probably better, but the simplicity that Go
brings in can not be compared to.

------
andrew_wc_brown
Go is good enough when you're switching from Ruby to Go and all you do is
build web-applications.

* Its forced syntax stops syntax wars. * Compiling down to one binary makes deployment easy. * Its has concurrency out of the box. * Its insanely fast. * A strong community to hire developers easily enough.

Does Haskel/Rust have the same criteria? Shurgs

~~~
orvado
I believe all of these are good points. The keywords are simple and concise
and I believe the language constructs such as interface{} and sub-typing were
designed to ensure compilation and running are insanely fast. Google is famous
for optimizing their server applications and Go appears to be their "go-to"
language of choice for all future web application development.

~~~
codygman
Interface{} (not interfaces as a whole) and subtyping would make compiling
slower. I think sum types and pattern matching would compile faster and be
more sensible.

------
joined
If anyone is looking for the article publishing date (no indication on the
site), archive.org made the first snapshot on June 2014.

~~~
carols10cents
Yeah, I suspected it was old when the Rust version used was 0.11...

~~~
hatsunearu
The most often encountered thing that I find Rust frustrating is how much the
language changed over time--lots of random answers and posts that are outdated
floating around somewhere that I have to throw out because the language
changed.

~~~
krisdol
It's just incredibly young at this point, and still in a phase where making
breaking changes for the sake of the language vision is acceptable. Swift has
been in the same boat. I'm sure that will change in the near future. Luckily
both languages have great compilers that catch backwards-incompatible issues.

------
jmquigs
There are some things I like about Go:

1) really fast compilation speed

2) goroutines

3) gofmt

But I learned F# after learning Go, and it felt like I was walking out of
Plato's cave. Its hard to use a Go-like language after using the ML-style
features described in this post.

Most modern static languages shift the debugging from run-time to compile-
time, which is a huge win in my opinion, but Go does not do this. You don't
even need to go "pure functional" to get the benefits (as in Haskell),
Rust/F#/OCaml are fine.

------
mydpy
When I first learned Python and Scala, they 'hooked' me practically instantly.
As my ability with these languages matured, I learned their strengths and
weaknesses, and (try) use the tools where their strengths are complimented.

Trying Go had practically the opposite emotional response: It didn't take long
to get a bad taste in my mouth while using the language (a lot of, where is
feature X from my favorite language, and why does the Go approach feel so
jagged by comparison?), and as I read blogs like this that emphasize the
weaknesses of the language, I don't feel compelled to write anything using Go.

With so many options, why bother with Go? Am I missing something?

~~~
TeeWEE
Ever wrote a big program in python? Then you know it works at runtime. Not at
compile time. Go comes with more typesafety while being a bit more verbose.
Its a tradeoff.

~~~
Filligree
And yet Rust has more type safety, while being more concise, more expressive
and faster.

Which is the article's point.

~~~
oscargrouch
Yes, but is less productive than go. You need more to express te same.

Rust is like a phone with a lot of buttons and commands, give you more options
and freedom of choice. Go is like a simple phone with very few buttons which
has enough to enable you the real purpose of the phone, to make phone calls.

Its just more pragmatic, and that doesnt make it a sin.

Particularly, i like to have options.. its good we have them all, and we can
choose the right tool for the job.

------
fixermark
For me personally, it's not what the language offers syntax-wise but what I
can do with it.

I was excited about Ruby because of Rails; only after working with it did I
pick up a book on Ruby itself and come to appreciate the cleverness of block
arguments (Ruby's insight, that functions that accept another function as an
argument almost always accept at most one, so special-casing the syntax for
that to make it clear, was really quite clever). And then I migrated away from
using Ruby when I started to care about execution speed and couldn't escape
the feeling that I was investing more time keeping up with the framework
changes than I was writing my program.

For Go, I can write fast web servers in it. That's what I want, and it shines
for that use case. I haven't looked at Haskell for that use case yet. Rust is
still figuring itself out in that space
([http://arewewebyet.com/](http://arewewebyet.com/)). Go, in contrast, has a
very solid commitment to backwards compatibility until the major version
number changes.

So my general take on Rust and Haskell, specifically, is "Wake me when it's
cooked."

~~~
quadrangle
Haskell can do fast web servers. See Warp

~~~
HelloNurse
I don't care about fast web servers if a language doesn't have a decent design
(rather than tolerable hacks and bolted-on libraries) for records, arrays,
hierarchical namespaces, mutable data structures, strings, exception handling,
compile-time dependencies, the standard library in general, system calls, etc.

~~~
innocentoldguy
Personally, I would say that immutable data structures and pure functional
programming ARE a decent design; especially in web programming.

------
teps
The author list features, shows you can't solve them easily with go and then
conclude that go is not good.

With similar argument, I could list every feature of xml, show that they are
not easily solvable with json and conclude that json is not good.

~~~
aikah
> that json is not good

Json became the defacto serialization format, but in my opinion, Json isn't
good for everything. Json and all its tools around it keeps trying to be like
XML.

~~~
fooster
Exactly the point surely? Just because json isn't good for everything doesn't
mean its not good. Just because you wish json had xslt support (for example),
doesn't mean its not good either.

------
tuyguntn
If there were GOOD language then all other languages will be dropped. Every
language has its own disadvantage, but it doesn't mean its not good, thats
just trade-off.

For me main selling point of golang is small lightweight threads with event
loop. You write sequential blocking code and you get concurrency built in.

~~~
quadrangle
That sort of total relativism is not a helpful perspective. There are
definitely better and worse designs in the world, and the reason people do not
drop the worse ones has to do with the network effects of adoption. Betamax
was superior to VHS but adoption rates and support by movie publishers made
VHS win.

~~~
quadrangle
Are people downvoting this because I didn't use a convincing enough example?
Or because they think this is part of the anti-Go sentiment here? Or because
they actually believe in total relativism? Sincerely curious. Maybe people
aren't relativists but actually believe that markets are magic and always make
the most deserving things win??

------
jkaptur
Using the author's standards, adding features to a language is always a good
idea.

> All well-written code is easy to read, and most poorly-written code is hard
> to read. Obviously Go can't change that.

I completely disagree. Languages with lots of features can make poorly-written
code vastly more difficult to read.

------
lohengramm
I like the article. It is well written and very informative. However, one
could just omit the word "Not" in the title, becoming "Why Go Is Good", and it
would still be a valid article.

In short, the author just points out features that Go could have but doesn't,
which is not a good argument for saying that Go is "unconditionally" bad. All
those missing features are missing on purpose, they are not bugs nor there is
some kind of inherent defect in the language.

To me, the only two things that really bother me in Go are: 1) sometimes, the
lack of generics, particularly when dealing with data structures and 2) the
lack of a proper and official dependency manager. (The go tool has so many
officially supported auxiliary tools, why not also a dep manager supporting
versions etc.?)

------
steven2012
I hate blog posts like this.

It sounds like the author wants to turn Go into Java or Haskell. If that's
what the author's preference is, then just use Java or Haskell. I don't even
use Go, but to me this post is simply just whining, but the author doesn't
appear to understand the fundamental reason of how or why Go was designed.

The creators of Go made _opinionated_ decisions on how the language would
behave. Generics weren't left out because of oversight or accident, that was a
conscious decision. Everything in his list was a conscious decision. Go is one
of the most opinionated languages out there, and it's definitely not flexible
to do whatever everyone wants. If you don't like it, then use another
language. It's pretty simple.

~~~
masklinn
> It sounds like the author wants to turn Go into Java

Go is already a Java. It's just that by and large it's an old Java, 1.0~1.1
style. Slightly better in some ways (local type inference), slightly worse in
others (more magical builtins).

> Generics weren't left out because of oversight or accident, that was a
> conscious decision.

So were they in Java 1.0. Or C# 1.0 for that matter. Though for the latter it
was because of time constraints, they were never under any illusion that they
_should_ do without.

------
tmaly
I was not sure about Go, but I tried it out, and I like the language. It was
easy to learn, has a good tool chain, it has a good standard library, and the
community produces code for things not available in the standard library. I
have traditionally used Perl for most things, but Go fills a nice spot for
small servers on the backend. I think if you need generics for your project,
C++ and Rust are waiting for you to pickup and start using. If you want
embedded programming, C is there for you to pick up. If you want fancy type
systems, Haskell is there for you to pick up. No one language can be
everything to everyone. Choose the tool with the features you need.

------
iand
Subtitle: "Go is not what I want it to be"

------
fideloper
Most of these arguments seem to be arguments between the pragmatism vs purity
camps.

I've switched between these camps before, and the lesson I've taken away is to
use each when needed. (Altho I personally err on the pragmatic).

~~~
wyager
I believe you are incorrectly conflating pragmatism with monotony.

I've found Haskell to be very pragmatic, once I learned how to apply it. I
haven't re-visited Rust in a while, but I expect to use it very pragmatically
once it matures and people start developing Rust tooling for embedded work.

------
brianolson
Another "Go isn't Haskell/Rust" rant. I agree Go lacks
macros/templates/generics and should fix at least one of those, but mostly
this is a bunch of whining wishing that Go was Haskell or Rust.

------
pmilot
I like this article and I agree with most of what was said there.

Against that type of point-by-point criticism, fans of a language will usually
use the argument: "but that language was not designed for that!". Then the
question becomes: What was that language designed for? My impression was that
Go was meant to be a slightly higher-level systems language with better
constructs for concurrent programming. With that in mind, it seems to me that
Rust is just a "better Go".

~~~
Veedrac
I can't really see a world in which Rust is a "better Go". Rust is one of the
more complex languages in existence, largely because it competes with C++ and
thus can't afford to lose many features nor do many things the easy way.

Go is one of the simplest languages in existence. It's on the other side of
the charts.

~~~
wyager
> Go is one of the simplest languages in existence.

By what metric?

I can think of a lot of simpler languages. Lua, C, Forth, all the theoretical
dead-simple combinator languages you don't want to use (Lambda Calculus, SKI
calculus, etc.), etc...

~~~
Veedrac
> Lua, C, Forth

Are all simple, yes. That C is on your list is kind'a the point - Go is
explicitly a spiritual derivative of C.

But go down on the TIOBE index[1] and tell me what _fraction_ of languages
there are as simple as Go. It's not a large fraction.

[1]:
[http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

------
karmakaze
> I like Go. I use it for a number of things (including this blog, at the time
> of writing). Go is useful. With that said, Go is not a good language. It's
> not bad; it's just not good.

It's all right there. Go has good uses. But it's not good for some things
including as an example for a 'good' (for some definition of good) typed
language.

Also Go has generics: array/slice, map, channel. You just can't create others.

------
polymathist
There is a small discrepancy in the article:

> Go supports the := assignment operator, which works like this ... All this
> does is look at the return type of bar(), and set the type of foo to that.

This is a misunderstanding of the := operator and how type inference works in
Go. If you look at the language spec
([https://golang.org/ref/spec#Short_variable_declarations](https://golang.org/ref/spec#Short_variable_declarations)),
you can see that the := operator is nothing more than a shorthand variable
declaration.

x := "foo"

is shorthand for (and functionally equivalent to)

var x = "foo"

Type inference is orthogonal to the := operator and is a little more powerful
than the author implies. For example, Go is able to infer the type of
literals, including inferring the type of a numeric literal based on the
presence of a decimal point or the symbol for the imaginary number, i (complex
and imaginary numbers have native support). It can also infer the type when
you assign a variable to an element in array, slice, or map or when you
receive from a channel. Of course it can also infer types for values inside of
a struct, map, slice, or array and for keys in maps. The only obvious
difference I see between type inference in Go and Rust or Haskell is that in
Go you must always define the return types for functions, but there may be
more differences I am unaware of. See this playground example for a demo of a
few different ways that types can be inferred in Go:
[http://play.golang.org/p/8ep340vLky](http://play.golang.org/p/8ep340vLky).

(edit: formatting)

------
poorman
The blogger has completely missed the entire purpose of Go. I suggest anyone
who actually wants info one way or the other to read the Preface in Alan
Donovan and Brian Kernighan's "The Go Programming Language". You will then
understand why Go is the way it is and why all the negative points (in his
mind) this blogger listed, are not in the language.

~~~
wyager
> read the Preface in Alan Donovan and Brian Kernighan's "The Go Programming
> Language"

I have read it :)

I think it's both misguided and misleading. It's misguided because they have
the wrong idea about simplicity, and it's misleading because they claim that
Go is "radically simple". Go isn't really that simple; it's just
inconveniently incapable.

~~~
AnimalMuppet
> It's misguided because they have the wrong idea about simplicity...

No, it's not _your_ idea of simplicity. It's not wrong, it's different. That's
all.

You're falling into the "my way is the right way" arrogance that so many here
are accusing the Go advocates of.

~~~
wyager
>No, it's not your idea of simplicity. It's not wrong, it's different.

What is your point? That words have no objective meaning and no one can ever
be wrong ever?

I'm operating under the assumption that most people have a definition of
simplicity that's similar to mine. Go is not simple under a _very broad_
definition of "not simple". I'm not saying using Go is the wrong way to do
things; I'm saying this classification is misleading.

~~~
AnimalMuppet
> I'm operating under the assumption that most people have a definition of
> simplicity that's similar to mine.

Perhaps you shouldn't assume that. But whether you're right or wrong in
assuming that most people have a definition of simplicity that's similar to
yours, it's another step to say that Donovan and Kernighan's definition is
_wrong_. It's that second step that I'm criticizing you for.

Plaugher has been very clear about what he means by "simplicity" in Go. (I
suspect the same is true of Donovan and Kernighan, though I haven't read their
intro.) So, yes, the word "simple" has a clearly defined meaning for them. It
also has a different, perhaps less clearly defined, meaning for you.

Again, it's fine for you to disagree. But to say that their definition is
_wrong_? That sounds both arrogant and childish. More to the point, it seems
unlikely that you are right that their definition is [objectively] wrong.

[Edit: Where did Go come from? It came from trying to solve the problems of
working on ten-million-line code bases for a decade or two. That experience
gave them definite ideas about what "simplicity" means. It's fair to say that
most people don't have that definition. But you don't have the right to say
their definition is wrong unless you've worked in that environment long enough
to know what the problems are.]

------
sesteel
High level programming languages exist, first, to help us instruct computers
on how to process data and second, to allow us to communicate with humans on
how we intended to have the computer process data. For the most part, Go works
well in both of these cases. I appreciate the fact that I can read other
people's code and understand what is going on.

------
poofyleek
These points are valid but miss the point of Go. To judge Go, as any language
or tool, one must program in it for a while -- say a year or two -- and build
substantial programs that serve specific needs. The outcome of such experience
is clear indication of a tool's usefulness. I started as a very skeptical user
of Go. Now I cannot live without it.

------
tomasien
This is the most HN headline of all time

~~~
harryh
"Why Go Is Not My Favorite Programming Language" would have been even better
given the historical nod.

------
Depado
Maybe we should stop fighting over languages and focus on the things you can
create with them ? I honestly see no point in creating blog posts about "Why
this language sucks". It's quite always a subjective point of view, and the
whole goal of this kind of article is generally to drag people away from a
language.

People are using Go. They create content with Go, they create amazing stuff,
sometimes they realize that Go isn't the best language to create this or that
and so they switch to something else. What's the point there ? If a language
doesn't fit your exact use cases, then it's a bad language ?

Stop the impossible standards of the perfect language. Real languages have
flaws !

------
skybrian
I think the answer for people who want this sort of thing is to write a Go++
that compiles to Go. If it's a good enough solution then it will convince the
community to move forward, at least on some features.

~~~
nanodano
Go is still young and I think it will expand over time. I think they wanted to
start with a simple language and grow it carefully. One of the biggest
complaints is generics and they compare it to Java but even Java didn't have
generics at first.

~~~
skybrian
And how do you think Java got generics? There were experimental offshoots of
Java (for example, Pizza and GJ) before Java 5. The authors went on to help
design the generics in Java 5.

I don't see a similar effort to improve Go, at least not yet.

------
amelius
The ugliest part of Go, imho, is that in some situations it may appear as if
nil != nil. See for example the confusion in [1], and for an explanation, [2]

[1] [http://stackoverflow.com/questions/21460787/nil-slice-
when-p...](http://stackoverflow.com/questions/21460787/nil-slice-when-passed-
as-interface-is-not-nil-why-golang)

[2]
[https://golang.org/doc/faq#nil_error](https://golang.org/doc/faq#nil_error)

~~~
tjholowaychuk
I'd have to agree! Some little quirks like this sort of make sense after
they're explained but they're certainly not intuitive. Assignability is
another that I find awkward, I had to dig around to find the reasoning behind
named/unnamed types being handled the way they are.

------
jwatte
Go is a perfectly fine incremental refinement on the Perl model.

What the Go cheerleaders lack is actual experience of most of the alternatives
over significant time.

I have code in production based on Go, and C++, and Haskell, and PHP, and
Erlang, and Python, and JavaScript, and probably others. Go doesn't really
stand out, at all. If I had to pick one, I'd pick C++. If I had to add
another, it would be Haskell, unless I needed front end which forces
JavaScript.

Go is probably ahead of PHP, though, so that's something.

------
Merovius
TIL that go is not good, because it's not rust. Also, yes, go has the ability
for isolated unsafe code. Namely importing the unsafe package and using that.

------
romanovcode
I tried Go, didn't really impressed me. I don't see any reason why now one
should choose Go over C#, for example.

------
bluepill
there we Go again.

why spend time writing about something you don't like? Is it a therapy for
programmers with strong opinions?

~~~
15155
> something you don't like?

Because you may be forced to use it at work.

------
talles
> Go has the null pointer (nil). I consider it a shame whenever a new
> language, tabula rasa, chooses to re-implement this unnecessary bug-inducing
> feature.

I agree that all points in the article are very debatable. But this one I'm
yet to see the counter-argument.

------
platz
> no runtime overhead from generic programming.

Not really the full truth, since the monomorphic version in haskell can
possibly be unboxed reducing a level of pointer indirection.

------
anotherevan
If I was of a more petulant nature, I'd be tempted to register the domain
doesgohavegenericsyet.com and just put up a web-site with a big "NO".

------
bribri
A language that someone could learn in a few days and can immediately start
being productive writing fast concurrent code is interesting. And it is good.

------
72deluxe
Very informative, thanks! Looks like I'll be sticking with C++11 onwards from
now on, despite its flaws and the ability to do dangerous stupid things. Even
better, it is backwards compatible so there is an abundance of usable existing
libraries for it. (On reflection, it can do dangerous stupid things but in
truth it would be entirely my fault for doing dangerous stupid things, so best
not blame the language for my stupidity).

A very informative article though, thanks!

------
aftabh
I might have taken the content of this article more seriously if it had been
titled something like "Why Go Is Not Good for Embedded System Programming"
since the original author of the article seems to have more experience in
embedded system's domain[1].

Also, the article say "Go is a regression from other modern programming
languages" and I find it amusing that a significant numbers of people here
taking the article and its claim seriously when it is coming from a student[1]
who just finished his 'Computer Programming' university course in Fall 2014[1]
(one of the reason, other reason is mentioned in the next paragraph). Don't
get me wrong here: I'm not saying that you can't say anything significant when
you're a student; what I mean here is that one needs to come up with more
detailed explanations and with many more examples which are valid for a wide
range of scenarios and use-cases when you make a general statement about a
programming language which has been created by some of the highly-respected
experts in the field of programming language. The list of problems mentioned
in the article are important but they're not very critical for the kind of the
system development that Go language has been designed/developed for[2].

Since Go language has been developed for system programming, the term 'system
programming' is not restricted to embedded system only (as few people have
already mentioned it in different threads here) which are mostly limited to
one component (or small number of related components working together). With
the advent of internet and IoT, we are forced to develop very large software
systems (read, software systems as infrastructures) in order to make next
generation of internet and IoT applications possible and usable (talking from
business perspective). Development of these new large scale systems bring
different kinds of theoretical and practical problems like complexity,
concurrency and inefficiencies in system development process (for example;
code compilation of large codebase and running regression test suits). And, Go
has been specifically build for this new kind of large scale system
softwares[2] (competing/working along with some other programming languages in
this area).

Here, I would read the initial set of high-level problems which forced Rob
Pike and his team to create a whole new language[2], instead of _only_
considering issues/problems which one face while developing a single machine
software/hardware program (as I've already said that they're important but
they're also not everything). Once I know the strength and weakness of a
programming language, I know when I should (or should not) use it, under what
circumstances it's the right tool and what advantages/dis-advantages I've to
trade off when I use it.

\---

[1]- [http://yager.io/resume.pdf](http://yager.io/resume.pdf)

[2]- [http://commandcenter.blogspot.de/2012/06/less-is-
exponential...](http://commandcenter.blogspot.de/2012/06/less-is-
exponentially-more.html)

------
DubiousPusher
I'm not switching to a language without a mechanism for type safe generic
programming any time soon. But I will say, the simplicity of Go probably makes
it much easier to keep the compiler fast and reliable.

------
pinn4242
Serious here--what is the color between black and white?

------
grabcocque
My essential issue with Go is how much it feels like cargo cult language
design. Compared to other emerging languages [Rust, Clojure, Elixir,
Julia...], it feels inconsistent, half-baked, uncertain what it's for or where
it's going.

~~~
cmrdporcupine
200% agree. I didn't feel consistency in what was included or excluded.

It's too bad because a language with its general tone really should replace
much of the use of Java and Python (and at Google, C++, which is still used in
places where many other companies would use Java)

------
crimsonalucard
Imagine a flawless gemstone with a permanent stain on one of the edges. This
is go, and this is why people complain endlessly.

The creators of go only look at the gemstone from a single angle. So they
never see the stain and they really don't care. When people complain to them,
they just tell the complainers that they're looking at the gemstone from the
wrong angle.

~~~
thegeekpirate
> The creators of go only look at the gemstone from a single angle. So they
> never see the stain and they really don't care. When people complain to
> them, they just tell the complainers that they're looking at the gemstone
> from the wrong angle.

This isn't true at all, and is incredibly naive. Here's the reasoning behind
not having generics, for example:

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

[https://golang.org/doc/faq#generics](https://golang.org/doc/faq#generics)

------
frik
Go is pretty good for various use cases. Before that, one coded web services
and server tools in C, C++, Java, etc. - nowadays Go is ideal for the task. It
has the advantages of Java (JIT, strings, higher level concepts, inbuilt
concurrency, etc), is fast and shares the simplicity of the C syntax.

------
insulanian
When one mentions Go, I imagine the crowd. When one mentions Haskel/OCaml/F#,
I imagine an artist.

~~~
oscargrouch
Whats the problem in enabling more people to program computers like Python, Go
and Javascript does?

And the most funny thing about this arrogant attitude for some languages, is
that the greatest popular tools, and the "killer apps" tend to occur in those
languages.. as a indication that there is actually pretty smart people using
the language contrary to common believe.

So is more likely that the "artist" might actually end using Go than Haskell

------
erjjones
Go is "trendy" and will fall right in line with Ruby on the trendy block.
They'll have block parties together and "Go" swing dancing. Wait, that was a
fad too and a pun.

~~~
innocentoldguy
Not in my mind. I'd invite Ruby to a party. Go is who I would go to for a
colonoscopy or prostate exam.

------
gendoikari
We'll see in the next few years... We'll see...

~~~
innocentoldguy
I don't think a language's popularity has anything to do with it being a good,
well-thought-out language. Just look at Javascript.

~~~
gendoikari
I didn't mean that. I meant that in the next years we'll see if some design
decisions were bad or wise.

~~~
innocentoldguy
I see. I apologize for reading your post incorrectly.

