
Four days of Go - wtbob
http://www.evanmiller.org/four-days-of-go.html
======
jgrahamc
_In other words, Go represents a kind of Machiavellian power play,
orchestrated by slow-and-careful programmers who are tired of suffering for
the sins of fast-and-loose programmers. The Go documentation refers quite
often to intolerable 45-minute build times suffered by the original designers,
and I can’t help but imagine them sitting around and seething about all those
unused imports from those “other” programmers, that is, the “bad”
programmers._

I think this is why some people dislike Go. The Go authors have made a
decision about the language and are sticking to it. I get the impression that
they are doing this because they believe they are 'right'. That makes some
people uncomfortable because we programmers like to discuss everything, and
argue, and it's hard to come up against people who have what is close to
'faith' in their own beliefs.

~~~
jfaucett
Personally, I think people dislike Go because they try using it for tasks
where it makes their life miserable. Mainly for web programming. (unless of
course you're a masochist and enjoy not having a repl and want static typing
and a compilation step when recursively parsing unknown json data structures).

In my experience, Go is a tool thats really good for a certain set of
programming tasks and like all other languages really bad or annoyingly
painful for others.

For me, Go is my number one tool for creating command line apps now. I get
immediate cross-platform cli tools with zero headache. Its also a really nice
fit for lower level networking/distributed applications where you are working
with byte protocols (things like mozillas heka, or docker, proxy servers, chat
clients, etc), the networking server-side stuff where you would probably have
used C++/Java.

My recommendation would be, if you work a lot on this kind of software
seriously start using Go, you will love it and think everyone is crazy for
hating on Go.

The problem is I think lots of people are trying to use Go for stuff it is not
designed for and where, compared to the alternatives, it is a rather bad fit.
For instance Go is zero fun for: Compiler Programming (Haskell/C++ have way
better tooling), Games (libs are one thing but Go cannot compete with C++ perf
here), Desktop GUI apps (Just use QT), Mobile Apps, and Web Programming (take
your pick of python,ruby,js,clojure,php - your life will be much easier),
Hardware/Low Level Systems programming (Obviously you can't use a GCed lang
here).

I haven't found another area where I really like programming in Go besides CLI
and networking I mentioned above. It could have another sweet spot I've
missed...

~~~
smt88
> _unless of course you 're a masochist and ... want static typing_

Some people say to prototype in a dynamically-typed language and then switch
to a static language later. Dynamic typing _might_ save keystrokes, but
typecasting and type-checking do require lots of typing, and who cares that
much about a few hundred extra keystrokes anyway?

Some people say to create whole, large apps in dynamically-typed languages,
but those people clearly haven't tried modifying or debugging code bases in
those languages that weren't created with utmost discipline and 100% test
coverage.

So with 10 years of web programming experience, I'd emphatically argue that
masochism is _not_ using static typing.

I have warm, happy dreams of a future where there's a great alternative to the
dynamic/weak web languages of today. There are already some great entrants,
but nothing has reached the massive popularity of existing languages yet.

(Edited for clarity)

~~~
stock_toaster
I think you left off the key part of his point, namely "when recursively
parsing unknown json data structures".

json parsing in Go uses reflection, which not only means it is slow, but if
your input is not consistent (like say.. a log file with 20 different possible
formats), it can be quite painful and very verbose.

~~~
jstarks
Do you have any resources demonstrating that JSON parsing in Go is slow?

~~~
stock_toaster
Here are a few google results:

* [http://erickt.github.io/blog/2014/11/03/performance/](http://erickt.github.io/blog/2014/11/03/performance/) and [http://erickt.github.io/blog/2014/11/11/benchmarks/](http://erickt.github.io/blog/2014/11/11/benchmarks/)

* [https://github.com/ugorji/go-codec-bench](https://github.com/ugorji/go-codec-bench)

* [https://github.com/golang/go/issues/5683](https://github.com/golang/go/issues/5683)

In my own testing it was faster (even with ffjson) to pre-clean my data in
cpython or pypy, and then emit some intermediary format (like capnproto) for
the go code to consume. I was parsing huge files full of lots of non-uniform
json with many formats.

For most use cases though, the fact that json is "slow" is probably not a huge
factor, as network IO or something else is likely the gating factor. For those
uncommon cases though, I wish the native json lib in Go was faster.

------
nnx
> Go basically forces you to have clean code all along, > which is a bit like
> forcing a scientist to wipe down the > workbench and rinse all the beakers
> between every experiment, >or forcing a writer to run the spell checker
> after every cigarette.

As usage of gofmt is idiomatic Go, simply using the superset goimports handles
all of this for you.

Sure, any language has tools to reformat code for you in some magic ways - but
what makes Go special is that it takes this kind of tooling seriously enough
by making it standard right out-of-the-box and right when initiating new users
to the language (notice the [Format] button on the _first_ slide of the
official Go tutorial
[http://tour.golang.org/welcome/1](http://tour.golang.org/welcome/1) ).

[https://github.com/bradfitz/goimports](https://github.com/bradfitz/goimports)

[http://michaelwhatcott.com/gosublime-
goimports/](http://michaelwhatcott.com/gosublime-goimports/)

Nevertheless, this new article from Evan is a marvel, a must-read, as usual.

~~~
swah
go fmt could be a tool that transformed "sloppy Go" (unused imports, variable
redeclarations...) into formal Go before compiling...

------
hahainternet
Wow. For once a fantastic article on Go which is clearly balanced and educated
by experience.

This is the sort of thing we should see more of on HN IMO.

~~~
nodivbyzero
+1. Agreed. I'm tired to read about startups/success stories/failures.

~~~
ChikkaChiChi
Your sarcasm is noted. I believe hahainternet was referring to articles that
either gloss over the bad parts of a thing, or make specious claims to
reinforce their ideas.

~~~
ajkjk
Not sure that was sarcastic.

------
donlzx
IMO, there are two different opposite directions in programming languages and
tools approaches,

1) The artistic approach which is very flexible and requires creative thinking
and deep understanding of the essence of computing. However, you can easily
shoot yourself with it. Languages of this type are for code guru, knights and
hackers.

2) The engineering approach which has rigid rules for efficiency and social
cooperation. It is less error-prone but tend to suppress diversity and
discovery. Golang belongs to this category. To me, the core Go authors are
more of engineers than artists :)

I use Go for work and simple command-line tools for myself. It is also great
for cooperation in well defined scenarios, e.g., Web back-end service. When it
comes to creative works, I'd rather avoid it.

~~~
wiremine
> To me, the core Go authors are more of engineers than artists

I thought the same thing. They are like the anti-Larry Wall.

~~~
nulltype
I guess that makes Go the inverse of Perl. I assume if a Perl programmer
shakes hands with a Go programmer, they cancel each other out.

~~~
vram22
No, the Go programmer will win. Strong(ly) type(d), you see :)
#SorryCouldntResist

Note: Said without any bias towards either Go or Perl.

Also, I'm not a language lawyer, and this was a joke, so I'm not replying to
any comments about Go not being "purely" or "strictly" strongly typed or
whatever.

~~~
vram22
Also, speaking of Perl, check out this (old) interview with Larry Wall:

[http://jugad2.blogspot.in/2015/04/interview-linux-journal-
wi...](http://jugad2.blogspot.in/2015/04/interview-linux-journal-with-larry-
wall.html)

------
mrcwinn
Go is not a perfect language, but I've been hard-pressed to find one and so
I've stopped looking. Here's what I like about Go.

Go is crazy boring. You type things. You hit return. You type the next thing.
Error not nil? Type more.

There's something very sequential, linear, methodical about it all. I suppose
in part it's gofmt. It may also be a byproduct of any strongly typed language,
but unlike many of those languages, Go feels simple and reasonable.

I actually think this is how programming serious applications should be. A
little boring. Nothing too fancy or cute. No refactors to fit some new great
abstraction pattern.

Not to wax nostalgic — in fact, I can't, because I wasn't even born — it
reminds me of paper tape in old computers. The card gets punched, it feeds in,
and the computer considers and executes your instructions. We're still doing
that, really. Programming should be simpler. Sometimes I think we go out of
our way to make it more complicated because we are experienced and bored. :)

------
coldtea
> _Reading Go’s mailing list and documentation, I get a similar sense of
> refusal-to-engage — the authors are communicative, to be sure, but in a
> didactic way. They seem tired of hearing people’s ideas, as if they’ve
> already thought of everything, and the relative success of Go at Google and
> elsewhere has only led them to turn the volume knob down. Which is a shame,
> because they’ll probably miss out on some good ideas_

This captures my sentiments and experiences with the language perfectly.

------
zimbatm
That was quite fun to read.

The point about Go being too pedantic and thus hindering exploration is
something I've felt too. Some of that pain was mitigated by the Sublime Text
Go plugin that has shortcuts to add/remove imports.

~~~
M8
Also he is spot on about the mascot.

~~~
nutate
I <3 the gopher:
[https://blog.golang.org/gopher](https://blog.golang.org/gopher)

------
cpfohl
What a fantastic writer. Hilarious technical articles are rare.

~~~
scott_karana
Agreed! I've not chuckled this much since reading Steve Yegge articles.

------
dilap
Fantastic article.

Two tips about the pain points regarding unused imports and variables:

The program goimports is an extended version of gofmt that will automatically
add and remove imports. Bind it to a keystroke of your editor of choice, and
the imports situation becomes painless.

For unused variables, you can do "_ = someVar" to stop it from being flagged
as unused. Still a bit of a pain, but much easier than commenting and
uncommenting things all the time.

------
zellyn
Great article. However, I would not assume that us (good programmers) vs them
(bad ones) is how the go folks see the world. If a couple decades of
programming have taught me anything, it's that "them" is usually "me" or "past
me" or "500 of us".

~~~
nulltype
A good point. I've seen people say that the Go designers are designing a
language for "bad programmers", but maybe they're just designing for humans.
Maybe code readability is more important than conciseness.

------
alanctgardner3
Two things stick out:

Catching unused variables is pretty essential, it's easy to shoot yourself in
the foot by redeclaring a variable with := inside a block.

>> which means you have to need separate storage for the actual RaceCar and
GetawayCar values, either on the stack with a temporary variable or on the
heap with calls to new

Maybe I miss his point here, but in Go it's totally valid to just create a new
*GetawayCar with &GetawayCar{} in any scope. You can return that pointer from
your current method. It's not necessary to explicitly put your GetawayCar on
the heap with new(), Go will decide for you with escape analysis.

------
rogpeppe1
From the article:

    
    
        In order to do evil things like convert raw bytes to floats,
        I chose to use the “unsafe” package
    

FWIW you don't need unsafe to do that. encoding/binary +
[http://golang.org/pkg/math/#Float64frombits](http://golang.org/pkg/math/#Float64frombits)
will do the job just fine.

------
dysoco
I must said, I've never heard of this guy, I think I have a new favorite
blogger now.

~~~
deathtrader666
He's the one behind ChicagoBoss - an MVC web framework in Erlang.

~~~
dysoco
Ah yeah, I'm not really into the Erlang world but I've heard of ChicagoBoss.

------
vowelless
> Go is productive enough that I’ve been enjoying implementing things from
> scratch like collapsible widgets and navigating a viewport. In order to do
> evil things like convert raw bytes to floats, I chose to use the “unsafe”
> package, which made me feel manly, powerful, and highly supportive of
> private gun ownership.

This was really funny!

------
anonfunction
_By the way, if anyone who works on the Go math library is reading this, there
are a few important functions missing._

I thought the same, so I built a stats library[1] of my own. It also only
works on float64's at the moment.

1\.
[https://github.com/montanaflynn/stats](https://github.com/montanaflynn/stats)

------
lugg
_My workflow at present is to print out the hex representation of a binary
file onto physical sheets of paper, and then mark them up with a ball-point
pen that I received last year at a conference about technology._

I love writing like this, where you got that pen doesn't matter one bit, yet
it turns the drab of a tech blog into an enjoyable story to read.

------
garfij
Ever since I started immediately creating at least one "test" file in my Go
projects, I have found that both the unused variable/imports problem, as well
as the "freedom to explore" issue have been eliminated for me.

Sure, they will still bite me in that individual test file if the situation
arises. It keeps the problem out of the "real" code, however so I don't get it
when building. In this way I get to maintain a creative space to test out
various apis and do my "print to console" testing, while also keeping my
primary code base Go-Clean™.

------
MindTwister
I find that every issue I had with unused imports disappeared when I started
using goimports:
[http://godoc.org/golang.org/x/tools/cmd/goimports](http://godoc.org/golang.org/x/tools/cmd/goimports)

~~~
rakoo
There are unused imports, solved easily with goimports, and then there are
unused _variables_ , which AFAIK are not solved by any tool. I dig what the
author says regarding "explorability" hindered by all those errors popping up.

It's also funny to see errors solved automagically by tools instead of
manually by the developer; there used to be a time where IDEs where
voluntarily avoided because they did too many magic things to your code and to
your project, and true hackers should be able to work with only a text editor
and the compiler. I fear go may be headed back to IDE-land if it starts
relying too much on tools (we have goimports today, the go generate command is
to be used for code mangling before compiling ...)

~~~
wtbob
> I fear go may be headed back to IDE-land if it starts relying too much on
> tools (we have goimports today, the go generate command is to be used for
> code mangling before compiling ...)

I think that it's kinda the opposite: rather than one monolithic IDE, it's
lots of little pieces working together. Pretty much what one would expect from
the guys who brought us Plan 9 and Go…

------
polymathist
I am worried that there might be a dangerous trend in conversations about go
on HN recently. There seems to be a tendency toward ad hominem comments
against the go authors.

The article itself is a great read. I love hearing interesting and honest
commentary about the language. But I wonder if comments like "for reasons that
appear to be political, does not have integer Min and integer Max functions"
are appropriate. Later the author mentions "I get a similar sense of refusal-
to-engage — the authors are communicative, to be sure, but in a didactic way."
If the go community (or the programming community at large) truly has the
sense that the go authors are unwilling to engage with the users of the
language, then that's a big problem. However, are these sort of off the cuff
comments the right way to start a discussion about it? At the very least, I
wish that the author would provide specific evidence for these claims. I'm
sure that there is some justification for them, but what the author is telling
us is his inference, and I would appreciate an opportunity to read the source
material and decide for myself. FWIW I have been programming in go for 2.5
years and made a few trips to the go-nuts mailing list. I don't share the
author's impression, but I also haven't read every thread on the mailing list.

That's far from the worst of it, of course. I have read comments calling the
go authors arrogant, ignorant, or conceited. If you insist on criticizing the
go authors, I would hope that you could at least keep it professional and
provide a link to some comment/literature to back up your criticism.

I welcome criticism of go, or of any topic for that matter. I just want to
avoid unfair characterization and irrelevant ad hominem comments. Am I being
too defensive or do other people share this concern?

~~~
rdtsc
> However, are these sort of off the cuff comments the right way to start a
> discussion about it?

Well it is a persons' opinion. There are some facts, some humor, some personal
opinions. I am not sure the author planned on being on the front page of HN. I
don't think he submitted his own article. It is up to the readers to put
things in the appropriate "bins" so to speak -- "This is good advice", "I
don't like this part", "This is just a personal attack" and so on. Sometimes
the same article can contain a variety of things.

------
anindyabd
"Throw caution to the garbage collector" \-- my new favorite phrase.

------
nicpottier
Hats off to the writing style, both informative and a good read.

------
TheDom
_California New Wave of systems programming languages_

Love it!

~~~
cmollis
Jersey-style, scorched-earth C..

~~~
rootbear
This essay was full of some great turns of phrase. I'll keep reading his blog.

------
kristianp
_From what I can gather on the mailing list threads, the language designers
are against polymorphism, as well as adding letters to function names, so
unlike the standard C library which operates on float, double, and long
double, as well as int and long where appropriate (e.g. absolute value), the
Go standard math library operates only on float64._

This is criticism of go I haven't heard before.

------
chrisduesing
Educational and entertaining as always Evan, I would love to see a similar
writeup on Elixir. Maybe a Chicago Boss port is in order ;)

~~~
timClicks
Evan actually spent a lot of time enabling Elixir support in CB when he was
actively involved with the project.

------
AnonJ
This author is quite exaggerating a bit. It seems like he himself is
constantly preoccupied with politics. Fine. But this doesn't mean other people
who he see with his eyes are necessarily thinking in the same pattern.
"Machiavellian" is such a heavy word. Go started out with a purpose, a purpose
which makes a lot of sense. It's not all about "make a new language and shove
the new rules onto everyone by coupling it with Very Fast Build Times, a kind
of veto-proof Defense Spending Bill in the Congress of computer programming."
Such a design has a lot of practical value.

------
Scramblejams
I used Go at work to write some utilities which extracted and manipulated
values from large text files. It compiled fast and ran fast (at least,
compared to the Python it was replacing).

However, I learned that Go is a language conceived for Programming in the
Large, and I found out (once again, thanks Java) that I don't like languages
for Programming in the Large.

But if I liked that sort of thing it'd probably be one of my first choices.

------
0xdeadbeefbabe
I wonder what he'll say in 8 days. I'm of the opinion that you can still make
a mess with go. Also, the gopher doesn't look that careful.

------
coldgrnd
is the code of "Hecate: The Hex Editor From Hell" available to look at?

~~~
hpux
The same question here.

------
karlgrz
That was great!

------
stefantalpalaru
> It’s also worth mentioning that you can get Go-style M:N concurrency model
> in C by using Apple’s libdispatch.

Not so fast. That library is only available for OS X and FreeBSD.

~~~
threeseed
There are ports:

Linux:
[https://github.com/nickhutchinson/libdispatch](https://github.com/nickhutchinson/libdispatch)

Windows:
[https://github.com/DrPizza/libdispatch](https://github.com/DrPizza/libdispatch)

~~~
stefantalpalaru
The Linux port seems to be using OS threads from Pthreads instead of
coroutines for the concurrent queue.

------
jlebrech
no ternary is a smart move tho. makes code more readable for all skill levels.

~~~
deckiedan
It's a balance between readability meaning 'short, and concise' and
readability meaning 'very clear, even if that requires being overly verbose'.

    
    
        return (data.name !== '' ?: 'New Data')
    

or Python style:

    
    
        return (data.name if data.name else 'New Data')
    

vs:

    
    
        if (data.name != '') {
            return data.name
        } else {
            return 'New Data'
        }
    

The former being much more concise, so that you can display (and grok,
perhaps) a single function in 3 or 4 lines, vs the Go style, which can result
in extremely long functions (long because they do a few things, and require
error checks before and after each one, and so on, rather than being long for
actually doing a lot).

The single line version implies at the beginning that all the line does is
return. The longer version requires you to read the whole paragraph to figure
out what it does.

~~~
sagichmal

        > if (data.name != "") {
        >     return data.name
        > } else {
        >     return "New Data"
        > }
    

Not exactly...

    
    
        if data.name != "" {
            return data.name
        }
        return "New Data"
    

And consider the likely context...

    
    
        func name(ref int64) string {
            data, ok := get(ref)
            if !ok {
                return "No Data"
            }
            if !data.valid {
                return "Invalid Data"
            }
            if data.name == "" {
                return "New Data"
            }
            return data.name
        }
    

Straightforward and unambiguous.

~~~
vorg
Doesn't compile though. You'll need lots of extra lines just to see an output,
which is really much of what the posted article was talking about with its
wandering-eyed gopher tale...

    
    
        package main
        import "fmt"
        func main(){
          fmt.Println(name(28))
        }
        type T struct{name string; valid bool}
        func get(ref int64) (T, bool) {
          return T{"abc", true}, false
        }
        func name(ref int64) string {
          switch data, ok := get(ref); true {
          case !ok:
            return "No Data"
          case !data.valid:
            return "Invalid Data"
          case data.name == "":
            return "New Data"
          default:
            return data.name
          }
        }

------
jasonlotito
> If I had to guess, I’d say the Go gopher suffers from a mild form of autism.

> I get the same feeling about the Go language. It feels like it is designed
> by an obsessive personality — obsessed with build times in particular, but
> also having an obsession with detail, someone who rarely makes mistakes when
> writing code, who generally will not run code until it appears to be
> complete and correct.

WTF? Not only is it insulting, it's ignorant. Considering some of the other
comments here regarding how "excellent" this article is, it clearly doesn't
concern many when casual insults are allowed.

No no, let's applaud someone for making casual, racist-like remarks without
even questioning it. If this is considered quality, we should be ashamed.

~~~
teach
As a high school teacher, I work with kids on the autism spectrum all the
time, and I don't find his comments offensive. They seem relatively accurate,
too.

~~~
jasonlotito
> As a high school teacher

As a father of two autistic children, I do.

> and I don't find his comments offensive.

He's equating look to a disorder. It's like saying "Black man dressed 'street
clothes' must be dangerous."

~~~
teach
I think he's saying "overly concerned with detail, marked lack of eye contact;
probably on the autism spectrum." These are literally two of the diagnostic
criteria for 299.00 Autism Spectrum Disorder.

It seems like you're reading a negative connotation into the "autistic" label
that isn't present in the article. Calling the gopher "unsettling" is the
biggest insult I can find in what he wrote.

------
rvalue
I still find it shocking how people can continue to write in Go which still
does not have an official debugger!

