
400 days of Go - selvan
http://www.philipotoole.com/400-days-of-go/
======
arihant
I love Go, 90% of my company's codebase is in Go. But I can't ignore the Kool-
Aid in this article.

I don't see why people have perception of IDE being a bad thing. In past 15
years or so, I have never been in a situation where I was on a system where
some IDE was not supported, and I wanted to use it.

They are everywhere, just like vim. That's like mocking the Gmail cause it
needs a browser, while praising mutt cause you can be lost in Jurassic World
with an Apple II which cannot run Chrome.

The build times of Go 1.5 are not that fast. That point is not _that_ valid. I
also don't see much point in have competition of build times among languages
that compile to binary. Rust, Go, C are all fast enough.

I'm sure he has good points below (I see testing as one), but he started out
bashing Java, after which I genuinely did not want to read the article. I'm
not a Java fan, but I find the language extremely non-assuming, very less
opinionated and quite useful. If Go one day has half a million repos of
libraries, given it's composability features, it will have names just as fugly
as some Java classes. Java's standard libraries are actually very clean.

~~~
mseebach
There's nothing wrong with an IDE _per se_ \-- but it's a smell when a
language is so verbose that it effectively requires a machine to help you
write it, which is definitely the case for Java.

It's just a smell, it's not disqualifying, because, as you correctly state,
rare are the times when you can't just run the IDE. But I think it's a
perfectly fair point that the language you can write effective in vi is -- all
other things being equal -- better than the language that requires an IDE.

~~~
yokohummer7
> it's a smell when a language is so verbose that it effectively requires a
> machine to help you write it

The funny thing is that this feature also explains what Go is. Go relies
heavily on the various tooling just to overcome the deficiencies of the
language. It's just that they didn't choose IDE as a primary target, but
instead various ad hoc tools.

For example, when I find the unused imports being a hard error inconvenient, a
typical suggestion from Gophers is "just use an editor plugin that
automatically handles that". This is exactly the same attitude that can be
found in the IDE lovers.

And that's why I don't like Go anymore. In the name of the simplicity of the
language, they concentrate on building more and more tools, rather than fixing
the language. I'm pretty sure if Go acquires generics someday, it will have
the form of code generation, which is proven to be awkward. (I heard "go
generate" already does a part of that?)

~~~
sagichmal
Those "various ad hoc tools" are literally the UNIX philosophy applied to
language design. It's cool if you don't like it, but call it what it is, and
realize you're really objecting to a whole ethos, not just a single instance
of it.

~~~
lobster_johnson
The example the parent picked — unused imports being an error — isn't an
instance of Unix philosophy at all.

Unused imports flagged as an error is great for production code, but
infuriating during developing, when you need to work with a lot of _tentative_
code, the most basic of which involves printing.

Having to add, remove, then re-add "fmt" or "log" just to keep the compiler
happy is not a Unix-philosophical issue around language design, it's just an
unnecessary strictness.

Go is "opinionated", but it tends to err on the side of impracticality, a kind
of distorted, prematurely-optimized YAGNI that disrupts developer efficiency
in the name of simplicity. "go get"'s obstinate simplicity is firmly in this
category.

Go gets a lot of stuff right, of course. And the tools — the "go" tool,
compiler toolchain, gofmt, debugger, godoc etc. — are clearly good Unix
citizens, of course.

~~~
kasey_junk
Not commenting on the bigger picture about philosophy. But I couldn't work in
go without:

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

~~~
StavrosK
> But I couldn't work in go without:
> [https://github.com/bradfitz/goimports](https://github.com/bradfitz/goimports)

I think this statement makes both points simultaneously.

------
ldite
Go get is an astonishing demonstration of failing to learn the lessons of the
past; it's bad enough watching Python, Ruby, Node, Java et. al. painfully re-
invent the wheel of dependency management, but at least they seem to have
gained the notion of versioning.

Go seems to have taken a look at the carnage of decades of dependency hell and
decided "if we make no effort to provide a system then people will be forced
to produce sane stable APIs".

I've picked the short straw of trying to reproducibly build and package Go
based projects for internal projects. The combination of go get and the Go
ecosystem's cultural lack of versioning and stability are giving me a deep
dislike of the language.

First you have to play git-bisect on the dependencies (after you've hunted
them down because of repo renames) in order to find the most recent one it
builds against (and who knows if that was the one written against!) Then you
have to futz around to add in either some custom or third party vendoring
script, and then you have to rinse and repeat for second order dependencies.

For example, take the author's own first linked project. Following the build
instructions:

    
    
        ~ $ mkdir ~/syslog-gollector
        ~ $ cd ~/syslog-gollector
        ~/syslog-gollector $ export GOPATH=$PWD
        ~/syslog-gollector $ go get github.com/otoolep/syslog-gollector
        package github.com/otoolep/syslog-gollector
        	imports code.google.com/p/log4go
        	imports github.com/otoolep/sarama
        	imports code.google.com/p/snappy-go/snappy: unable to detect version control system for code.google.com/ path
        ~/syslog-gollector $ go install github.com/otoolep/syslog-gollector
        src/github.com/otoolep/sarama/snappy.go:5:2: cannot find package "code.google.com/p/snappy-go/snappy" in any of:
        	/usr/lib/golang/src/code.google.com/p/snappy-go/snappy (from $GOROOT)
        	/home/ldite/syslog-gollector/src/code.google.com/p/snappy-go/snappy (from $GOPATH)
    

Well, I'm shocked.

~~~
hellbanner
I gave up Go from Google's tutorial level 1 when I had a compile error.

What language ecosystems do you feel have good dependency management?

~~~
koloron
Haskell has a pretty cool new dependency management tool called _stack_
([https://github.com/commercialhaskell/stack](https://github.com/commercialhaskell/stack)).

It's based on the curated package server
[https://stackage.org](https://stackage.org) which server sets of packages
that are tested for compatibility.

------
clessg
I've used Go for numerous web projects, and I dislike it progressively more as
time goes on. There are a lot of things that I really like about it, but I
feel as though its advocates have a bit of stockholm syndrome. If Go makes X
difficult or clumsy, then clearly X is a bad idea and you should Do It The Go
Way™. I hope that doesn't come across as too dismissive; it's just been my
experience.

I really like some of the decisions around Go, but I don't like Go _itself_ ,
as a language. For web apps, at least. I've been looking at [http://elixir-
lang.org/](http://elixir-lang.org/) and
[http://www.phoenixframework.org/](http://www.phoenixframework.org/) and I
really hope that they gain steam before Go does. I will continue to use Go for
command-line apps, which I think it is very well suited for.

~~~
tptacek
If you replace "X is bad" with "X is not the right way to solve the problem in
Go programs", you end up with a much more reasonable statement. Lots of good,
even great things don't make sense in every program. The notion that every
good thing should be available to every program seems more unreasonable to me
than the inverse notion.

~~~
kasey_junk
Absolutely, but there is certainly a very large strain of "father knows best"
in the golang language and community. Which can be _very_ off putting.

~~~
tptacek
It's probably the ~5 years of Ruby I did prior to Go that inoculates me from
that; I'd rather have "father knows best" than the opposite.

~~~
clessg
As somebody who's done a lot of Ruby, I can sympathize with that. But the
rationalization is typically very religious: it often turns out that every
decision made in the language is obviously the right decision. If you
disagree, then you're wrong, and you should just accept it and stop
questioning it. (This is not hyperbole. People actually say this.)

The Go community can be really problematic and condescending. Which is another
reason why Elixir appeals to me: you get treated like a person.

~~~
AnimalMuppet
Well, if I'm in a position to re-write the language, then how I think they
should do it matters. If I'm in a position to select which language gets used
on a project, then which language does it the way I prefer matters.

But if I'm in the middle of a project in language X, trying to do Y, then
"shut up and do it the way we do Y in X" really might be the correct answer.
Work with the tool, not against it...

------
hacker_9
Stopped reading after author considered IDE's to be a code smell. I mean
honestly - they are there to make life easier and speed up writing code. 99%
of the time I only have to type 2 chars + [TAB] and autocomplete completes the
word for me. Now I have a descriptive word that I can read _and write_ in less
than a second. How is this bad? Coupled with contextual member browsing on
typing a '.', and contextual rename refactoring, and contextual
errors/warnings underlining...

The fact that Go doesn't have an official IDE is actually what stops me from
going near the language.

~~~
CmonDev
He is just in love with the shiny toy: Go is good, Go doesnt have and IDE =>
IDE is bad.

I have seen a guy on HN saying that debuggers are bad and logging debug
messages is superior :). Future is here, but it is sooo unevenly distributed.

~~~
sagichmal
For certain classes of software development, specifically distributed systems,
debuggers _are_ bad (or, at least, effectively useless) and logging debug
messages _is_ superior (because it's the best way to rebuild a chain of
causality).

It's all about context. Go is a great tool for certain things. Understand the
boundaries of those domains, rather than castigating the tool.

------
oweiler
_I once tried to write Java code using vim, and the runaway proliferation of
source files, of AbstractSingletonProxyFactoryBeans, quickly made an IDE
required_

I can't stand reading this crap anymore. I'm using Spring for at least 3 years
and never had to deal with such class names.

Though I agree that writing Java in vim is quite painful.

~~~
scalesolved
Agreed, with Lombok/Spring/Spring Data and zero xml config these days Java
project verbosity has dropped crazily low. It's just nice to hate on it, I'd
still always use an IDE because I can't remember the exact APIs for
everything! :)

------
rumcajz
> Now I may underestimate the work GC is doing for me — quite possibly — but
> if I had to track the memory myself, and still write Go code, I don’t think
> I’d really mind.

I've written a go-style concurrency library for C for people who share this
sentiment: [http://libmill.org](http://libmill.org)

------
pif
> So if there is one word to summarize Go, it’s productive. > ... >
> boilerplate ... This can make code maintenance more difficult.

These two sentences can't be both right. Most of the work in software
development is maintenance. A tool that lets you ship bad code faster is going
in the wrong direction.

~~~
yxhuvud
They can both be true at the same time, because productivity is not a boolean,
it is a float.

~~~
darkr
bool and float32, surely.

If you'd have been using an IDE...

------
joesmo
Interesting, but what I'd really like to know about and the author didn't
mention is the debugging situation. The debugging tools and styles available
on a platform are truly a make it or break it deal for me. It's a huge factor
in productivity, sometimes the main one. Maybe someone with experience in this
area can delve into this topic a bit further? I think the availability of
third party libraries in various areas is another huge factor that the author
missed.

~~~
ominous_prime
Not that there's anything wrong with using a debugger as a tool, but I find it
hard to understand why it's such a stringent requirement for some. I've never
really had the need for one outside of a few instances over many languages,
and I know many others that feel the same, which covers a much greater range
of languages and styles of programming. Even so, I'm eagerly awaiting a good
Go debugger when one arrives.

There are some being worked on, like delve
([https://github.com/derekparker/delve/](https://github.com/derekparker/delve/)),
which might be the most ambitious, but it's only recently becoming usable. The
problem is partly due to my first statement, there's not a huge demand for
these in the language ecosystem, so development has been slow.

~~~
joesmo
After using a proper debugger, I can almost say I'll never go back to a
language without one. It's such a useful tool, I use it a lot even when
writing code. I think if you asked a functional programmer to give up their
REPL, they might not be so happy. The debugger is essentially the REPL of
imperial languages (because a REPL by itself is not enough for imperial
languages since all the state has to be set up). Also, it's extremely useful
when learning a new codebase as well as actually debugging bugs. I also think
it's necessary to have one for a language to gain mainstream support.

~~~
Shorel
By "imperial languages" do you mean "imperative languages", right?

~~~
joesmo
Oops. Yes, indeed.

------
shurcooL
If you don't like GOPATH workspace and use a separate GOPATH for each project,
you should just use gb [1] which was designed and built with that use case as
a goal.

Build tool and language are somewhat separate concepts.

[1] [https://getgb.io](https://getgb.io)

~~~
lobster_johnson
gb is promising, but doesn't feel like the complete solution quite yet.

The author only hesitantly added support for managing dependencies, which is
done through a separate "plugin", gb-vendor. It maintains an internal manifest
file which only the gb-vendor tool is supposed to manage. It's not like NPM or
Ruby's Bundler where you the manifest file (package.json, Gemfile) is what you
edit to produce the vendor tree. Support for branches and tags seems to
missing, as does any notion of versioning, so of course semver is not on the
table.

I understand the Unix philosophy of keeping dependency management and building
separate tools, but I suspect that what most Go developers want is a fully
integrated solution. I know I do.

------
bsaul
I think everybody agrees on the quality of go standard lib. Has anyone tried
to reimplement it with a different language ? I'm thinking maybe D, Rust,
nimrod, java, scala, or even swift ( in anticipation to its open sourcing in a
few months) could make good candidates.

------
atilaneves
Several of the "why Go is good" points aren't unique to Go.

------
ciupicri
> Key data structures built-in

Yet a decimal data type is missing.

~~~
AnimalMuppet
Why do you consider that a key data structure? (It may be key for your
application, but should it really be key for the language as a whole?)

~~~
Shorel
It's not the definitive default number only because performance reasons and
because of C influence in language design.

If most languages had Decimals, I am sure only C/C++/Java diehards would use
ints/floats instead. In fact most modern scripted languages should have them.

Regarding go, as it is a relatively new language, and having to interact with
databases, with Decimal being a fundamental SQL type, yes, it should have
Decimal.

~~~
kazinator
Floats are not for C/C++/Java diehards but for rather science, engineering,
signal processing, financial modeling, computer graphics ...

------
al2o3cr
"By building both in, it has resulted in a standard and systematic way for Go
programmers to deal with these data structures"

Also, nothing says "use the standard way" like making the built-ins the only
thing that's generic...

