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

191–200 of 210 posts

Re: Why Erlang Matters

#191

Post by atemerev »

amelius wrote: post #177
atemerev wrote: post #175

Earlier quoted context omitted.

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?

The API only defines a way to start a new actor remotely.

Now, each actor per actor model convention has to survive restarts. In distributed environment, the state can be persisted e.g. in distributed memory cache / storage (Hazelcast, Cassandra).

Re: Why Erlang Matters

#192

Post by querulous »

ssmoot wrote: post #178
coldtea wrote: post #137

Earlier quoted context omitted.

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

it doesn't, but an erlang process that is waiting on a message won't block other processes from running ever

Re: Why Erlang Matters

#193

Post by crazydoggers »

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…

I'd like to mention Celluloid here as well. Generally I prefer Erlang/Elixir, but in Ruby centered apps, Celluloid (especially run under the JVM with JRuby) solves a lot of concurrency problems easily.

> All other major implementations (including Akka) have cooperative scheduling, i.e. forbidding blocking code in actors. Erlang allows it.

Curious as to what people's thoughts on Celluloid:IO are with respect to solving the problem of blocking code in actors. Celluloid:IO provides an event driven reactor that works in parallel with the actors. I haven't used it myself, but it seems an interesting approach.

Re: Why Erlang Matters

#194

Post by igouy »

adrusi wrote: post #59
jandrese wrote: post #2

I'm a very green Erlang noob, but given what I have seen from it I find articles like this kind of strange. Sure concurrent programming is difficult and we need to think hard about how to make programs run quickly in a multiprocessor environment, but the fundamental architecture of Erlang seems to be in conflict with big data and high speed computing. It seems like a language that can scale much better, but has such…

I think you might be underestimating Erlang's performance. Running on the same single machine, Erlang's perfomance is comparable to python on benchmarks [1] [2]. Its performance obstacles aren't really that different from scheme's, and Racket does a little better than Erlang on benchmarks, so there's definitely room for improvement [3]. But Erlang isn't really for doing computation, it's for communication. If you hav…

Also

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

Re: Why Erlang Matters

#195

Post by BuckRogers »

incepted wrote: post #105
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…

> And actor supervision is the best way to write reliable systems. Need some citation there, because we've been writing extremely reliable systems (multiple nines) for decades in various languages (mostly C, C++ and Java). All these languages (including Erlang) come with pros and cons to write such systems, but so far, Erlang has failed to deliver on most of the promises that its advocates repeatedly make.

Facebook, Whatsapp, almost every phone call you make for decades, and much of the backend for League of Legends were all built on Erlang.

Not that the others are unsuccessful from an engineering or financial standpoint, but the last one, Riot Games' League of Legends recently hit 1 billion in revenue. It's a fact that it's the most popular video game on Earth today.

If it didn't work or "failed to deliver on its promises"- none of these world-class, top-tier services would be where they are. To repeat myself so it sinks in. Yes. It is a fact that every phone call you make hits Erlang code somewhere.

Because people actually stand in the face of Erlang and spout this nonsense to this day... I'll take the claim one step further and will back it up if challenged as if it's not already self-evident.

Erlang has proven itself better, for a longer period of time than Java. Many have tried to replace Java. No one, and I mean no one has tried nor has anyone succeeded in replacing Erlang.

Only C rivals it for carrying the world on its shoulders.

Re: Why Erlang Matters

#196

Post by strmpnk »

atemerev wrote: post #174
strmpnk wrote: post #86

Earlier quoted context omitted.

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!

This assumes failure is clean. Some failures are tougher, for example, imagine code going into an infinite loop. It either system, you have waste but the scale of the disruption in Erlang is kept isolated where Akka would fail to release the thread. Otherwise, I'd definitely agree that Akka handles vanilla failures just fine by using supervision trees.

Re: Why Erlang Matters

#197

Post by roller »

e_proxus wrote: post #168
jerf wrote: post #91

Earlier quoted context omitted.

Live reload is a funny thing with Erlang. When I claim it's a feature, but describe the pain it is to use, I get told nearly nobody uses it. When I claim that nobody uses it, I get told that lots of people use it. I'm not sure it's something that an Erlang competitor would have to get right. And it would be valid to use a different mechanism for live reloads, perhaps something that explicitly migrates state between O…

I think you are seeing two definitions of "live reload". One is where you live upgrade a full running release, including all applications and version, where you mutate state that had its format changed. All this in production, without any downtime. This is incredibly hard to get right. Erlang gives you a lot of tools (OTP & friends) to achieve this, but it is still very complex. The other is reloading Erlang code in…

I haven't seen it used directly, but it seems like Elixir macro based code could be altered and recompiled based on runtime configuration.

An example would be changing log level settings. Normally Elixir log blocks can be compiled entirely out when running in production mode. But it should be possible to fairly safely recompile with debug logs enabled and reload without missing a beat.

Re: Why Erlang Matters

#198

Post by wcummings »

arh68 wrote: post #77
wcummings wrote: post #37

Earlier quoted context omitted.

You could write NIFs in Rust (well not sure if you can now, but I don't see any reason it couldn't be supported) for the high perf bits and use Erlang to coordinate, I figure. At least Rust code is less likely to explode and bring down the whole VM than C.

Any idea if a network-level FFI has been started? I'm thinking along the lines of the Haskell erlang-ffi [0]. Speaks the Erlang network protocol and impersonates an Erlang node on the network. Fully capable of bi-directional communication with Erlang. NIFs still limit you to [0] https://hackage.haskell.org/package/erlang

There's support for "dirty NIFs" in new versions, R19 will make it the default. Dirty NIFs allow for long running NIFs managed by the VM. In older versions, you can use nif_create_thread to create background workers, and your NIF will only block for as long as it takes to acquire a lock for your queue.

You can also use c nodes (or the JVM interface, which is pretty similar to c nodes I think).

... You can also use ports which define an interface for communicating with external processes.

The world is your oyster!

Re: Why Erlang Matters

#199

Post by coldtea »

ssmoot wrote: post #178
coldtea wrote: post #137

Earlier quoted context omitted.

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

The magic is called "preemptive multitasking".

Re: Why Erlang Matters

#200

Post by jrobn »

pmontra wrote: post #148
jrobn wrote: post #100

Earlier quoted context omitted.

There is Pony ( http://www.ponylang.org ).

Interesting language, thanks. What's the amount of adoption to date?

Close to 0%. It's still in development. I would love to see this development into a high performance alternative / complement to erlang.
Post reply on HN