
The March Towards Go - zef_hemel
http://zef.me/6191/the-march-towards-go
======
skrebbel
Zef writes this as if it's completely amazing that people are leaving Node for
Go. Node is based on JavaScript. There are arguably more things wrong with
JavaScript than with any other popular programming language, as evidenced by
book titles like "JavaScript, the good parts". This is common knowledge; we're
all trying to do good work _despite_ JavaScript, seldom because of it. So
Node: it's fast, we can share code with the browser, but it's a bitch to use.
We knew that when we signed up.

Conversely, Python is a great language but it's not as easy to make it go
fast. It's slow, but it's great to use. We also knew _that_ when we signed up.

It's great that Go is getting more mainstream adoption! Deservedly so. But
it's probably still easier to be super-productive developing a CRUD app in
Ruby or Python. And it's still easier to share code between backends and web
frontends with Node. If you don't need either of that, and you do need
performance, then, yes, maybe you shouldn't pick Python or Node.

I agree that Go is a great option to consider, but Zef is framing it a little
as a silver bullet, and well, of course it isn't.

~~~
facepalm
There are minor details wrong with JavaScript. Normally you don't encounter
them in daily use.

Apart from that JavaScript is brilliant. Few other languages can match it's
simplicity.

Python falls through because it doesn't have real lambda.

~~~
adamlett
> There are minor details wrong with JavaScript. Normally you don't encounter
> them in daily use.

If you really believe that, I can only assume that you either don't have very
much experience with Javascript and haven't yet been burned (or haven't yet
discovered that you've already been burned), _or_ that you don't have any
experience outside of Javascript and therefore are not aware that languages
exist that have all the niceness of Javascript but almost none of the bad
stuff. I say this as someone who is primarily a Javascript developer
professionally.

Yes, there are languages that are worse than Javascript to work in (I'm
looking at you Java and PHP), but there are many that are much better. It's
worth noting that everything that is good about Javascript already existed in
other languages before Javascript got invented. In fact Brendan Eich has
stated that his intention was to create Scheme for the browser. If only he had
just used Scheme as it existed, things would have been so much better!

~~~
dccoolgai
I've been working with JS professionally for the last 3 years...priorto that,
spent many years with C++/SQL/etc...the statements that people get "burned" by
JS (pesumably because of the weird coercion or floating-point comparisons?)
I've never understood...maybe I just write my code in a weird way that
insulates me from those things...I've never experienced more than a "minor
surprise" in dev - certainly never been "burned".

~~~
adamlett
> maybe I just write my code in a weird way that insulates me from those
> things

Maybe you do. I certainly strive to. But don't you sometimes have to work with
other people's code too? I recently inherited a 10 years old codebase written
by people who had not heard of implied global and didn't use the var keyword.

In my previous job I had to educate several frontend developers about the
dangers of using parseInt without a radix parameter. The ones that already
knew did so because… you've guessed it: They had previously gotten burned.

I worked on a project in which the backend had a rest API that served json
data. Among the data were some rather long integer IDs. But since javascript
doesn't have integers but only floats (of all things), the IDs got rounded off
in weird ways. Not very useful as IDs after that! If all everyone ever used
was javascript, this would perhaps not have surprised anyone, and it would be
known by all that you shouldn't use a Number as an ID, but always only
Strings. The problem is that most back-end developers are not Javascript
experts and in their world it is only natural that you should be able to use a
number as an ID (as it should be IMO).

As time goes by and you get experienced, you begin to learn all of these
little 'quirks' of the language, and maybe you start to adopt a defensive
style of programming that insulates you from the worst of them. And if you've
never experienced anything else, it's easy to tell yourself that this is just
the way things are, and that it's probably the same for everyone. But I'm here
to tell you, that this is not the case! Sure, other (better) languages have
surprising behaviours too, but they are mostly good surprises that empower
instead of restrict.

~~~
dccoolgai
> But don't you sometimes have to work with other people's code too?

Yes, I suppose I have gotten "burned" by other people's JS quite a bit...but
not any more than I've been burned by other people's bad SQL or C++ or C#, to
be honest.

> Sure, other (better) languages have surprising behaviours too, but they are
> mostly good surprises that empower instead of restrict.

I am assuming that by "better" languages you are meaning type-safe ones... I
know this is not a popular opinion, but I honestly just prefer dynamic typing.
When I code, there is only room for one whiny child in the equation: me. Not
the language I code in. I would rather not have my language throw a temper-
tantrum and break down because I gave it something a millimeter different than
what it was expecting. If the object is supposed to have "thing" and it has
"thing" then shut your mouth and use it, language. Where JS gets weird is that
it tends to put "thing" there in some cases where you didn't expect it, but
honsetly after learning the few cases where it does that, I've never had a
huge problem with it - I think, like everyone, I bumped into some mild
surprises (ya the radix thing with parseInt and [] == false and soforth), but
they were never more than just mild surprises in development. I know it drives
people insane - and some people will swear that there is no way to build large
systems with it. I suspect those people are the same ones who asked the
teacher for extra homework for the whole class when they were kids. That was
just never me, and I would just respectfully disagree. To me JS is just a ton
of fun and there are too many people making too many awesome things with it to
ignore. Apparently TJ got tired of it - maybe I will one day, too.

Until then, I just wish people would recognize that the reason JS "won" the
language wars of the mid-late aughts was specifically _because_ of the "get-
out-of-the-way-and-let-coders-code" dynamic built into it - IMHO the modern
web could not have been built with anything else. If you have any recos for
"better" languages that share that dynamic, I would be very interested in
hearing them.

------
Udo
This sums up the problem:

 _> Not looking at Go yet? It may be a good time to do so now — everybody else
is._

That's going to be a large albatross around Go's neck, as it has been around
node.js', and Rails before that. Large amounts of developers flocking to a new
thing because "this is the thing to use now and if you don't you're dead
meat".

Personally, I thought Node.js was a _terrible_ platform for serving dynamic
web sites. It is, however, a great platform if you need to make a reasonably
performant general server with minimal effort (such as a message broker for
example).

Likewise, people will now order their projects in Go whether it makes sense
given the requirements or not. 20 years of Go experience will be needed on
CVs. And when Go inevitably fails at certain things, "everybody" will move to
the next thing - probably Rust, thereby completing the migration away from
dynamic scripting.

This is not reasonable, is it?

~~~
aikah
> That's going to be a large albatross around Go's neck, as it has been around
> node.js', and Rails before that. Large amounts of developers flocking to a
> new thing because "this is the thing to use now and if you don't you're dead
> meat".

TJ's blog post is basically like if DHH ditched Ruby/Rails for Go.

> Personally, I thought Node.js was a terrible platform for serving dynamic
> web sites. It is, however, a great platform if you need to make a reasonably
> performant general server with minimal effort (such as a message broker for
> example).

Totally agree with you,nodejs is not a silver bullet.

~~~
collypops
It's more like Zed Shaw leaving Ruby for Python.

That happened. So did lots of other stuff. Same as it always was.

------
sz4kerto
"In the past week I’ve rewritten a relatively large distributed system in Go"

Maybe I don't have any programming talent at all, but I cannot even imagine to
rewrite a 'large distributed system' in a week. The not-too-large distributed
systems I worked with had years of thinking behind them, I could not even type
in the characters of the code in a week.

~~~
thomseddon
You obviously don't know TJ...

[https://github.com/visionmedia](https://github.com/visionmedia)
[http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-
Holowaychuk-...](http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-
so-insanely-productive)

~~~
teacup50
What am I supposed to take away from these links, other than the technical
culture's self-defeating tendency to lionize individuals to fit a hero
narrative?

~~~
sergiotapia
If you read the second link, it's presented that that guy is actually a group
of people working under a phony name, to give the cult a "hero". Drum up hype,
etc.

It's been done before too!
[http://en.wikipedia.org/wiki/Nicolas_Bourbaki](http://en.wikipedia.org/wiki/Nicolas_Bourbaki)

\---

Nicolas Bourbaki is the collective pseudonym under which a group of (mainly
French) 20th-century mathematicians wrote a series of books presenting an
exposition of modern advanced mathematics, beginning in 1935. With the goal of
founding all of mathematics on set theory, the group strove for rigour and
generality. Their work led to the discovery of several concepts and
terminologies still discussed.

------
bsaul
I've often heard that Go founder were surprised that Go seemed to replace
python more than C++ or C which were the initial targets. By judging from the
given examples it seems that it isn't the case : people seem to come to Go
when they start looking for performance. Instead of writing C modules and
using them from python, they just switch everything to Go.

I'd be curious to know how many start ups prototype their first software
version with Go.

Note : as a coder that writes a lot of python, seing dropbox switch to Go in
parallel to python so often having toxic discussions about python 3 vs 2 is
_really_ painful.

~~~
pjmlp
Because thanks to our experience with strong typed languages with native
compilers and type inference, we know better.

Many of us have had the fortune to work with C, C++, Ada, .NET, Java, Delphi,
Modula and Oberon derived languages, ML language family.

So we already know what modern strong typed languages, with native compiler
toolchains, are capable of in terms of language features. And going Go feels a
bit backwards.

Regarding Python, I never saw it more than a scripting language for system
administration. ML based languages provided a better experience in terms of
both performance and productivity.

~~~
anko
.NET isn't a language.

The languages you list really suck compared to Go. They are ridiculously
verbose. Goroutines in particular are really quite nice.

~~~
pjmlp
> .NET isn't a language.

It is easier to name the eco-system than all the languages with available
compilers targeting .NET.

> The languages you list really suck compared to Go. They are ridiculously
> verbose.

Except they embrace the last 30 years of language research.

> Goroutines in particular are really quite nice.

Goroutines are nothing new. Modula-2 already had them.

~~~
anko
Gosh this reply is ridiculous.

We're talking about languages and .net isn't a language. The differences
between visual basic and f# are vast.

Are you saying the last 30 years of language research dictate that languages
should be more verbose?

Comparing go-routines to modula-2 is disingenuous at best. Multiprogramming is
nothing like multithreading.

------
jaxytee
TL;DR It is very likely that TJH is a hive mind.

FYI some question TJ Holowaychuk's 'person.' A glance at his github commits
would lead you to believe he is some open source prodigy, but there is a
curious case being built (share=1 trick, no Quora login needed):
[http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-
Holowaychuk-...](http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-
so-insanely-productive?share=1)

~~~
abritishguy
Lol, he works at segment.io and he is very much one person.

~~~
jaxytee
Have you met him?

------
jbb555
I don't understand why people like go. It seems to be missing a lot of
features and be pretty ugly and painful. I guess compared to javascript I can
see the advantages though

~~~
ovi256
Go could be improved in many ways. It lacks facilities that what we consider
modern programming languages have, e.g. object-oriented programming, generics.
The existing Goland solution to the generics problem is to have an almost duck
typing approach of doing everything via interface{}. These are the cons.

The pros are of such value that they more than compensate for the cons: first
class facilities for building concurrent programs and distributed systems.
These are language features such as go-routines and channels and standard
library includes for networking and RPC.

These are so great at what they do that they make programmers like me, who
like Go, overlook the suck that comes from the existing typing system.

My personal dream endgame would be a dynamic language, such as Python or Ruby,
that includes the concurrency features such as goroutines and channels.
Directly as language features. AFAIK, the existing GIL in the reference Python
and Ruby interpreters makes adding true goroutines impossible.

~~~
rakoo
> The existing Goland solution to the generics problem is to have an almost
> duck typing approach of doing everything via interface{}.

I see this repeated again and again. It's wrong.

The "solution" to the generics problem is to not try to do anything that is
generic, but do it specific: re-write that sort every time you need it for a
new type.

People who have some experience in Go seem to tell that when you go this path
you actually realize that you won't write them hundreds of time as was feared;
it's completely manageable. Plus, you have your "sort" re-implementation right
next to the struct definition, so you know it is sortable.

~~~
ovi256
I knew about this solution. It's just that my inner Ruby dev screams "DRY!".
Obviously it's so repetitive that it would be a bad sign in other languages.

I like more the solution used by the sort package. You can write generic code
that delegates specific type code to a few well-defined functions, like ones
that sort.Interface defines.

More here: [https://code.google.com/p/go-
wiki/wiki/GoVsGenerics](https://code.google.com/p/go-wiki/wiki/GoVsGenerics)

------
lmm
Go may well be better for many apps than js or C++, but there are other
languages out there. If you're looking for a new language it's worth
considering more possibilities, e.g. see
[http://roscidus.com/blog/blog/2013/06/09/choosing-a-
python-r...](http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-
replacement-for-0install/)

~~~
_yosefk
Incidentally, your link includes a great example of Go's error handling -
which is inevitably what _actually_ happens in languages without exceptions:
errors are silenced and the program marches on, each step making less sense
than the previous. It's a good talking point that you can always check error
values - but it never really happens, in part because library designers try to
avoid putting the burden on themselves and their users:

"Getenv returns the empty string and continues. Then Go somehow manages to
parse the empty string as an empty JSON list and still continues. Then it
tries to interpret the first of the user arguments to the program as the path
of the program to run and execs that instead! Utter failure."

I happened to write about it just before Go came out here:
[http://yosefk.com/blog/what-makes-cover-up-preferable-to-
err...](http://yosefk.com/blog/what-makes-cover-up-preferable-to-error-
handling.html)

It seems that having exceptions in the language is a great predictor for
libraries/built-ins barfing upon bad input vs silently producing garbage (as
in JS's "undefined" string produced from undefined values and propagated, or
Go's behavior above, etc.) For instance Lisp's NTH produces garbage and it
predates Lisp's exception handling features whereas AREF was added later and
indeed complains loudly, etc.

~~~
fauigerzigerk
_> It seems that having exceptions in the language is a great predictor for
libraries/built-ins barfing upon bad input vs silently producing garbage_

Maybe so, but having exceptions in a language is also a good predictor for the
misuse of exceptions for purposes other than error handling. For instance,
Python has the StopIteration exception to signal the end of an iteration.

Exceptions force API designers to decide whether or not a situation is
exceptional enough to force a stack unwind on the caller's end. That's not
something that's necessarily decidable from the point of view of the library.

For instance, say you have a function http.get(url). Should a 404 response
automatically raise an exception? What about a 301? A network issue? Surely,
for a crawler, a 404 is not exceptional enough to merit a hidden goto that
unwinds the stack frame (by default). The designer of the http library cannot
decide which status code is exceptional in every application.

It's similar with the results of SQL statements, file system access and all
sorts of other IO related stuff.

It seems to me that the more complex a system is, the more it needs a very
specific error handling strategy anyway and doesn't benefit from library
designers' opinions about what is and isn't worth a stack unwind.

That said, I do hate seeing

    
    
      if err != nil {
        return nil, err
      }
    

on every other line of code.

~~~
marcosdumay
> Maybe so, but having exceptions in a language is also a good predictor for
> the misuse of exceptions for purposes other than error handling.

Is that really a problem? I once hated such uses, but could never point why.

~~~
fauigerzigerk
I think it's a problem for two reasons:

First of all, sudden stack unwind comes with a greater mental burden than
regular structured code. Something implicit is happening that violates the
expectations we have based on what we can see.

Secondly, consistency is always important because inconsistency forces us to
think about things that we shouldn't have to think about, which lowers our
productivity.

------
Shish2k
> Statically linked binaries make for easy deployment

They certainly do, but have we solved the problem of statically linked bugs
yet? What happens when the next heartbleed happens?

~~~
pgeorgi
How many people updated their libssl packages without restarting the server
processes, thinking they're safe when they really aren't?

With a bug in such a central place you'll have to touch everything - could as
well rebuild everything, when your processes are prepared for it.

------
nemasu
When node first appeared, the thought of server side JS gave me shivers, maybe
I should trust my instincts more often.

~~~
CmonDev
It's good when you are writing it but someone else will be maintaining it :).

------
rcarmo
I was kind of expecting this. Although I like Go (and prefer it to NodeJS), I
hope forthcoming feedback on TJ's "life choices" does not degrade into a
"Let's move from Node to Go" echo chamber.

More importantly, I hope the Node community's self-centred "holier than thou"
doesn't bleed over, given that Go has (at least so far) kept a fairly high
standard of discourse.

That said, I, for one, welcome more contributors to the Go ecosystem. It is a
good systems programming language, but it needs a few more "horizontal"
libraries to make humdrum tasks (like parsing, accessing databases, etc.) more
palatable.

(edit: removed incorrect double negative)

------
eliben
It's not surprising that the same crowd that started switching to Node.js en
masse a couple of years ago is redoing it for Go :)

------
beck5
There are a couple of things which have stopped me getting into go which I am
ignorant about.

\- Lack of decent IDE with intellisense/good refactoring support.

\- Libraries seem to be globally shared between projects like rvm rather than
in the project like nvm.

Am I wrong, misguided or out of date on these things?

~~~
sagichmal

        > Lack of decent IDE with intellisense/good refactoring 
        > support.
    

Sublime Text + GoSublime; vim + go-vim.

    
    
        > Libraries seem to be globally shared between projects 
        > like rvm rather than in the project like nvm.
    

There's no fixed rule. If you need dependable reproducible builds, current
best-practice is to vendor your libraries in your repo.

~~~
beck5
Thanks, sublime tex and vim with plugins are still a long way off what you get
from a good ide. Just glancing there is no real refactoring support, its more
around auto complete.

~~~
sagichmal
Refactoring in Go is accomplished with `go fix`.

------
rufugee
It's a shame that the debugging story in Go is still "use GDB". It's really
lacking good visual debugger support afaik.

------
dccoolgai
So what comes after Go? I only ask because I figure if I start learning that
now, by the time they switch again I will have a fair chance of being
competent at it by then...

~~~
marcosdumay
I'm taking the oposite route. Once all those people live Go for something
else, I'll evaluate it and see if it's any good.

------
lsiebert
So I understand there isn't a go package manager like pip/npm/cpan. Is that
correct?

~~~
percept
See the "Managing Dependencies" section, and comments:

[https://www.digitalocean.com/company/blog/get-your-
developme...](https://www.digitalocean.com/company/blog/get-your-development-
team-started-with-go/#managing-dependencies)

Also:

[http://peter.bourgon.org/go-in-production/#dependency-
manage...](http://peter.bourgon.org/go-in-production/#dependency-management)

More discussion:

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

------
angularly
I wonder why they didn't choose Go in the first place. Both languages were
introduced in 2009, I remember evaluating both, and choosing Go because it was
clearly superiour when the goal was serverside, speed, stability, maintenance
and simplicity.

------
peterhunt
I want Go but with a really strong static type system. What do I use?

Haskell's Hackage seems to be full of broken packages.

OCaml seems to be stuck in 1999.

F#/Mono is pretty great, but tough to find quality libraries that work with
the tools I use (postgres etc)

Anything I'm missing?

~~~
jackyb
As far as I know, Go already has a really strong static type system (int32
cannot be assigned to int for example). Which parts are weak?

~~~
cgag
No generics (parametric polymorphism), no algebraic data types. You should
learn some Haskell or Ocaml even if you don't plan on using it in production.
Go's type system is weak.

Edit: I don't think there's anything like type classes either but I'm not
100%.

~~~
otikik
> Go's type system is weak.

It is strong enough for me.

I see the lack of algebraic data types and type classes as a feature,
honestly. It means I can learn the things I need and start working in 2 days
instead of in 2 weeks or a month.

I sometimes need generics, but not frequently enough to miss them.

You think Go's type system is weak. I think Haskell's type system is
overcomplicated. So, there.

~~~
DCKing
Go's type system being weak is a factual statement. Haskell's type system
being overcomplicated is an opinion.

One might prefer a weak type system over a strong type system, but that's a
different discussion. The parent clearly expressed that he wants a static
strong type system.

~~~
personZ
_Go 's type system being weak is a factual statement. Haskell's type system
being overcomplicated is an opinion._

Calling one weak and the other overcomplicated are both completely subjective,
biased statements.

And no, some random blog doesn't count as a citation: There are zero
legitimate, agreed to sources that will back up your definition. Instead it's
people painting broad strokes to bias the world towards their own beliefs.

Just as unreasonably I could say that Go has a Clarified Type System, versus
the Conundrum Type System found in Haskell.

~~~
DCKing
Are you aware that the notions 'weak' and 'strong' are actual terms used to
describe type systems [1] ? Did you bother to look that up before going
overboard and immediately accuse me of bias? I don't program in either Go or
Haskell.

Now whether Go's type system actually has the property of 'weak'ness is very
debatable. But whether it is true or false, it remains a factual statement.

[1]:
[http://en.wikipedia.org/wiki/Strong_and_weak_typing](http://en.wikipedia.org/wiki/Strong_and_weak_typing)

~~~
personZ
You should read the first sentence in the page you linked. To make matters
even worse, _none of the "weak" notions even apply to Go_, and I thought you
were talking about something entirely different altogether given that Go is by
zero definitions, colloquial or not, "weakly typed".

The post that set this off called Go's type system "weak". They were not
saying that it was weakly typed.

------
p0nce
> Not looking at Go yet? It may be a good time to do so now — everybody else
> is.

I'll be gladly left behind.

------
ricardobeat
> Text processing increased 64 percent just by moving from Node to Go.

And rewriting everything from scratch, plus it's a given that node isn't the
best tool for data processing..

------
tete
I agree. JavaScript is weird. I think ECMAScript will make a lot things
better, but it will still be a couple of months and it still won't fix it all
- still a huge step of making it a really usable language for many things.

Node.js is becoming mature, less trendy. I really find it weird how people
compare it age wise with Go. JavaScript is way old than Go or other languages.
V8 is also older than Node of course. ECMAScript didn't have breaking changes
in a really long time. There are many, many implementations. SpiderMonkey has
been used on the server side for over a decade now.

Go looks great. There are some rough edges though and whether really good
solutions will build up for these things is a really interesting thing to look
at.

It is really nice to see Node.js, Go and Rust emerging in amazing ways, all of
them fixing problems in amazing ways. I love how great concepts, like node.js
streams and pipes are copied to Go and Rust in ways that match their styles,
not just blindly.

All these things even influence languages like Java and C++. Who would have
known only a couple of years ago that things would emerge in such ways and
that it needs some projects with the idea of yet another programming language.
What is even more interesting is that a lot of concepts actually stem from
Perl... well, not necessarily the language itself, but libraries, modules or
Perl6, which arguably was/is a really ambitious research project. It's a bit
how many concepts took ages to be ported from Plan 9 to other operating
systems.

Anyway. It is great to see how people nowadays look at other projects and
don't judge by first impression anymore.

At least it seems like it. Node.js looked extremely awful to me in the
beginning and turned out to actually not be (despite its shortcomings and
JavaScript, which also turned out to be nicer). On the other hand projects,
like Meteor that looked at least okay in the beginning turned out to be way
more awful than they looked when I first heard that they don't even support
proper REST.

I know, my opinion on this might not be really popular, but it's amazing to
see how so many new concepts emerge, even when they seem crazy, sometimes turn
out to be crazy, sometimes turn out to be amazing. It's hard to know where we
will stand in a couple of years. However, I don't think only one of Rust, Go
or Node.js will make the race and I think none of them will look like they do
today in one or two years, especially when it comes to their ecosystems. Just
because all of them are too young to be judged upon and all of them are
changing too rapidly (or new standards are upcoming, as with ECMAScript), so
that nobody really has or can develop a deep understanding of the
language/framework yet, not even its developers.

What I really hope though is that there will soon be more big projects than
just Docker and a bigger ecosystem.

