
Google's Go Programming Language Grows Up: Now What? - rohshall
http://www.readwriteweb.com/cloud/2012/03/googles-go-programming-languag.php
======
danenania
I've been learning and trying out both Clojure and Go recently. While they
clearly take very different approaches on many issues, I think they also have
a surprising amount in common in their core philosophies. They both focus
strongly on simplicity, removing boilerplate, performant and minimalist core
data structures, and providing clean abstractions for parallelism.

The split in how each goes about targeting 'simplicity' is quite interesting,
and seems close to the heart of each language. In Go, simple seems to mean:
obvious, intuitive, unclever, and familiar. Clojure's conception is much
headier: simplicity isn't accomplished through familiarity and comfort, but
through the power and flexibility to create appropriate abstractions, and the
discipline to avoid dangerous ones. The most immediate consequence, for a
newbie, is that Go feels a lot easier to learn, while Clojure is more mind-
expanding and abstract. In Go, simplicity is easy. In Clojure, the simplicity
is deeper and perhaps more theoretically pure, but reaching it can be quite a
challenge.

My preliminary feeling so far is that each feels like a very clean, modern
language and is basically superior to other languages I've used (Ruby, Python,
C, js) by every important metric except maturity of community and libraries,
and each will have its place. Go's lack of cleverness probably makes it ideal
for more run-of-the-mill systems with a lot of straightforward io, where
organization, maintainability, and baseline performance are more important
than development of powerful algorithms, while Clojure will be a better fit
when cleverness is desired either to solve difficult problems or for rapid
feature development (a la pg's Beating The Averages). I could also see them
potentially working quite well in tandem for a system that spans both those
categories.

One more thought: as much as I like Clojure and understand the pragmatism of
targeting the jvm, Go's ultra-simple, ultra-fast runtime, along with libraries
and a community that embody a similar spirit, really is _such_ a breath of
fresh air compared to the jvm world and even the ruby/python worlds. In this
realm I think Go beats Clojure at its own game. Thanks to the more 'difficult'
choice of starting a fresh platform rather than leveraging an existing one,
Go's whole ecosystem and development experience now share a unifying
philosophy, and every aspect of working with Go is suffused with what makes Go
great.

~~~
reddit_clone
I wonder how hard/easy would be to compile Clojure to a native application?
Perhaps targeting something like LLVM?

Of course the big advantage of easy availability of all those Java libraries
will be gone. But it might open other doors.

~~~
winter_blue
gcj (GNU Compiler for Java) can compile JVM class files to machine code.

Technically, the JVM also compiles your Clojure to the native instruction set,
via JIT; but I don't think a JIT compiler performs the same level of
optimizations (due to time constraints) as a say "gcc -O3".

------
jeremyjh
This is really getting a bit overheated.

I think I understand where the Go team is coming from, but there is so much
hype from other quarters that I think is at best premature.

I think Go will be a fantastic alternative to C for "systems" programming,
once it matures. I think this was one of its most immediate original goals,
but really it is not yet ready to do even that. Two main reasons it is not
ready for that is that performance is not _yet_ there though I think it will
get there; second reason is that it has no support for dynamic linking or code
loading. You can't write something like Apache, or even Nagios in a platform
that has no support for loadable modules. Still I think there are LOTS of
applications where these constraints would not be an issue.

So then we have all this hype and people doing things like building web
applications in Go and calling it the next Node.js or Ruby or Python and
frankly this is just stupid. Despite some claims it has nowhere near the
expressive power of those languages. It is statically typed but has no
Generics - and there are quite a few use cases where there is no
answer([https://groups.google.com/forum/#!topic/golang-
nuts/PYJayE50...](https://groups.google.com/forum/#!topic/golang-
nuts/PYJayE50JZg\[1-25\])) and you will just have duplicate code.

It polymorphism but no inheritance - and the way interfaces and composition
works while still fairly powerful is not at all what an OO programmer would
expect(<http://xampl.com/so/category/software/golang/>) just naively reading
about this feature. Whatever you want to say about the benefits of simplicity,
this is LESS powerful than any OO dynamic language. Go's closures are nice,
but aside from that on what basis can any other claims be made about its
expressive power?

In fact, the language is intentionally very, very limited. They want large
teams of mediocre programmers [1] to produce code that is very supportable.
Everytime someone in the lists brings up a "why don't we have" question all
the answers revolve around this premise, that the language becomes "too
complicated" if you have crazy features like generics. So it seems Go is
optimized to satisfy the angst of systems programmers who have to work on C
code that is thirty years old and been maintained by dozens of people. I get
it, but that doesn't mean its really a good language for hackers to use to
build the latest social network for people who like cats.

Ok so concurrency. Yes Goroutines are smart. Channels are smart. These are
great features. Scala can do the same thing (and more elegantly) with it's
Actor constructs. The same thing can probably be done in other languages such
as Ruby (<https://github.com/igrigorik/agent>). Its nice that this feature is
in Go from the beginning, but its going to make its way into other platforms
as well.

Performance. Well...lots of blog articles just keep repeating the mantra of
"native code" as though it automatically means something. It doesn't. C isn't
just fast because it generates native code, it is fast because it's compiler
has been optimized for decades. Go doesn't have that today. In fact today, Go
is slower than Java and Scala based on both Google's benchmarks
([http://www.readwriteweb.com/hack/2011/06/cpp-go-java-
scala-p...](http://www.readwriteweb.com/hack/2011/06/cpp-go-java-scala-
performance-benchmark.php)) and the language shootout
([http://shootout.alioth.debian.org/u32/which-programming-
lang...](http://shootout.alioth.debian.org/u32/which-programming-languages-
are-fastest.php)). Go will get there almost certainly, or at least very close,
but it isn't there today.

Today if you want a static, fast language with good concurrency and an
incredible standard library and extended library ecosystem then you want Scala
I think. If you want a powerful, expressive language for quickly building web
applications then you want Python, Ruby[2] or Node.js or similar. If you want
a language is actually very fast and with incredible libraries you want C/C++.

I really do not hate Go. But it is not yet ready to replace hardly anything in
my opinion.

edit: [1]You are right. The "mediocre programmer" comment is really out of
line and a major distraction. I guess I actually think this IS a feature of
Go: more maintainable code than C/C++ from mediocre developers. I'm bitter and
tired ofdebugging twenty-year old C programs and I wish they were all written
in Go. I shouldn't read that into Thompson's or Pike's intentions though.

[2]May brain stopped working here - I meant Ruby not Java.

~~~
discreteevent
"They want large teams of mediocre programmers to produce code that is very
supportable."

I think any argument that uses the phrase 'mediocre programmers' should set
off alarm bells by now. Its critique by slander. The creators of the language
(who are not mediocre) like simple languages. The desire to make things more
transparent and simple is does not reflect on a person's capacity it reflects
on their taste (insert Einstein quote, St Exupery etc). Ken Thomson is not an
idiot for example but:

"Computer: Your nominators and endorsers for the Kanai Award consistently
characterized your work as simple yet powerful. How do you discover such
powerful abstractions?

Ken Thompson: It is the way I think. I am a very bottom-up thinker. If you
give me the right kind of Tinker Toys, I can imagine the building. I can sit
there and see primitives and recognize their power to build structures a half
mile high, if only I had just one more to make it functionally complete. I can
see those kinds of things.

The converse is true, too, I think. I can't from the building imagine the
Tinker Toys. When I see a top-down description of a system or language that
has infinite libraries described by layers and layers, all I just see is a
morass. I can't get a feel for it. I can't understand how the pieces fit; I
can't understand something presented to me that's very complex. Maybe I do
what I do because if I built anything more complicated, I couldn't understand
it. I really must break it down into little pieces."

Is he an idiot because he couldn't understand it? Or they giving awards to the
wrong people? Could it be that to recognise everybodies limitations when
working with code day in day out (not just the mediocre people) is actually a
valuable insight?

~~~
jeremyjh
You are right, Rob Pike said it was for "large teams". In most places (maybe
not Google) "large team" will often mean an average skill level that is
mediocre. I do not understand why a large team of very skilled programmers
can't build large systems that are very maintainable in more powerful and
expressive languages. I do not understand the argument that a language is "too
complex" in this context.

edit: You are right and I added this to my top-level comment. The "mediocre
programmer" comment is really out of line and a major distraction. I guess I
actually think this IS a feature of Go: more maintainable code than C/C++ from
mediocre developers. I'm bitter and tired ofdebugging twenty-year old C
programs and I wish they were all written in Go. I shouldn't read that into
Thompson's or Pike's intentions though.

~~~
jbooth
Whenever I hear someone denigrate simplicity in a language as something that
caters to 'mediocre' or 'average' programmers, I'm reminded of the surveys
where 80% of people think they're an above average driver.

------
davidw
I am / We are considering using Go, but I'm a bit reticent about its maturity
compared to Erlang, which is a very, very solid system. The 32 garbage
collection issue is a big question. Arm support is another. Also, all the
extras Erlang gives you in terms of writing robust systems look pretty
attractive.

That said, I'm about 99% that Erlang will always remain a niche player, along
the lines of Smalltalk and Lisp, whereas Go has a shot at 'the big time'.
That's something to keep in mind in terms of hiring people and getting other
people up to speed on the language. Go is something that other people will
look at and 'get' a bit quicker than Erlang.

BTW, interesting article on Go concurrency vs Erlang concurrency:
<http://www.informit.com/articles/article.aspx?p=1768317>

~~~
luriel
You might want to watch this talk about using Erlang in production:
<http://www.youtube.com/watch?v=G0eBDWigORY>

Go and Erlang have some differences, and I found particularly interesting that
pretty much all the issues they have with Erlang don't apply to Go often
because of how Go avoided what might seem superficially like a 'feature' in
favor of "raw" simplicity.

That said, Erlang probably would be my second choice after Go if I had to
build a highly concurrent distributed system, just realize that things are not
as rosy as they seem.

BTW, to address your other comments: all the remaining 32bit GC issues should
be solved in the upcoming Go 1.1 release (still you will always be much better
off using the 64bit port), and the ARM port is in pretty good shape.

~~~
davidw
> Go and Erlang have some differences, and I found particularly interesting
> that pretty much all the issues they have with Erlang don't apply to Go
> often because of how Go avoided what might seem superficially like a
> 'feature' in favor of "raw" simplicity.

Some of what they discuss simply isn't available in Go, like OTP, so I
wouldn't count that as a "win" for Go. Other things like 'heart' are things I
_want_ , given that it's going to be for a semi-embedded system.

That's a good video, but all languages have gotchas and things to watch out
for, especially mature ones. Go has some advantages in a 'fresh start': some
of the biggest Erlang warts are actually the language itself; the syntax,
records, some things like that that are just kind of ugly.

For a product currently in development, "should be solved by a future release"
is probably too far in the future to matter much. "pretty good shape" sounds a
bit worrisome for a semi-embedded device where updates via the internet are
not necessarily going to be an easy proposition. 64bit is going to eat more
memory, something we'd prefer to avoid if at all possible.

------
esolyt
"Now that Google has released a stable version, and is deploying support on
Google App Engine, it's likely to gain even more traction."

I think what Go actually needs is another popular framework so that the
language can be used without depending on Google's App Engine and it's
unstable pricing.

~~~
genbattle
The great thing about Go as a web language is that alot of the bones are
already there - templates and HTTP handling are already waiting for you in the
standard library.

The most popular web frameworks i've seen for Go so far are Web.go (a Web.py
clone) and Revel (a Play clone). Frameworks will develop organically over
time. The only reason they're not very strong at this stage is because as I
said; most of the batteries you need for web development are already included
in the standard library.

~~~
luriel
> The most popular web frameworks i've seen for Go so far are Web.go (a Web.py
> clone) and Revel (a Play clone).

Unfortunately both web.go and specially Revel were developed by people that
were not (yet?) familiar with Go's style, and they simply cloned what they
expected from other languages and frameworks they were more familiar with.

Gorilla[1] and pat[2] (by the creator of Sinatra, who is now a Gopher) fit
much more with the Go style and philosophy.

[1]: <http://gorilla-web.appspot.com/>

[2]: <https://github.com/bmizerany/pat>

------
lucian1900
Go's GC is in fact much, much worse than the JVM's. One may have less memory
issues because Go tends to generate less garbage, though.

~~~
thebluesky
In truth pretty much every language's GC is worse than the JVM's.

~~~
KaeseEs
Lisp implementations have had excellent GCs that are broadly better than the
JVM for years.

~~~
jbooth
Do you have a source for that? I could see a purely functional language
creating much less garbage than Java and/or providing much easier escape
analysis scenarios, leading to better performance, but I'd be very surprised
to see them perform better for similar amounts of heap allocation, given all
the work that went into the various Java GC algorithms. I mean, those LISP GCs
probably predate wide adoption of threading, right?

------
aartur
I don't like that Go has builtin generic collections, but doesn't allow
programmers to build their own. It feels more like some corporate/"4GL"
programming language than a hacker's/"real" programmer's one. Maybe lack of
generics is not so important, but it shows designer's attitude towards
language users.

~~~
ovidiu
This issue has been addressed in the FAQ. They say generics might get added at
some point, but they don't want to rush it. C# 1.0 didn't have generics
either. <http://golang.org/doc/go_faq.html#generics>

~~~
aartur
I meant that if they use generics in some built-in classes, they should also
give that possibility to users. If they cannot give it to users, they
shouldn't use it in built-in classes. It feels like they think users are too
dumb to implement their own, so they give some created by them.

~~~
ovidiu
Maybe they are afraid of introducing some features they would later regret.
This is not a hobby project of some lone hacker, it's meant to compile
Google's infrastructure.

I really don't see why user code has to have the same capabilities as the
runtime. It looks more like a philosophical request than a practical one.

------
biomechanica
It's seems like there's been a lot of posts about Go lately. Maybe I'm
delusional..

I find Go to be nice to work with. I'm just starting out in it so I'm not
exactly proficient yet, but it feels a lot easier to program with against say,
Java.

In regards to the GC. I saw a post a little while ago made by Rob Pike, I
think (could be wrong) about how there are many improvements coming where they
see 50% speed ups (sometimes even more). So, as young language I think Go has
come pretty far and more is to come.

~~~
nicholassmith
No, I agree there seems to be some kind of watershed moment where a lot of
people are talking about it.

~~~
jff
And, apparently, a few people are now pissed that every post isn't about
Node.js or Ruby anymore, because I have come across a small group of people
that come into every Go thread and spread the same FUD about garbage
collection, performance, maturity, and generics.

~~~
nicholassmith
Means it has hit a level of success then, remember when every thread about
Ruby would degenerate into "YEAH! But RoR doesn't SCALE! HAH!"? Level of snark
seems proportional to the level of success a language is enjoying.

I must admit, I've not tried Go yet and I'm not overly sold on some of the
syntax aspects but it's nice to see a new language doing well against
established players.

------
bkirkby
i've not had a ton of experience with Go, just some coder challenge type
stuff, but i love almost everything about the language. it has the feel of old
skool C, but greatly improved and upgraded.

the one thing i hate about Go is how it does exported identifiers. in order to
make a variable/method available to other packages, you must start the
variable name with an uppercase letter. this is the only way to export
identifiers which means the exporting is a bit obfuscated.

giving meaning to the first letter of a variable name is filled with potential
problems:

1\. people will inadvertently export properties simply because they chose to
name them with uppercases 2\. in some cases, you will need to force this case
sensitive language to be case insensitive. ex: a json property named "address"
needs to unmarshal into a Go variable named "Address" 3\. i don't have this
concern personally, but i wonder about coding in languages that don't have
uppercases. (actually, it's prolly legit to force them to code in english i
suppose)

i've read the Go engineers are extremely happy with this feature, so i guess
i'm going to have to get used to it and the bevy of problems it creates if i'm
going to continue using it.

~~~
markdrago
FWIW the 'tag' concept in Go alleviates concern #2.

Info regarding tags (scroll a bit): <http://golang.org/ref/spec#Struct_types>

How tags are used by the built-in JSON encoding library:
<http://golang.org/pkg/encoding/json/#Marshal>

Of course, just because this kind of thing can be handled with tags doesn't
mean that people will actually know to use them or actually use them
correctly.

~~~
bkirkby
thanks for that! i wasn't even aware of field tags.

i can see this solution causing other problems too. there can only be one tag
per field, right? what happens when another library has a different meaning
for the tag?

are we going to see a hacky standard emerge where we have multiple tags in the
one field separated by semicolons (with a precursor for each tag like
'json:')?

it feels like an ugly hack to use tags this way, but i guess an ugly hack is
what is needed for this right now.

i would much prefer a separate keyword to explicitly export fields. or, since
we are already hacking the tag, why not have the compiler export any field
with a tag called "export"?

------
rbanffy
Just out of curiosity, is anyone using Vala? I was asked to do a little bit of
research into alternatives to build a cross-platform chat client and, along
with the more obvious Java, C++/wx, Objective-C/OSX/GNUStep and C#/.NET/Mono
stacks, I found Vala as a possible option.

------
muruke
I haven't written anything real in Go yet, but there is a lot of articles
about it, and many parts of it do appeal to me. I like how they didn't write
another language for the JVM, I like the c inspired syntax, I like the
concurrency model they have, etc. It also seems to be getting a lot of praise
in web development circles.

But am I the only one that cringes at going back to writing & and * for
passing parameters etc. for web development? I know there is sometimes a need
for really managing memory but... I'd love a simplistic language built around
the ideas of Go (small runtime, fast, type safe, compiled etc.) for building
web apps.

Time to download Go source and tinker...

------
kennethh
What web framework should one use with Go?

~~~
gamache
There seems to be a bit of traction around Revel:
<http://robfig.github.com/revel/>

It was founded as a Play framework derivative, if you're familiar with that (I
wasn't). I've been using it to put together a web service and I like it so
far.

~~~
luriel
Revel is getting traction mostly among people who (like its author) are not
very familiar with Go.

As gorilla <http://gorilla-web.appspot.com/> and pat
<https://github.com/bmizerany/pat> (by the creator of Sinatra) are much more
in line with the Go philosophy.

~~~
batista
The good (brilliant) thing about Play for Java, was that it wasn't inline with
the Java philosophy.

So, Revel not being in line with the Go philosophy could also be a great
thing.

------
sgdesign
Like everybody, I've been hearing good things about Go lately. But although
I'm curious about the language, its homepage (<http://golang.org/>) doesn't
make a great impression. It looks very amateurish and unappealing.

And you can pretty much say the same thing about <http://www.scala-lang.org/>
and <http://clojure.org/>

It might not seem like a big deal, but it would certainly not hurt a
language's popularity to have a slightly nicer site. Unless of course these
languages _don't_ want to become popular.

Edit: I actually can't find a single language site that looks good. So maybe
bashing Go for this is unfair, although I still find the Go site particularly
bad.

~~~
IvarTJ
I am not sure what you find unappealing about those websites, but I find Go’s
website very easy to navigate and for browsing the standard library. When
looking for software to depend on, I think I prefer a visual design that does
not attempt to be in any way “mysterious,” but rather simple and predictable.

~~~
modarts
How do you equate "mysterious" with good visual design?

~~~
IvarTJ
I made an uneducated guess for why sgdesign disliked golang.org’s web design.
I think an unearthly visual design is more appropriate for adventure games,
less so for software tools. That does not mean that only “mysterious” visual
design is good visual design.

------
scriptproof
"programming to that in a way that is nonblocking". It is strange that go it
compared to Node.js and this sentence is false. Each function has a Sync
version to program in "blocking" way.

~~~
gfosco
Sure there are Sync versions, but you almost never want to use them. There's
nothing wrong with his sentence. He did not enjoy the Node.JS callback style
event loop. I love it.

------
webreac
It is too sad, they choose the name of my favourite game to name a language.
Now it is near impossible to make google searches about game of go.

~~~
praptak
The popularity of the verb "go" doesn't help either of the search terms. It's
even in the article itself: "Can Go Go Mainstream?"

Where Would Go Go if a Woodchuck would Go(#) Go?

(#)As in "rewrite all of his woodchucking apps in Go"

~~~
genbattle
To be fair, this will change as go becomes more popular and mature, I don't
even know why people keep bringing it up.

Is "C" any more searchable? If C was 3 years old, search results would
probably be dominated by pages on the letter "C". I remember search results
when C# first came out: most search engines presumed you were talking about
musical notes. Java searches kept showing me pages about coffee suppliers and
distributors.

None of these languages have this problem anymore because they are mature, and
the context around them is firmly established.

The accepted name for the language when doing searches is "golang", and Google
does a great job at optimising results around this term. Also there's the IRC
channel and Google group if you can't find what you need.

~~~
luriel
> Also there's the IRC channel and Google group if you can't find what you
> need.

The irc channel is #go-nuts in freenode, in case anyone was wondering.

And there is also <http://www.reddit.com/r/golang>

