Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Concurrency Models: Go vs Erlang

joneisen.me

Post reply on HN
Print view View original

31–40 of 46 posts

Re: Concurrency Models: Go vs Erlang

#31

Post by camus »

tsewlliw wrote: post #29
davidw wrote: post #7

Earlier quoted context omitted.

> Learn from it, please, I want a better Erlang than Erlang, but talking yourself into how Go is already better than Erlang isn't going to get you there. That's fantastic advice for language advocates everywhere: Rather than pissing on other languages, learn from them, understand what good there is in them, and figure out how to build on that. Sometimes that's difficult: if you're forced to work 10 hours a day with s…

the PHP devs I know really seem to embody a culture obsessed with 'shipping' that I'm not sure can be matched, and I'm really a big fan of it for that, in spite of PHP's huge wackyness.

true. Problem with PHP is that you cant really write backends with it ( I mean stuffs not related to the http interface ) ,like one could do with ruby , python .net or go. That's fine because native solutions exist. But the lack of general purpose of PHP is its greatest weakness.

Re: Concurrency Models: Go vs Erlang

#32

Post by cerales »

derefr wrote: post #28
jerf wrote: post #3

Erlang's error checking model is a great deal more like Go's than he thinks. Erlang is in the "exceptions are exceptional" camp too, and idiomatic code should not be throwing exceptions around willy-nilly. Go is noticably more fragile with errors. Unhandled exceptions (which are just a fact of life unless you're a perfect programmer) will result in the entire program terminating if you don't have something that handl…

> I want a better Erlang than Erlang, but talking yourself into how Go is already better than Erlang isn't going to get you there. I don't mean to go against this point--it's very true, and I think it's important--but I think this conversation (and most comparisons of Go with Erlang) miss something: Erlang is a platform (it has its own VM, and basically its own OS, just relying on the outer OS as a hypervisor.) Meanw…

> Meanwhile, Go isn't a platform, nor is it trying to be. Its designers (Rob Pike and Ken Thompson) already made the platform, first, a long time ago. It was called Unix.

This is great, and I think many of Go's advocates - including devs at Google - underplay it. I don't understand why, particularly given the pedigree of Pike and Thompson.

My approach to building large systems in Go is based around processing pipelines, and tries to be as UNIX-y as possible. The interface types in the io package particularly fit the everything-is-a-file model, where processes can do one thing well while having their inputs and outputs connected to pipes, files, sockets, named sockets, devices, etc.

In short, building complex systems with Go components has made me a better UNIX programmer, a level that I could never quite reach in C due to all the distractions of memory management and unsafety.

Re: Concurrency Models: Go vs Erlang

#33

Post by gordonguthrie »

jeremyjh wrote: post #20

Idiomatic Erlang actually uses multiple return values (in a tuple) in a way that seems similar to Go to me. For example an attempt to open a database connection might return either {ok, Conn} or {error, Reason}. If you have a match for the error then you can handle it right there. If you don't have a match, yes its a runtime exception and OTP will handle it for you. You can also use exceptions for control-flow but th…

> Just because Go doesn't offer you supervision trees doesn't mean they wouldn't be helpful. In fact I'll be surprised if there isn't a decent library for them in a couple of years.

Supervision trees only work because the worker processes they supervise are supervisable. You can't just bolt them on. If you are building things in threads (ie with shared state) then 'supervision' consists of closing them ALL on any error in ONE and restarting. Not so useful

Re: Concurrency Models: Go vs Erlang

#34

Post by microtonal »

genwin wrote: post #25
drdaeman wrote: post #14

Earlier quoted context omitted.

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

In Go, channels can be between boxes, so a channel could be used to trigger or communicate with Go code running on another box.

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

#35

Post by martijn_himself »

cerales wrote: post #32
derefr wrote: post #28

Earlier quoted context omitted.

> I want a better Erlang than Erlang, but talking yourself into how Go is already better than Erlang isn't going to get you there. I don't mean to go against this point--it's very true, and I think it's important--but I think this conversation (and most comparisons of Go with Erlang) miss something: Erlang is a platform (it has its own VM, and basically its own OS, just relying on the outer OS as a hypervisor.) Meanw…

> Meanwhile, Go isn't a platform, nor is it trying to be. Its designers (Rob Pike and Ken Thompson) already made the platform, first, a long time ago. It was called Unix. This is great, and I think many of Go's advocates - including devs at Google - underplay it. I don't understand why, particularly given the pedigree of Pike and Thompson. My approach to building large systems in Go is based around processing pipelin…

I have been playing around with Go on Windows- I really like it (especially the built-in concurrency types) but after reading these comments I feel like I would be better off trying it on UNIX (my mac will do). It probably does not help I am still somewhat lost on UNIX, either, but could you give an example of what a 'processing pipeline' approach would look like? That sounds very much like functional programming to me is that correct? Any advice on tackling UNIX and Go at the same time would be much appreciated!

Re: Concurrency Models: Go vs Erlang

#36

Post by martijn_himself »

jerf wrote: post #3

Erlang's error checking model is a great deal more like Go's than he thinks. Erlang is in the "exceptions are exceptional" camp too, and idiomatic code should not be throwing exceptions around willy-nilly. Go is noticably more fragile with errors. Unhandled exceptions (which are just a fact of life unless you're a perfect programmer) will result in the entire program terminating if you don't have something that handl…

>Unhandled exceptions (which are just a fact of life unless you're a perfect programmer) will result in the entire program terminating if you don't have something that handles it

I am in danger of being downvoted here as I am a bit out of my depth but after reading the go language documentation it seemed to me that go standard libraries are designed to throw exceptions internally but recover gracefully and return an error type to the caller- thus avoiding program termination- I thought that was quite a nice idiom. 'Imperfect' programmers would have to explicitly call panic without recover to cause termination?

Re: Concurrency Models: Go vs Erlang

#37

Post by asabil »

mseepgood wrote: post #30
PixelPusher wrote: post #2

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.

A supervisor is easily implemented in Go: http://code.google.com/p/gosup/source/browse/supervisor/supe...

What happens if one of the children calls panic() ?

Re: Concurrency Models: Go vs Erlang

#38

Post by mseepgood »

asabil wrote: post #37
mseepgood wrote: post #30

Earlier quoted context omitted.

A supervisor is easily implemented in Go: http://code.google.com/p/gosup/source/browse/supervisor/supe...

What happens if one of the children calls panic() ?

A Goroutine can catch any panic() via recover() and then signal bad health to the supervisor.

Re: Concurrency Models: Go vs Erlang

#39

Post by dannywoodz »

> For instance, what if there are a pair of processes that work in unison and one of them dies?

That would depend upon whether the programmer linked them or not. If they're linked, the exception propagates and potentially kills the peer process. If they're nodes in a supervision tree, it's up to the supervisor as to whether to: respawn the dead process; kill the peer and then restart them both; or even to kill the peer and die itself, passing the error up the tree.

It's a matter of resource cleanup and consistency. Not so much what happens if one of the processes dies, but rather what happens if only one of them does?

Re: Concurrency Models: Go vs Erlang

#40

Post by xradionut »

rdtsc wrote: post #21
PixelPusher wrote: post #2

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.

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, h…

You can use Python on top of Erlang.
Post reply on HN