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

Why Erlang Matters

sameroom.io

Post reply on HN
Print view View original

171–180 of 210 posts

Re: Why Erlang Matters

#171

Post by jeremyjh »

logicchains wrote: post #124
jeremyjh wrote: post #84

Earlier quoted context omitted.

There is one other. Haskell has green threads, a preemptive scheduler, and it has a pretty decent implementation of Erlang-inspired multi-node concurrency primitives and higher-level framework including supervisors, gen_server equivalent etc in the Cloud Haskell project. It does NOT have Erlangs deployment base and track record but it is still a very promising framework and very appealing if you like Haskell's type s…

Just a nitpick, but Haskell's scheduler (like Go's) is "less preemptive" than Erlang's. If you have e.g. i = 0 for{ i += 1 } or equivalent in Go/Haskell, then the HS thread/goroutine running it cannot be interrupted, as interruption can only take place at certain points (e.g. allocation or function calls). Erlang on the other hand assigns a certain amount of time units to each process, and each pure-Erlang operation…

Haskell's scheduler preempts on memory allocation. Memory allocation is ubiquitous in Haskell; the example you are giving cannot really be written in Haskell as values are immutable. You could try to do something with IORef and bang patterns to avoid thunks being allocated but you are now in a very tiny corner case, much smaller than the surface area of NIFs that can cause you problems in both Erlang and Haskell.

Re: Why Erlang Matters

#172

Post by amelius »

One missing feature is that you cannot run the same code in the browser and on the server (which is very useful).

Is there a language that compiles to both Erlang and Javascript?

Re: Why Erlang Matters

#173

Post by dschiptsov »

There is Armstrong's thesis (google it) which explained all the major design decisions much nicer that this arrogant "Erlang matters".

The foundation principles is not only in selecting a functional language and enforce immutability, but explicitly rejecting all sharing (threads in the first place) and providing a theoretical basis of why JVM is an unacceptable target for reliable, soft-realtime systems, (no matter what Scala guys might tell you) - a crashed process would affect none other, no data corruption, no locks, no messed up stack. This is what is behind the "let it crash" meme.

Erlang is not "matters", it is a masterpiece of software engineering to study and learn insights from. Especially, how to make ones own decisions based on right principles and rejecting sectarian dogmas (run everywhere!) of wast majority.

Re: Why Erlang Matters

#174

Post by atemerev »

strmpnk wrote: post #86
findjashua wrote: post #57

Earlier quoted context omitted.

preemptive. Cooperative scheduling runs the risk that a long-running actor might starve the other actors

Exactly. In terms of fault tolerance, a buggy actor is isolated in regards to scheduling others. Bad behavior has a more limited scope. This isn't to say that one can't create a process that eventually has harmful consequences to the entire system, it just means it's much less likely. These little points of isolation add up. Scheduling, memory management, lifecycle, crashes, &c... It's why it's a bit funny when I hea…

Akka is quite good in terms of reliability (I developed in both Akka and Erlang). All actors in Akka are supervised by default, and restarted if any exception happens.

This allows skipping most of error handling in Akka code. If something's wrong, your actor will be restarted. Works great!

Re: Why Erlang Matters

#175

Post by atemerev »

amelius wrote: post #163
atemerev wrote: post #47

AFAIK, Erlang is still (as of 2016) the only distributed actor model implementation with preemptive scheduler. All other major implementations (including Akka) have cooperative scheduling, i.e. forbidding blocking code in actors. Erlang allows it. This is huge. And actor supervision is the best way to write reliable systems. I have wrote some code in Akka without much effort and testing (streaming market data aggrega…

> AFAIK, Erlang is still (as of 2016) the only distributed actor model implementation with preemptive scheduler. It is one of the open issues with Golang. https://github.com/golang/go/issues/11462 User aclements notes: > @GoranP, you can think of the Go scheduler as being partially preemptive. It's by no means fully cooperative, since user code generally has no control over scheduling points, but it's also not able t…

And goroutines are not distributed, while actors can be transparently deployed across remote physical nodes, both in Akka and Erlang.

Re: Why Erlang Matters

#176

Post by eggy »

Jtsummers wrote: post #61
pmontra wrote: post #51

Earlier quoted context omitted.

He probably means that an Erlang process is equivalent to an object and message passing among processes is equivalent to method calls. In my experience with Elixir, objects, method calls and mutable data are easier to write than processes, messages and immutable data. It's not the mutable and immutable part, it's more about the boiler plate of spawning processes, receiving messages and matching them to dispatch them…

Yes. In the same sense that closures and objects are equivalent. http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent

Or use LFE - Lisp Flavoured Erlang by one of the designers of Erlang, Robert Virding. All the BEAM/OTP goodness with the meta-programming and homoiconicity of Lisp. Worth checking out.

Re: Why Erlang Matters

#177

Post by amelius »

atemerev wrote: post #175
amelius wrote: post #163

Earlier quoted context omitted.

> AFAIK, Erlang is still (as of 2016) the only distributed actor model implementation with preemptive scheduler. It is one of the open issues with Golang. https://github.com/golang/go/issues/11462 User aclements notes: > @GoranP, you can think of the Go scheduler as being partially preemptive. It's by no means fully cooperative, since user code generally has no control over scheduling points, but it's also not able t…

And goroutines are not distributed, while actors can be transparently deployed across remote physical nodes, both in Akka and Erlang.

How does this work with state? Isn't it inefficient to transfer the state of the actor to another node compared to just letting the actor run on the same machine?

Re: Why Erlang Matters

#178

Post by ssmoot »

coldtea wrote: post #137
ssmoot wrote: post #102

Earlier quoted context omitted.

You've done something wrong then? Or maybe using experimental features? I might play with them a bit, and it can be frustrating to wait, but I've never launched anything on -experimental before. I was referring to "cheating", with the idea that you might pollute your Actors with... I dunno. Programmatic connection pooling for your database driver? Passing mutable messages around? Both of those things would be very un…

> You've done something wrong then? Well, the idea is with Erlang you can't.

I don't believe Erlang goes around magically imposing it's own timeouts on message handling.

Re: Why Erlang Matters

#180

Post by [deleted] »

atemerev wrote: post #47

AFAIK, Erlang is still (as of 2016) the only distributed actor model implementation with preemptive scheduler. All other major implementations (including Akka) have cooperative scheduling, i.e. forbidding blocking code in actors. Erlang allows it. This is huge. And actor supervision is the best way to write reliable systems. I have wrote some code in Akka without much effort and testing (streaming market data aggrega…

[deleted]
Post reply on HN