Comment by MCRed | Hacker News Reader

Comment by MCRed | Hacker News Reader

Elixir is one of the best ways to program erlang. I learned erlang first, many years ago, and I don't really think of them as different languages. Yes, they have different syntaxes and yes Elixir has added features. But when I'm programming in Elixir I'm using the same part of my brain that loved programming in erlang. I think in the same way.

More importantly, I think, for some reason so many programmers just can't get past erlang's syntax. I've never seen any really good criticisms of erlang that made sense-- other than the syntax. While it was fine for me when I was doing erlang all the time I did spend a couple years away and find it frustrating again. So Elixir fixes that.

Further, there is no other language/platform that does distributed computing correctly, or on such scale, and with such battle testing. Haskell may do it correctly (I'm not sure) but it's very new. Go, Node.js, every "actors" library you can think of, they are single-threaded-thinker's attempts to scale, and they are not correct.

Yes, in computer science there is such a thing as "correct" and "not correct", and way too many young programmers seem to think popularity determines correctness.

IF you haven't learned Elixir and you want to write code that runs on multiple machines without a lot of hassle, and you've seen how tough this is to do on other platforms, head over to http://elixir-lang.org and learn. It's really a delight!

Edit: Fixed some typos. Oops. Want to add, my intention is not to bash languages like Go. Go has some good ideas and is appropriate for certain use cases. It's just frustrating to see these things being pitched as "distributed" when they have not incorporated the lessons learned building erlang over 20 years ago, and the 20+ years of development since.

does distributed computing correctly

Go, Node.js, ever "actors" library you can think of, they are single-threaded-thinker's attempts to scale, and they are not correct

Could you elaborate, or point to a resource comparing the different scaling strategies? What makes the Erlang approach correct?

Check out Seven Concurrency Models from Prag Prog. It does a good job of going over concurrency. It doesn't explicitly go over Node.js or Go's concurrency model, but it talks about the pitfalls of concurrency with shared memory and it also goes over the actor model, which is Erlang/Elixir model as well as Scala's Akka.

https://pragprog.com/book/pb7con/seven-concurrency-models-in...

It really is concurrent and at a fundamental level, eg: it's supported in the VM. The JVM does not support it. It's not a language feature that simulates concurrency and it's not throwing the baby out with the bathwater and just using events (node.js).

The book recommended by the other replyer is probably good. I'd also suggest you check out Joe Armstrongs thesis or his ProgPRog book "Learning Erlang".

There are many necessary things to do things right. It's not a single feature. Erlang the language, the VM, the OTP platform are a collection of all these choices...

I understand and appreciate your enthusiasm and excitement over the Erlang vm, but you really shouldn't misrepresent what's possible with the JVM, the Go VM, or even with Node.js.

All support parallelism as well as concurrency, and all can do so with an actor paradigm (and predictably, Node's support is the weakest).

Erlang's solution is more exciting because it offers a transparent mapping between local and remote code, so long as "transparent mapping" ignores the performance overhead.

The problem is that there is a leaky abstraction of concurrency in Node and Akka. Anytime you want to do some blocking computation or IO, you put the whole application at risk. This even applies to garbage collection. There's a whole class of things that you shouldn't do in that concurrency model. You also have to be sure that none of the libraries you use are doing these things. (zealots will say "don't do blocking IO in Akka!", which missing the point entirely)

Erlang's solution shines (in addition to reasons you cite) because of its efficient scheduler. That's something that you can't have in another language without essentially building Erlang itself.

I'm not too familiar with Scala nor Akka, but know that Akka uses the actor model for concurrency. How does it differ from Erlang/Elixir?

In Akka, multiple actors share a pool of threads. This has a lot of implications:

1. Garbage Collection. Garbage Collection on the JVM is not isolated to actors. One actor causing a lot of memory churn will prompt a garbage collection and prevent all other actors from executing until the Garbage Collector is finished. BEAM (the erlang VM) has per process (aka per actor) garbage collection, so actors will not interfere with each other during garbage collection.

2. Shared Memory. Since the JVM does not provide proper isolation guarantees, actors can in fact access shared memory. Safety in concurrency is accomplished via best practices rather than guaranteed by the VM. The BEAM VM does not allow shared memory. It is impossible for two processes to write to the same memory. While this matches the convention in Akka, it is enforced at the VM level.

3. Scheduler. In Akka, actors are oversubscribed to threads. That's why you can have hundreds of thousands of actors on a single system. The abstraction is great, but the implementation means that calling Thread.sleep is going to tie up a thread. If you do that often enough then all the threads will get tied up and the rest of the actors will be unable to make progress. The BEAM VM handles this scheduling at a much lower level. Calling sleep on an Erlang process is no big deal. While sleep is a contrived example, the effect on the ecosystem is pretty big. Using a blocking HTTP client on Akka is a bad idea. You have to use something like Dispatch or Spray which is essentially callback based (via monadic Futures). In Erlang, you just make the blocking call and the scheduler takes care of it. Since the synchronous code is easier to reason about than asynchronous code, the Erlang solution is simpler, easier to maintain and often more performant.

I've spoken with a number of seasoned Scala/Java programmers who basically tell me "Of course you shouldn't do that, just do X or Y". With Erlang, I find there are fewer situations where you need to be an expert to avoid screwing things up.

3 is true because Actors are implemented on top of a language and runtime that hasn't decided to implement actors and ONLY actors. Just like Haskell, you can in fact mix paradigms of concurrency. This is generally regarded to be a positive thing! But of course it does mean you need to understand how the semantics interact.

But it's weird to call out actors oversubscribing to threads in Akka as a bad thing when that's exactly what Erlang's runtime does! And by the way, it's not difficult for even C to match the classic "quarter million execution threads" claim. Java certainly can with competitive memory overheads.

The problem with Akka oversubscribing is that it doesn't actually have control over execution. It can't pause an actor in order to guarantee fair scheduling. It's similar to Node and the event loop in that regard. That's a big deal in my book.

Competitive memory overhead in the Erlang world for a quarter million processes is 700MB (just sleeping). You can't do that with POSIX threads, where the default pthreads stack size on Linux is 2MB. Java adds more overhead on top of POSIX threads. As far as tuning PTHREAD_STACK_MIN on x86 is generally 16K, which is quite a bit bigger. So either you aren't in the same ballpark (factor of >5) or you have basically built a scheduler yourself (which is what Akka did).

> The problem with Akka oversubscribing is that it doesn't actually have control over execution. It can't pause an actor in order to guarantee fair scheduling. It's similar to Node and the event loop in that regard. That's a big deal in my book.

I mean it can if you use their libraries. You just suggest that because calling out to a different I/O library is possible that we should only evaluate it in that context. This is basically a condemnation of ALL languages that host multiple abstractions.

> or you have basically built a scheduler yourself (which is what Akka did).

Riiiiiiight.. so... what's the problem there? Someone did what the erlang folks did on the JVM. Why is that used as a refutation here?

> As far as tuning PTHREAD_STACK_MIN on x86 is generally 16K, which is quite a bit bigger. So either you aren't in the same ballpark (factor of >5)

My comment was in regards to building a scheduler yourself (erlang doesn't have that many threads of parallel execution either) or using a technique with less demanding semantics like Fork-Join.

A lot of people have mixed up a lot of concepts here in the attempt to discuss why they like Erlang, but the truth is that it can't be nearly so efficient at scheduling and executing parallel computation as the average Java program appealing to java.util.concurrent, but is tuned for greater concurrency. It's also true that for some classes of computation Erlang's strategy works great, and for others it'd require substantial engine improvements to make competitive.

The impression given on this thread is that Elixir is the answer. I don't like that impression being left for people new to the discipline, because it's not how most people who are good at distributed systems or massively parallel AND concurrent programming think about the problem.

By not having preemptive scheduling, there are a whole lot of hoops that have to be jumped through. Spray.io is a disaster in usability in my opinion, for example. I've yet to find my code simpler and easier to maintain and debug when I use callback based async techniques. That is, however my opinion and personal taste. Others may disagree.

You won't find me carrying a lot of water for any Node library.

I just think it's not wise to try and represent the use cases that actor based excels at as primary for our industry or even somehow privileged.

The difference is the scheduling. In erlang, processes are preemptively scheduled, in akka they aren't. Erlang goes to great lengths to avoid one process from starving another. With akka you have to go to some lengths yourself to prevent starvation (e.g. preventing blocking calls in your event handlers).

> Anytime you want to do some blocking computation or IO, you put the whole application at risk.

It is true that you should not do this, and it's a fair point. Of course, you don't do it with Erlang either! Erlang carefully takes all file I/O out of their actor model and has it so that one (and only one) process can interact with a file handle. Operations to this have to be serialized by the actor. Since there is only one implementation of I/O and it's non-blocking, this works fine, but if your application is an actor pipeline you run exactly the same risk as your mailbox overflows. Needham's Duality is real.

And naturally that ignores the fact that JVM concurrency and parallelism can handle that outcome perfectly well (and in fact Akka appeals to these primitives). It's absurd to suggest that java.util.concurrent doesn't have great tools for parallel anything, let alone parallel I/O.

Golang, by the way, doesn't have this restriction. The runtime supports non-blocking, parallel-friendly I/O from the ground up.

And as for Node.js, well the general abstraction here is the most parallel of all. I'm not a huge fan of it and I agree it's a bit leaky, but Node's cluster stuff is serviceable and used by many. You cannot argue the actor model is essential, threadpools and actors ultimately model the same process and as Go has shown can do so with similar sharing semantics.

Finally, Erlang's scheduler is not black magic nor an arcane work of wisdom. It uses well-known, well documented principles and techniques. Quite frankly, its not the secret sauce of Erlang. Erlang's secret sauce is the HUGE some of very good code for building a distributed system with all the robust goodness that OTP provides.

Erlang's great, Elixir is interesting (albeit it took one stinky old syntax and exchanged it for another stinky syntax). I wanted to reply to that prior post and talk to why Erlang has a magical recipe for distributed code, not parallel code. Quite frankly, Erlang's parallelism story only makes sense in the context of its decision to make remote and local execution indistinguishable at the call site.

In the context of sharing IO, Erlang does have the same problems. I was however referring to IO in the sense of "I'm going to block until I get a response." And not have to deal with callback shenanigans (be it futures or callbacks). Golang does solve these issues fairly well except for GC issues (which I've heard have gotten better).

> I was however referring to IO in the sense of "I'm going to block until I get a response." And not have to deal with callback shenanigans (be it futures or callbacks).

Callbacks and futures are very different modeling techniques and I'm not sure why you'd suggest they're inherently inferior. They have their uses just like the Actor model.

People obsess on the existence of blocking I/O (proponents of Node.js do this too) and I find it strange that this is still a subject of conversation. It's by and large a solved problem.

> Golang does solve these issues fairly well except for GC issues (which I've heard have gotten better).

Golang's GC issues were no to much about GOMAXPROCs as just needing a really good optimization pass. As a younger language, it's unsurprising it needs some time to reach production readiness. Erlang has the benefit of many years of testing in anger.

> ou really shouldn't misrepresent what's possible with the JVM, the Go VM, or even with Node.js.

He's not saying it isn't possible. Everything is possible with assembly, it doesn't mean assembly is a good choice for distributed programming.

> and all can do so with an actor paradigm (and predictably, Node's support is the weakest).

There-in lies the problem. The main benefit of actor programming programming is about programming with isolated actors. Such that one actor doesn't see the heap or memory of another one. Because at a large enough scale fault tollerance start to become more important than other things. If a single goroutine panics and takes down other 100K connections, it doesn't matter that it is lighting fast or cool or whatever, it will be broken.

In other words langauge that claim "Erlang-like concurrency" never get is right. They put a queue and a thread together in a class and call it "Erlang". But that is not Erlang. The closest thing to Erlang's model is probablh the operating system with its processes.

It even makes sense to think of your code in that way -- your langauge platform is an OS for your code. If you write in Erlang or Elixir you are writting on a modern sane OS like Linux, Windows, OS X. If you are running with pthreads or goroutines, you are back to Windows 3.1.

> In other words langauge that claim "Erlang-like concurrency" never get is right. They put a queue and a thread together in a class and call it "Erlang". But that is not Erlang. The closest thing to Erlang's model is probablh the operating system with its processes.

That's not really right.

> It even makes sense to think of your code in that way -- your langauge platform is an OS for your code. If you write in Erlang or Elixir you are writting on a modern sane OS like Linux, Windows, OS X. If you are running with pthreads or goroutines, you are back to Windows 3.1.

That's not true at all. I have no idea why you'd try and use such an emotionally loaded argument. Just earlier in your post you made a point that different tools have different sweet spots.

The Actor model is useful for some things, but not all. There are many effective techniques for parallel computation that do not rely on the actor model. There are several ways to model distributed computation that are not the actor model.

My principle objection to this entire thread is that people are making a mistake ignoring these other techniques and in fact directly misrepresenting the state of the art for the sake of their rhetoric about Erlang. By and large, the Erlang community itself tries not to do this!

Haskell is 'very new'?

Have any of the popular Haskell libraries for building distributed systems seen high-scale production use for more than 5 years?

Haskell's not new compared to Elixir which got it's 1.0 release last summer. It is new compared to erlang which has been around longer than the startup CEO in silicon valley has been alive. :-)

Also "new" is one of those things that I think changes perspective with age. Probably when you're younger newer things seem more established than when you're older and looking at a longer time horizon. No offense meant to haskell. :-)

I don't really know how to compare these things since I don't think Haskell was really very useful at it's 1.0 release, but Haskell 1.0 came out in 1990, 4 years after Erlang, they're both pretty old.

Reply on news.ycombinator.com