Bill & Ted
Every Google data centre has a full-on robot chubby.
Every Google data center has a Chubby, and Heroku wanted one too. Like the rest of Google's much admired back-end infrastructure, Chubby is decidedly closed source, so Heroku men Keith Rarick and Blake Mizerany built their own. Although they didn't have source code, they did have one of those secret-spilling Google research …
Go is sweet. It's like stackless python but fast and with a lower memory footprint. However there is one thing IME which is wrong with the language: the designers didn't like the way C and company require a ; between each statement, and so they made it optional in Go. The rule is that if a ; could be placed before an end-of-line and things still parse then act as if the ; had been there all along. That makes statements like
x = 10
look nice. But
if (x == 10)
body
is dangerous because the compiler realizes it could put a ; after the ), and does so, with obvious incorrect results.
Yes explicitly putting the {} and making sure the { is on the same line as the if statement works as expected. However the other three common "C" layouts fail: the one I mentioned above, the { on the next line, and the body on the same line as the if. I don't like C-like unless it is really C-like. Somewhat close trips me up.
Go also missed the "indentation is information" boat which python, haskell (and others I don't know--Eiffel I think) got right, IMO. It enforces that the code be pretty. That isn't nice for generated code, but great for humans.
Still despite its faults it's very nice for multi-threaded code, server or otherwise.
Uh? They mention Hoare's CSP in the article, and Pike and pals have done several generations of concurrent programming languages.
He who doesn't read the article properly is doomed to comment on it without understanding the context of certain remarks.
It's a long-winded way of doing Fibonacci but a nice-ish way of demonstrating closures. The fib() function doesn't actually do anything, it returns a function which can be asked to do so something later. a and b act rather like globals and are held in a 'closure' attached to the function object returned by fib(). Each call of this function (which gets assigned to 'f' in the main()) modifies a and b. The double assignment is a trick to calculate both right-hand sides before assigning them to new values of a and b, which gives you a kind of two-element queue, which is what you need for calculating Fibonacci. HTH.
So a and b exist throughout the life of the call "println()"? That would explain
set a = b
set b = a+b
and the next function call actually taking those values into account.
If you run
println( fib(),fib(),f(),f())
instead, you get
0xf84000b040 0xf84000b080 1 2
Two function "addresses" I'd assume...
Try it all out here. http://golang.org/
I've typed it already if you care to copy and paste:
package main
func fib() func() int {
a, b := 0,1
return func() int {
a,b = b, a+b
return b
}
}
func main() {
f := fib()
println( fib(),fib(),f(),f())
}
WTF...because I'm thick :)