Seems to be running on AppEngine by the look of it. AppEngine has the limits far too low for basic stuff like this, they should really re-look at their service offering if they want to actually compete in the market.
Which given their history is a bad, bad sign.
Google has a similar possibility here - they can really take over the webapp hosting environment and create massive ease of use and integration for their various web platforms and APIs by making it easy to integrate them into AppEngine. The requirement for this is massive adoption, and the requirement for massive adoption is, at the very least, providing similar cost/performance as a random dedicated host. AppEngine/Google compute engine are barely competitive with other very expensive, high margin services such as AWS. Google is missing out massively here because they want to squeeze out traffic penalties with a terrible business model that gives users across the web a nice error message.
They've at least had the sense to be guilty enough to remove their branding from the error page though.
[1] https://github.com/tumblr/gocircuit/blob/master/src/circuit/...
* A bit more security by default. Erlang was built for something where they presumed they were walled off from bad stuff.
* Some kind of routing mechanism, so that you could have A connected to B, and B connected to C, and the system would be able to send messages from A to C. I have no idea if this is actually a good idea, as this is not the sort of thing I use Erlang for myself. But it seems like it might be cool.
Excerpt from my browser cache:
"The circuit extends the reach of Go's linguistic environment to multi-host/multi-process applications. In simple terms, the Go Circuit was born from the desire to be able to write:
feedback := make(chan int)
circuit.Spawn("host25.datacenter.net", func() {
feedback <- 1
})
<-feedback
println("Roundtrip complete.")
The Spawn operator will start its argument function on a desired remote host in a new goroutine, while making it possible to communicate between the parent and child goroutines using the same Go code that you would use to communicate between traditional goroutines. Above, the channel feedback is transparently “stretched” between the parent goroutine, executing locally, and the child goroutine, executing remotely and hosting the anonymous function execution."I have heard arguments from both sides starting from the days of CORBA and DCOM. But never had a convincing answer either way. It usually boils down to 'depends on use case'.
http://www.gocircuit.org/big.html
(also, to the maintainer: the "Ideal architecture" header at the bottom is on the wrong column)