4 ms·

Go at Heroku - build your own Chubby

96 points by timclark 15y ago

timclark 15y ago
Also lots of additional material about the Go language if you read past the first page.
- JonnieCache 15y ago
  Single page version: http://www.theregister.co.uk/2011/05/05/google_go/print.html http://www.theregister.co.uk/2011/05/05/google_go/print.html
- enneff 15y ago
  Indeed, and the HN title is wrong.
supersillyus 15y ago
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.
- icey 15y ago
  I think it's much more challenging to find quotes from Martin Odersky where he talks about disliking a language than it is finding quotes where he talks about liking one. Scala is a bit of a kitchen-sink language; there are things in there from all over the place. It makes sense that he can find things to like in many disparate languages. (fwiw: I like Scala, and I like that Martin Odersky can find good things to say about other programming languages :))
- LiveTheDream 15y ago
  Someone described to me recently "Go is to C as Scala is to Java".
  - micrypt 15y ago
    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.
anotherjesse 15y ago
Source and docs at https://github.com/ha/doozerd https://github.com/ha/doozerd and https://github.com/ha/doozer https://github.com/ha/doozer
- MatthewPhillips 15y ago
  Seems to, for the most part, break the Go convention of return an os.Error when something unexpected happens.
comice 15y ago
What was wrong with Apache Zookeeper? No mention of it at all!
- comice 15y ago
  Actually, the blog entry mentions it, just not the article: http://xph.us/2011/04/13/introducing-doozer.html http://xph.us/2011/04/13/introducing-doozer.html
- woodrow 15y ago
  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 http://zookeeper.apache.org/doc/r3.3.3/recipes.html
calloc 15y ago
Here is the actual Doozer introduction by its creator: http://xph.us/2011/04/13/introducing-doozer.html http://xph.us/2011/04/13/introducing-doozer.html
- joshu 15y ago
  is it just me or are the embedded links unclickable?
  - calloc 15y ago
    Definitely not just you. I can't select any of the text either!
deleted 15y ago
[deleted]
stephth 15y ago
Great article. It's barely about Doozer, it ends up being a great piece of journalism about the Go language.
Detrus 15y ago
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.
- uriel 15y ago
  > I wonder, is it possible to do some syntax rewrite to make it look like a weak/dynamic typed language Go already in practice feels very much as light as a weak/dynamic-typed language thanks to (implicit) interfaces, type inference and the plain simplicity of the type system and syntax.
- enneff 15y ago
  > 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 15y ago
> [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!
exDM69 15y ago
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.

96 points by timclark 15y ago

timclark 15y ago

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

JonnieCache 15y ago
Single page version: http://www.theregister.co.uk/2011/05/05/google_go/print.html http://www.theregister.co.uk/2011/05/05/google_go/print.html
enneff 15y ago
Indeed, and the HN title is wrong.

supersillyus 15y ago

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.

icey 15y ago
I think it's much more challenging to find quotes from Martin Odersky where he talks about disliking a language than it is finding quotes where he talks about liking one. Scala is a bit of a kitchen-sink language; there are things in there from all over the place. It makes sense that he can find things to like in many disparate languages. (fwiw: I like Scala, and I like that Martin Odersky can find good things to say about other programming languages :))
LiveTheDream 15y ago
Someone described to me recently "Go is to C as Scala is to Java".
- micrypt 15y ago
  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.

anotherjesse 15y ago

Source and docs at https://github.com/ha/doozerd https://github.com/ha/doozerd and https://github.com/ha/doozer https://github.com/ha/doozer

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

comice 15y ago

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

comice 15y ago
Actually, the blog entry mentions it, just not the article: http://xph.us/2011/04/13/introducing-doozer.html http://xph.us/2011/04/13/introducing-doozer.html
woodrow 15y ago
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 http://zookeeper.apache.org/doc/r3.3.3/recipes.html

calloc 15y ago

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

joshu 15y ago
is it just me or are the embedded links unclickable?
- calloc 15y ago
  Definitely not just you. I can't select any of the text either!

deleted 15y ago

[deleted]

stephth 15y ago

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

Detrus 15y ago

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.

uriel 15y ago
> I wonder, is it possible to do some syntax rewrite to make it look like a weak/dynamic typed language Go already in practice feels very much as light as a weak/dynamic-typed language thanks to (implicit) interfaces, type inference and the plain simplicity of the type system and syntax.
enneff 15y ago
> 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 15y ago

> [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!

exDM69 15y ago

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.