News for hackers. Stuff that matters.
Re:Concurrency Models: Go vs Erlang by PixelPusher on Wednesday March 27, 2013 @04:44PM (#5451908)
I haven't used Go yet, but love Erlang.

Honestly can't imagine a better way to build fault tolerant applications without the help of a supervision tree, errors that bubble up, and fast process restarts.

Would love to try out Scala or Go though, but Erlang has served me well so far. Not sure what they offer that's similar to OTP.

Re:Concurrency Models: Go vs Erlang by alexatkeplar on Wednesday March 27, 2013 @05:10PM (#5452036)
Check out Akka for Scala/Java - http://akka.io/

I am genuinely puzzled why people embark on building systems which they intend to be massively scalable using languages which don't have a technology like Erlang/OTP or Akka to support distribution across multiple boxes.

Re:Concurrency Models: Go vs Erlang by drdaeman on Wednesday March 27, 2013 @06:52PM (#5452484)
This.

The fact that, as opposed to to Goroutines, Erlang processes can be transparently running on some other node is the most important difference.

Re:Concurrency Models: Go vs Erlang by genwin on Thursday March 28, 2013 @12:09AM (#5453308)
In Go, channels can be between boxes, so a channel could be used to trigger or communicate with Go code running on another box.
Re:Concurrency Models: Go vs Erlang by danieldk on Thursday March 28, 2013 @04:23AM (#5453774)
Oh, could you please show me some code that does this (a 'channel between boxes'), and supports sending of exactly the same data types that you send over a regular Go channel?

Using the old deprecated netchan package doesn't count ;).

Re:Concurrency Models: Go vs Erlang by granitepail on Thursday March 28, 2013 @01:25PM (#5456256)
There's gob ( http://golang.org/pkg/encoding/gob/ ). Not going to claim it's on the level of node communication in Erlang, but it does make data (de)serializaiton incredibly simple. With only a few lines of code you could have a channel reading from and writing to a socket to another machine.
Re:Concurrency Models: Go vs Erlang by genwin on Thursday March 28, 2013 @10:22AM (#5454883)
I haven't done it myself. The idea is from the book The Go Programming Language Phrasebook. I've misplaced the book, but this link shows it's probably netchan: https://groups.google.com/forum/?fromgroups=#!topic/golang-n...
Re:Concurrency Models: Go vs Erlang by shinolajla1234 on Wednesday March 27, 2013 @10:09PM (#5453056)
Akka does that as well, and you're right, it's very important for writing declarative, distributed logic. Akka's ActorRef abstracts over the physical location of the actor, just as Erlang's PIDs do.
Re:Concurrency Models: Go vs Erlang by drdaeman on Thursday March 28, 2013 @08:54AM (#5454472)
So does Cloud Haskell (which borrows and improves on many ideas from Erlang/OTP).

http://haskell-distributed.github.com/documentation.html

Re:Concurrency Models: Go vs Erlang by rdtsc on Wednesday March 27, 2013 @08:55PM (#5452856)
There is nothing like the pleasure of using the right tool for the right job.

Using C++, Java or even Python for highly concurrent and fault tolerant systems is a bit like hammering screws into the wall. It can be done with enough effort -- but try a screw driver drill and see what a difference it makes.

The secret sauce is all about fault tolerance, everything else amazingly and logically leads from it: isolation, hot code reloading, distribution (running nodes on multiple machines)

Re:Concurrency Models: Go vs Erlang by xradionut on Thursday March 28, 2013 @08:28AM (#5454379)
You can use Python on top of Erlang.
Re:Concurrency Models: Go vs Erlang by mseepgood on Thursday March 28, 2013 @02:24AM (#5453562)
A supervisor is easily implemented in Go: http://code.google.com/p/gosup/source/browse/supervisor/supe...
Re:Concurrency Models: Go vs Erlang by asabil on Thursday March 28, 2013 @05:55AM (#5453993)
What happens if one of the children calls panic() ?
Re:Concurrency Models: Go vs Erlang by mseepgood on Thursday March 28, 2013 @06:20AM (#5454052)
A Goroutine can catch any panic() via recover() and then signal bad health to the supervisor.