

Go at Heroku - build your own Chubby - timclark
http://www.theregister.co.uk/2011/05/05/google_go/

======
supersillyus
At the very end, there's quote from Scala designer Martin Odersky:

    
    
      "I like a lot of the design decisions they made in the language.. Basically I like all of them."
    

Considering how (at least, to my eye) the design principles of Scala seem very
different than Go, I find that surprising. I guess it makes sense if you
consider that there are multiple valid design paths that one can take.

~~~
LiveTheDream
Someone described to me recently "Go is to C as Scala is to Java".

~~~
micrypt
That doesn't quite sound right. The only premise I'd imagine in which it could
be correct is to describe one as an "evolution" of the other.

------
Detrus
Some key quotes

 _"Previously, these operations people would write these in Python, but
they're finding that Go is much faster in terms of performance and time to
actually write the code."_

Go beating Python in time to code?

 _"[Node.js is] a single thread. In a very similar amount of code, you could
write a goroutine-heavy server that could handle tens of thousands of requests
and use all the cores on your machine, so that if the requests were expensive
– if they were CPU-intensive – you'd have a chance of keeping up," Pike says.

"Node.js shows great numbers for heavy numbers of clients, and they've done a
really good job. But if those clients are CPU-intensive, they've got no place
to go. You can't get the parallelism you need. With Go, you get the best of
both worlds: You get many clients easily handled, and if they're CPU
intensive, you can imagine scaling to a much larger number of requests."

What's more, Gerrand argues, Go doesn't force developers to embrace the
asynchronous ways of event-driven programming. ... "That lets you write
asynchronous code in a synchronous style. As people, we're much better suited
to writing about things in a synchronous style."_

Not quite true about CPU-intensive tasks. Node can use webworkers and leave
the main thread for handling small requests. Obviously JavaScript is slower,
webworkers open up heavy OS level threads (at least in browsers, not sure
about node), but there is somewhere to go.

I like the competitiveness either way. Go deserves more popularity.

I wonder, is it possible to do some syntax rewrite to make it look like a
weak/dynamic typed language and only use static types when you need the
performance? That would give them a popularity boost from superficial
Ruby/Python devs traumatized by systems programming.

~~~
enneff
> Go beating Python in time to code?

Yes, that's what they tell me. Among other reasons, static typing means
catching programmer errors faster.

------
jamii
> [Go] gives a new breed of concurrency you won't find in other languages,
> including Erlang. And this comes from goroutines. Goroutines aren't threads
> or lightweight threads. They aren't callbacks. They're processes within a
> single address space that can communicate with each other.

> Grasping the concurrency may take a little longer, even if you're experience
> with something like Erlang – "the concept's a bit difficult to grasp if
> you've never been exposed to message-passing inside of a program before,"

There are many interesting differences between erlang and go (eg single
mailbox vs channels, process separation vs shared heap) but the above is
misleading at best. Goroutines are very much like erlang processes and both
languages make heavy use of message-passing inside programs.

Journalists: get your interviewees (ie the people who know what they are
talking about) to proof-read articles!

------
anotherjesse
Source and docs at <https://github.com/ha/doozerd> and
<https://github.com/ha/doozer>

~~~
MatthewPhillips
Seems to, for the most part, break the Go convention of return an os.Error
when something unexpected happens.

------
calloc
Here is the actual Doozer introduction by its creator:
<http://xph.us/2011/04/13/introducing-doozer.html>

~~~
joshu
is it just me or are the embedded links unclickable?

~~~
calloc
Definitely not just you. I can't select any of the text either!

------
stephth
Great article. It's barely about Doozer, it ends up being a great piece of
journalism about the Go language.

------
timclark
Also lots of additional material about the Go language if you read past the
first page.

~~~
JonnieCache
Single page version:
<http://www.theregister.co.uk/2011/05/05/google_go/print.html>

------
exDM69
What is nice about these lightweight thread multiplexing languages and
runtimes is that you don't have to write your apps in the butt-ugly
continuation passing style (doSomething("foo", function(result, err) {
print(result); }). This is something that the compiler and runtime can do for
you in Go/Haskell/Erlang/etc where using a blocking system call will
effectively do the same, but it's automatically done, not by the programmer.

Of course you can get the same effect with Node.js/Boost.asio, but I find it a
bit clumsy.

------
comice
What was wrong with Apache Zookeeper? No mention of it at all!

~~~
woodrow
I think the Doozer people misunderstood Zookeeper. They claim that ZK is
focused on providing locks, but ZK really just provides a consistent
hierarchical datastore that can then be used to construct locks, perform
leader election, etc. See
<http://zookeeper.apache.org/doc/r3.3.3/recipes.html>

