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

11–20 of 46 posts

Re: Concurrency Models: Go vs Erlang

#11

Post by dons »

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…

What's with the "dude" and "totally radical"?

The problem with [Char] for bulk text IO was well acknowledged when I wrote bytestring. To quote:

"The Haskell String type is notoriously inefficient. We introduce a new data type, ByteString, based on lazy lists of byte arrays, combining the speed benefits of strict arrays with lazy evaluation. Equational transformations based on term rewriting are used to deforest intermediate ByteStrings automatically. We describe novel fusion combinators with improved expressivity and performance over previous functional array fusion strategies. A library for ByteStrings is implemented, providing a purely functional interface, and approaches the speed of low-level mutable arrays in C."

Re: Concurrency Models: Go vs Erlang

#12

Post by chongli »

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…

>Haskell world on a couple of those issues ... I want a better Erlang than Erlang

What is your opinion of Cloud Haskell? It is a library which attempts to do exactly that.

Re: Concurrency Models: Go vs Erlang

#14

Post by drdaeman »

alexatkeplar wrote: post #8
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.

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.

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

#15

Post by stonemetal »

douglasisshiny wrote: post #9

I would love to see a comparison between Erlang and Clojure. I do Rails stuff but eventually want to try a functional language in which concurrency isn't an afterthought. I know Erlang achieves concurrency through message passing / message queues, but that's about it. And I have only watched a handful of Rich Hickey talks and have read some introductory material, but I understand that concurrency is achieved through…

It is closer to the Go end of the spectrum. It provides agents, they are an asynchronous message handler kind of similar to a goroutine or an Erlang process. When an agent gets an uncaught exception it caches it, then any subsequent interactions will immediately throw an exception, until the agent's errors are cleared.(http://clojure.org/agents) Which sounds kind of reasonable but I could see it causing problems as you start to see exceptions thrown by code that had no hand in creating the problem and may not know how to fix it.

Re: Concurrency Models: Go vs Erlang

#16

Post by reddit_clone »

douglasisshiny wrote: post #9

I would love to see a comparison between Erlang and Clojure. I do Rails stuff but eventually want to try a functional language in which concurrency isn't an afterthought. I know Erlang achieves concurrency through message passing / message queues, but that's about it. And I have only watched a handful of Rich Hickey talks and have read some introductory material, but I understand that concurrency is achieved through…

The closest thing to Erlang/Otp is (Scala/)Akka. Akka is a library modeled pretty much 1-1 after Erlang/Otp.

As a language Scala supports both functional and imperative programming. I recommend you check it out too.

Re: Concurrency Models: Go vs Erlang

#18

Post by rdtsc »

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…

> Erlang as a language is one of the wisest languages around

It is a truly one of the few industrial, battle hardened functional and concurrent languages. I think languages that came after it and claim to have those features should at least somehow justify how they have improved on what's there.

Now ok, there is a balance. Someone spent time, and effort. Wrote a new language and open sourced it. Should we criticize them? They are giving it away and here we are telling them their work has some big warts and someone already built something similar. Yeah, it is an interesting question, and how heavy the criticism should be....

Re: Concurrency Models: Go vs Erlang

#19

Post by rdtsc »

gordonguthrie wrote: post #4

Few quick points Erlang doesn't have threads - it has processes. Thread's share state, processes don't. The processes are created within the Erlang cluster - they can't be operating system processes because they might be running on a different instance of the operating system. Try and Catch are actually very rare constructs in Erlang - usually only at the boundaries of the system with the rest of the world. In my 10…

> Thread's share state, processes don't.

Not only that they also have separate heaps -- truly concurrent GC is possible without too much "clever" code.

Re: Concurrency Models: Go vs Erlang

#20

Post by jeremyjh »

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 that is less idiomatic. 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.
Post reply on HN