
New stable release of Go - uriel
http://golang.org/doc/devel/release.html#r57
======
kaib
This is actually the first proper stable release since the process was
introduced, the first tagged release did not go through a similar release
preparation.

I'm personally extremely happy with this development. We run Tinkercad on a
moderately complex Go/C++ based server infrastructure (7 server types on tens
of machines) and we have been lagging the Go tip given our need to avoid
instability. The fact that we can now sync more often than 6 months and with
less risk is great. It's a important step towards making Go a solid choice for
distributed systems programming.

------
timclark
Reasons to like go:

gofmt - no need to argue over coding style since it is enforced by this tool.

gofix - as the language evolves, the go team provide fixes that you can run
across your old source code automatically.

~~~
munificent
If you look at the actual fixes gofix provides, most of them are to paper over
a lack of language features. In particular, if Go supported function
overloading, they probably wouldn't need gofix at all.

~~~
jff
"If they just had function overloading, we could keep dozens of old,
unmaintained functions around forever! Think how amazing documentation will
be!"

~~~
pjscott
As it is, their core libraries are remarkably clean and well-designed. The
source code is even a pleasure to read.

~~~
munificent
It's pretty to make version one of your language's libraries clean and simple.
The real challenge is how they hold up over time and the needs of evolution.
Go's philosophy seems to be:

1\. Simplicity matters more than compatibility. 2\. Assume all extant Go code
is easily mutable.

The purist in me finds that appealing, but I'm not sure how that will hold up
over the long term. The language seems intentionally designed to _not_ evolve
which doesn't seem like a good way to stay useful for real people for a long
time.

Maybe I'm wrong and everything will work out, but I wonder if several years
from now, Go will just fall over from its inflexibility and become unusable.

~~~
jff
You typically can't even compile Linux with the previous GCC version, yet
somehow that kernel has been tottering along for about 20 years now.

If you compile a program using Go, you get a binary that will run forever.
Statically linked, contains the runtime, you're all set. If you update Go, you
can then re-build that same program, but you might have to update a few things
to get a working binary again--but you only have to do this if, somehow, that
originally-compiled binary isn't working for you.

If Python decides they want to change the syntax for opening a file, then you
can either 1. Keep a second Python around forever for compatibility or 2.
Modify your program so it uses the new syntax. Go will never do this to you;
as long as your OS continues to support the same binary format, I don't see
why a binary shouldn't work indefinitely.

------
Kilimanjaro
Now all we need is Go on AppEngine. Killer.

------
swannodette
What's the appeal of Go when something like OCaml exists and seems to cover
much of the same territory and delivers better performance? Not trolling here,
I'm genuinely curious.

~~~
uriel
First of all, it is quite obvious that Go and OCaml are completely different
languages designed around very different philosophies and styles.

Also saying that you are not trolling doesn't make your comment any less
trollish, specially given that your only claim is false, Go, despite still
being much younger and greatly unoptimized is already considerably faster than
OCaml:
[http://shootout.alioth.debian.org/u64/benchmark.php?test=all...](http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=ocaml)

~~~
swannodette
I'm asking about _technical_ merits of one over the other, which you didn't
respond to at all. And look at the overall scores on the 64bit one-core and
quad-core benchmarks. OCaml is ahead.

~~~
chc
I'm looking at the overall scores on the 64-bit single-core and Go is six
places ahead of OCaml. On the 64-bit quad, Go is five places ahead. The only
one where OCaml appears to come close is single-core 32-bit, in which Go comes
out one place ahead of OCaml.

(And just so we're clear: I actually like OCaml and have never used Go. So I'm
not trying to wave some Go fanboy flag or anything. Those are just the
numbers.)

~~~
swannodette
[http://shootout.alioth.debian.org/u64q/which-language-is-
bes...](http://shootout.alioth.debian.org/u64q/which-language-is-best.php)

[http://shootout.alioth.debian.org/u64/which-language-is-
best...](http://shootout.alioth.debian.org/u64/which-language-is-best.php)

~~~
uriel
I thought you were talking about performance, in which case the relevant chart
is:

[http://shootout.alioth.debian.org/u64/which-programming-
lang...](http://shootout.alioth.debian.org/u64/which-programming-languages-
are-fastest.php)

Which shows Go is well ahead of OCaml.

The "which language is best" chart you linked has rather arbitrary weighting.

~~~
igouy
Did you downvote my reply instead of trying to justify your own comments ?

~~~
chc
You can't downvote replies to your own comments on Hacker News, so that seems
unlikely unless he's sock-puppeting.

------
icey
Is there any sort of "Planet" for Go? (i.e. <http://planet.lisp.org/>,
<http://planet.python.org/>, <http://www.planetscala.com/>,
<http://planetcsharp.com/> etc?)

~~~
uriel
<http://planet5.cat-v.org/> is the closest, but haven't maintained it properly
for a while, I should add a few new blogs and remove some that are obsolete.

~~~
smosher
ichi ni san shi Go.

------
lobster_johnson
I haven't used Go het, but try to keep up to date. One issue I have is that
naming conventions seem all over the place. Is there a logic behind the naming
of things?

For example, function names are sometimes CapitalizedLikeThis, but
sometimesLikeThis. This kind of messy inattention to detail makes the language
come across as sloppy and unfinished.

~~~
uriel
This is covered in the basic language introduction: names starting with a
capital letter are public, names starting in lower case are private.

Go's naming conventions are much more clean, respected and even enforced than
in almost any other language I know (Ruby and Python are specially bad in
this, but C++ and Java are not much better).

~~~
198d
_Go's naming conventions are much more clean, respected and even enforced than
in almost any other language I know (Ruby and Python are specially bad in
this, but C++ and Java are not much better)._

Do you mind explaining this statement a little further, specifically related
to Python and Ruby. I work with both of those languages and find the naming
conventions to be quite clean and respected. The style of the language is not
enforced, but you'll certainly be chastised by any serious developer in either
language for doing something outside the norm.

~~~
uriel
The Python stdlib is full of examples of CamelCase, under_score and
alltogether.

In Ruby just looking at the methods for strings is enough to find this like:
"instance_variable_defined?", "rindex", "tr_s", "casecmp", "equal?", "eql?"
and more. Yes, it is all lower case, but consistent it is certainly not.

~~~
lepht
I also find myself wishing that Ruby's destructive (!) and boolean (?)
suffixes were either enforced somehow or not used at all.

The idea itself is cool, communicating extra context about what the method
does or its intended usage, but they're used so inconsistently (even withing
the Ruby stdlib) that A) They're unreliable and you need to check the source
to find out the behavior anyway and B) It's less predictable whether the
method exists with the suffix or without, so you need to either run it and
modify your method call if there's an error or check the lib/API docs. This is
the sort of thing that makes having an IDE handy for completing method names,
which is unfortunate because Ruby is generally very usable without any IDE
crutches.

------
leon_
Go replaced python for me. Today morning for example I wrote a utility/demon
that controls my Macbook Pros's Fan under Linux (because out of the box the
fan stays @ 2000rpm till somewhere around ~80C).

I've also written 2 smaller web apps using Go and I had really fun doing so.
Statically typed language for webdev = <3

I can say I became a Go fanboy in the last few weeks and I hope Go gets more
traction. Go @ Android would be freaking awesome.

~~~
singular
go already targets arm, android can't be too far away.

~~~
uriel
Also Brad Fitzpatrick (of LiveJournal and memcached fame) recently moved from
the Android team to the Go team.

Go on Android should be quite cool, but what will be awesome is Go on
AppEngine.

~~~
leon_
> Go on AppEngine

I hope that's the "surprise" Andrew mentioned on twitter: >
<http://twitter.com/#!/go_nuts/status/63762141555064832>

~~~
uriel
I hope so, in the mean time there is this issue in the AppEngine tracker:

[http://code.google.com/p/googleappengine/issues/detail?id=23...](http://code.google.com/p/googleappengine/issues/detail?id=2382)

