
Go Circuit – Distributed Go Programming Framework - Rooki
http://www.gocircuit.org/
======
paulsmith
<https://github.com/tumblr/gocircuit>

------
vanderZwan
For those who, like me, were looking for a more in-depth _"About"_ page, the
_"Big picture: problems and solutions"_ link under _"Research"_ is what you
want:

<http://www.gocircuit.org/big.html>

(also, to the maintainer: the "Ideal architecture" header at the bottom is on
the wrong column)

------
davidw
Sounds like Go adding more Erlang style features. Off the top of my head, some
nice things that Erlang lacks in that department might include:

* 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.

~~~
dualogy
> Sounds like Go adding more Erlang style features.

Nitpick: this is simply an independent 3rd-party package / external lib for Go
developers. Not a language or runtime feature or addition.

~~~
elviejo
So maybe like erlang's OTP ?

------
RyanZAG
_This application is temporarily over its serving quota. Please try again
later._

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.

~~~
threeseed
When it comes to GAE it really doesn't seem like Google's heart is in it.

Which given their history is a bad, bad sign.

~~~
salimmadjd
I'm guessing like everything else google, it will be shutdown leaving many
developers stranded. We built an entire site around GAE and it was the biggest
mistake of my professional career!

~~~
reeses
You have a great opportunity to start a GAE-compatible service provider! I
imagine a decent percentage of people would migrate just for insurance.

(Yes, I suspect this would be the new biggest mistake of your professional
career. :-))

------
peterwaller
Can someone explain how `Spawn` ships the closure for execution to a remote
host? I'm quite curious to know. I had a grep through the source, but I only
found one [1] implementation of `Spawn` accepting a function as a parameter in
the code base. This hides the true implementation, which I'm struggling to
find. Any hints?

[1]
[https://github.com/tumblr/gocircuit/blob/master/src/circuit/...](https://github.com/tumblr/gocircuit/blob/master/src/circuit/use/circuit/bind.go#L84)

~~~
jbp
<http://www.gocircuit.org/spawn.html>

~~~
peterwaller
I found that earlier - unless I'm missing something, it doesn't actually
explain how the closure is packaged. Does the worker need compiled-in
knowledge of what the master wants to execute in advance, for example? It's
not clear to me.

~~~
jbp
It looks like at this time Spawn doesn't support the closures yet.
<http://www.gocircuit.org/lang.html#worker-functions>: "The need for
boilerplate will be removed in an upcoming Circuit Compiler"

From
[https://github.com/tumblr/gocircuit/blob/master/src/circuit/...](https://github.com/tumblr/gocircuit/blob/master/src/circuit/use/circuit/bind.go#L75):
"The worker function fn, whose type must have previously been registered with
RegisterFunc"

And it looks like only function type id is communicated to worker:
[https://github.com/tumblr/gocircuit/blob/master/src/circuit/...](https://github.com/tumblr/gocircuit/blob/master/src/circuit/sys/lang/func.go#L115)

------
jzelinskie
This looks like tumblr took their hand at making "netchan" (and more). Pretty
interesting; I'll have to check this out. I like how they tried to make it
similar to Erlang. However, the way they've organized the source isn't "go-
get"able which is a pet peeve of mine.

------
GilbertErik
Quick popularity like making it to the front page of HN, Reddit, Slashdot,
etc. can become quite the curse when you're running a small app on App Engine.
Of course, after throwing a few buckets of money down the well, you'll quickly
learn to start optimizing for the platform. I don't know what this framework
does, but it might be useful to link to a static page in the interim and then
have people click through to your app.

~~~
mseepgood
> I don't know what this framework does

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."

~~~
reddit_clone
Though interesting, it brings back up the age old question if this is the
right thing to do? Should an RPC actually look indistinguishable from a local
call?

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'.

