36 ms·

Why Erlang Matters

423 points by _oakland 10y ago

jandrese 10y ago
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 enormous constant time penalties that the scaling can't overcome the hurdle until you're talking about thousands of processors. Every single state change requires a function call, every function call involves a pattern matching algorithm that has to account for all of your program arguments (effectively almost the entire state of your thread!) and isn't even strongly typed. And then there is synchronization and data sharing between threads, which seems a bit handwavy and effectively requires a database running in your program that the threads can poll. If your problem set is lots and lots of small independent tasks that don't have to finish overly quickly, then Erlang is fantastic. Stuff like switching voice circuits for example. But I'm trying to imagine manipulating a 1TB dataset with thousands of worker threads if you have to make a copy on the stack for every change every worker makes. I know people do some big data stuff with Erlang, so these have to be solved problems somehow, but I can't help but to suspect that they have to compromise some of the ideals espoused in this article to make it work.
- elihu 10y ago
  For years, I didn't see what the point of Erlang was. It might scale well, but if it takes an Erlang process running on a hundred processors to equal the performance of a single-threaded C application, what's the point? When I learned a bit more about Erlang, I realized that the point is that there are a lot of applications that are IO bound rather than computation bound, and for those apps Erlang performs very well and is easy to program in. Crunching numbers the fastest isn't always the most important thing.
  - rdtsc 10y ago
    One of the main points of Erlang is fault tolerance. Everyone forgets about that and talks actors and scalability, which is fine. But without fault tolerance and proceses with isolated heaps it doesn't matter how fast the C code is, it can process millions of transaction a second, and then segfault, and the availability and transaction rate goes to 0 on that node. The other advantage is power of abstraction. With Erlang it is easy to describe and program distributed system with lots concurrent components. Sure you can do it with C++, Java, and Node.js etc, but those things are awkward there -- either threads share memory and have to deal mutexes, or you in are in callback/promise hell.
- actsasbuffoon 10y ago
  Erlang excels at high throughput and fault tolerance. Number crunching, even in parallel, isn't really the goal.
- jerf 10y ago
  Erlang may be useful for coordinating computation tasks, but, yes, even with HIPE it is not a good numerical language on its own. It would be interest to re-engineer a language today that tries to fit into Erlang's niche but has a stronger performance focus. Rust, Cloud Haskell, and Go all sort of cluster in the area I'm thinking about, but none are quite what I'm thinking of. Cloud Haskell is probably closest but writing high-performing Haskell can be harder than you'd like. Rust shows you don't have to clone Erlang's immutability and all the associated issues it brings with it for inter-process safety, but Rust of course is "just" a standard programming language next to what Erlang brings for multi-node communication.
  - aaron-lebo 10y ago
    This is an easily solved problem. You've been around so what I'm about to tell you is nothing new, but... In the aughts Ruby and Python were really slow so if you had computational-heavy problems you had to drop into C. It worked but C isn't great. The thing is - we have a lot of languages that can do computational problems easily now - Rust, Go, Nim, and the list goes on.... It becomes relatively trivial to create libraries which could wrap these languages for Erlang/Elixir. In the few cases where Elixir isn't fast enough, just drop down to something else. Write a small piece of code in Rust (you may as well call Elixir/Rust peanut butter and jelly). Optionally, you could create some kind of DSL which compiles down to another language in Elixir. I did the same with xjs (Elixir syntax, Javascript semantics) [0], and I must say, for a 200-line hack it works really well. This isn't even considering the fact that a lot more work could be invested in Erlang's VM. Yes, Ericsson is its corporate sponsor but imagine if you had companies trying to make it fast the way they try with Ruby, Python, JS, or another of other more complicated languages. I think this is relatively low-hanging fruit. You can't tell me that Erlang and Elixir are harder to make fast than other dynamic languages (in most contexts). [0] https://news.ycombinator.com/item?id=11444499 https://news.ycombinator.com/item?id=11444499
    - eggy 10y ago
      The drive for fault-tolerance, distributed computing and on the other hand, speed, are all becoming prominent leaving Erlang in a good place right now, but in need of other major changes in the computing world. Wrapping languages or 'dropping down to C' is no longer going to cut it, even if it is low-hanging fruit. Rust or Pony's guarantees only hold if you stay in their pen. We need a way of marrying PLs like Erlang/LFE/Elixr and Pony to newer hardware paradigms to take advantage of all those multicores, and potentially custom FPGA vs. ASIC chips rigs that will be arriving to market. Why Erlang matters is that it showed you can allow for failure, albeit brief and inconsequential failure, to succeed. No zero-risk or failure here. Acceptable bounds that are easy to see now, but revolutionary at the time. Custom hardware is already in use at HFT and bitcoin mining companies. The U.S. is going to try and beat China's Tianhe-2, that is currently the world's fastest supercomputer. I'm not sure why, since the Chinese scientists say it would take a decade of programming to utilize the potential of the Tianhe-2's hardware. If you think I'm calling the spirit of Lisp Machines from the dead, you're close ;) I think the von Neumann HW architecture, and its straddled type of OS, are straining at the edges of high-stakes usage, not the common user. We don't need supercomputers, we need new hardware architectures at a lower-level than 'super', that can be programmed in months not decades. Programming languages in the OTP/BEAM category, old, battle-tested languages like APL and J, which have always dealt with the array as their unit of computation, will be the basis for new languages, or they will be adapted in an new one. The money, big data, and mission-critical business needs will drive it to market.
- Jtsummers 10y ago
  > even strongly typed. A nit: Erlang is strongly typed. You cannot (ok, excluding numbers) almost transparently convert a string into a number into a tuple like you could in C, to which everything is merely memory so casting allows trivial but potentially erroneous conversions. Erlang is dynamically typed, not statically typed. Dialyzer + type annotations (and some inferred) allows for static analysis, but it's not directly part of the compiler so it can't be strictly enforced (automatically). EDIT: Also, consider that erlang processes are a dual of objects in the OO sense. They can receive various messages and respond by changing state and/or transmitting messages. This interaction is similar to the way objects (instances of classes) behave in OO languages. The difference being that they're all running concurrently. So you could put a massive amount of state into one process. OR you could have a handful of processes that act together like you have a handful of classes in an OO language. If I write a server for playing a game, I don't include all of a player's state and their connection in one process. I have a process that handles the network connection. It sends messages to a process (or processes) that handle player state. Which connect to some game state processes, and on until the network handler sends messages back to the player or gets more messages from the player.
  - jandrese 10y ago
    You've hit on the tradeoff though. By decentralizing your state, you've increased your inter-process synchronization requirements. In the worst case everything ends up being tightly bound and your application runs like a single threaded application because everything is always blocked waiting for the state update from a remote thread. Huge parallelism is easy if your data and processes are largely independent, but the real world is rarely so kind.
    - catnaroek 10y ago
      > In the worst case everything ends up being tightly bound (...) Your tradeoff is between “tightly bound by shared data structures” vs. “tightly bound by process synchronization”. I don't see how either is better than the other. > the real world is rarely so kind In the real world, from what I've seen, while everything is interconnected to everything else, not all the connections are equally strong or important. If you want to compute exact results, without possibility of failure, no matter what the computational cost, then sure, you need to take all the connections into account. If you can trade some accuracy for performance gains in the average case, you'll probably want to find ways to prevent minor failures from bringing down the entire system.
- runchberries 10y ago
  I don't see why it is confusing that applications for high concurrency would solve problems differently than big data. I am also an Erlang noob, but I don't think pattern matching has to account for all parameters. To my understanding erlang pattern matching is very efficient, and anything you would pattern match on function parameters, you would have to do some type of logic in the function if you had no pattern matching, so I don't see how pattern matching would negatively effect performance. ETS tables to share data between threads actually make a lot of sense if you think of your program with the idea that no matter what "x" is, this process should properly handle it, because you can't guarantee when the message you sent will be processed. An ETS table is a DB, but you can replicate it by having a single genserver hold that data, and use calls to retrieve and manipulate it. It gives you one spot for your data to be. If you had that same data in messages or function call stacks, by the time the process executes it, it could be stale. Its useful if you need one "true source" of individual pieces of data that needs to be synchronized. Its about decoupling data from processes.
- jlouis 10y ago
  The interesting aspect of scaling up is that it doesn't matter how fast you are at individual single-core computation. Fast single core computation, or even SIMD GPU processing, is largely an "easy" problem: get a stream of data going, or get a chunk of data into the system, and work away on it. What makes scaling up hard is moving data around. Once you have more than a single computer, there is no way you can easily share memory between them, so you have to impose some kind of copying for the system to work. If you want to demux a stream for multiple workers, you have to distribute work to the workers. If you have massive amounts of data in a cluster, you have to move the computation to the nodes in the cluster on which the data resides. Moving data around requires you to have good orchestration of "mostly stateless" computations, with a couple of pinches of persistence strewn in as well. You can do this well in any language, but what makes Erlang well suited for it is that it provides some decent primitives for you with a lot of time sunk into the architecture. Beating this architecture in any other system requires you to spend some time doing that. And chances are it isn't as general, so when the world around you change, the framework you used is left behind. Before Erlang, Tandem systems built hardware/software with many of the same ideas in them. They built these systems primarily for fault tolerance and robustness, but they found, somewhat to their surprise, the same architecture is good at scaling. The reason I believe, after 10 years of Erlang programming, is mostly that the computation model of isolated services forces you to think distribution into the system from day one. Your solution naturally gravitates toward the distributed model, and this in turn means it is easier to scale out later. The model also makes it hard to accidentally build a part of the system which can slow down everything. I think this should be given more credit than it is normally given. And once you have your problem distributed, you call into that CUDA GPU code on the node to obtain the high computation speed. Or you call into your FPGA or DSP ASIC. Any problem on the CPU is slow because of its general purpose behavior (the exception: You are Fabrice Bellard)
  - signa11 10y ago
    > Before Erlang, Tandem systems built hardware/software with many of the same ideas in them. Indeed, Jim-gray's (from tandem) paper 'why computers stop and what we can do about it' is an quite good. It contains a detailed report of machine failure including s/w and h/w and details techniques for reducing the mtbf by these. Erlang's language and runtime seems to have picked seminal ideas from here...
- jallmann 10y ago
  > the fundamental architecture of Erlang seems to be in conflict with big data and high speed computing Because they are different problems. Concurrency, meet parallelism. Concurrency: many smaller tasks that can be multiplexed over one core. The core doesn't need to be particularly fast; it just needs to be able to handle multiple tasks in-flight at once. Web serving, etc. Parallelism: one big, honking task that can be split over multiple cores (or nodes), and each core needs all the horsepower you can eke out, so it can finish its part of the task quicker. Big Data, etc. Erlang is not particularly fast (bad for parallelism), but it excels at concurrency. > I know people do some big data stuff with Erlang Not sure who is doing big data with Erlang, or why anyone would want to -- unless they have some very fundamental misconceptions about the problem at hand and the tools available. > compromise some of the ideals espoused in this article to make it work The article was really nonsense. Most of the terms it throws around have nothing to do with Erlang specifically, and proclamations like Erlang being used for a hypothetical "data center on a chip" are... what? The author's gist basically boils down to this: Use supervision trees with unikernels. I have had the same fantasy, for what it's worth.
  - adrusi 10y ago
    I know you weren't aiming for maximum accuracy in your definitions, but I think this is worth bringing up. Parallelism and Concurrency are not mutually exclusive terms. All parallelism is concurrent. Concurrency is whenever more than one thing is happening at the same time conceptually. Everything from iterators to threads. Parallelism is whenever more than one thing is happening at the same time physically. From a user-space perspective, this means threads or a coprocessor (like a GPU).
    - jallmann 10y ago
      Yes. The intuition is a good one of parallelism being a deliberate way of designing a system to run its parts simultaneously (physically), with concurrency being a property of a system that may or may not have its parts running simultaneously (conceptually, 'overlapping', whether physically or logically). There are many, many ways to think about this difference, and it's fun (and beneficial!) to do so every once in a while. > From a user-space perspective, this means threads Interestingly enough, before SMP and multicore, thread-level "parallelism" was actually disguised by a time-sharing concurrent implementation. That remains true for most threading libraries in languages with a GIL, and any time you have threads exceeding the number of physical cores. In fact, the primary purpose of threads was (and still mostly is) to get a semblance of concurrency... Even the Erlang implementation was single-threaded 2008 or so.
- adrusi 10y ago
  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 have an existing erlang system that has a lot of data and you want to perform some computations on all of it, you'd probably use erlang to get the data onto the appropriate servers and then spawn another process, that can compute efficiently, with numpy or just C or similar. Distributed systems aren't just a way of scaling performance beyond the number of CPUs you can have using the same memory. It's about reliability. Erlang's design enables you to create network services that have decades of uptime. It achieves this through its concurrency model, through its error handling approach, by allowing hotswapping code (an operation that's relatively easy to reason about without mutable state), and probably more ways that I as an outsider am not aware of. [1] http://benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=python3 http://benchmarksgame.alioth.debian.org/u64q/measurements.ph... [2] http://benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=hipe http://benchmarksgame.alioth.debian.org/u64q/measurements.ph... [3] http://benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=racket http://benchmarksgame.alioth.debian.org/u64q/measurements.ph...
  - igouy 10y ago
    Also http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=hipe&lang2=python3 http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=hipe&lang2=racket http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
tombert 10y ago
You know, even if Erlang didn't have great SMP scaling, or wonderful distributed properties, I think its fault-tolerant, actor-model-ey nature would make it wonderful anyway. The fact that you program expecting failures, and forced isolation of everything allows for incredibly "sturdy" code. The other features are fantastic, but they're just gravy as far as I'm concerned.
dboreham 10y ago
Doesn't the existence of Golang remove most of the reasons to use Erlang these days?
- tombert 10y ago
  Nah, Golang is wonderful and I use it for a lot of stuff, but it's sort of a different thing than Erlang. Go is more of a systems-ish language that has an emphasis on concurrency, but also on being relatively C-like. It's much more general-purpose than Erlang. Erlang is more about fault-tolerant, concurrent applications, and more specifically servers. It's not designed to be especially fast, it's designed to make it very simple to write systems with a ton of throughput, that can handle outages, and perform passably in the process. They're different things, and the only thing they have in common is that they both advertise concurrency, really.
- rubiquity 10y ago
  Personally, for me it was the other way around. Discovering Erlang (and Elixir) removed all uses of Go that I had. I primarily used Go for writing networked applications. I never needed crazy CPU throughput on a single point of execution. Erlang's way of modeling concurrency and the built-in facilities of OTP made me way more productive than re-inventing the wheel via channels.
- andrewfromx 10y ago
  specially with this stuff http://www.jerf.org/iri/post/2930 http://www.jerf.org/iri/post/2930 https://github.com/thejerf/suture https://github.com/thejerf/suture golang for the win!
  - tombert 10y ago
    This is certainly something useful for Go, but it's only one aspect of Erlang. You still don't have to guarantee of thread-safety, you still don't have the immutability, you still don't have tail-call optimization, and perhaps most importantly, you don't have a REPL for hot-code updates.
- jlouis 10y ago
rb808 10y ago
I'm really tempted to use Erlang/Elixir for a project at work but unsure of its traction. Is it leading edge or trailing edge? I don't even know, but don't want to saddle the firm with a white elephant - even one that is impeccably fault-tolerant. Is Erlang too esoteric?
- PetrolMan 10y ago
  We've pushed a couple of Elixir apps in the past six months. There was definitely a bit of worry that no one would be able to maintain it, but I have to say that the code is very readable. So many languages integrate some functional aspects that the code doesn't look foreign in most cases. Also, the Phoenix Framework (if you're building a web app) is really, really nice.
- tombert 10y ago
  It depends on your location, I think. Here in New York, it's not too hard to find Erlang enthusiasts, particularly ones that work on Wall Street. That said, no one seemed to have even heard of the language in Dallas when I lived there. So the long-story-short of this is that if you don't mind doing some remote-hiring, it's not too hard to find workers, and things like Ejabberd have a ton of tutorials on writing modules.
- SpacemanSpiff 10y ago
  Embedded systems programmer here. I'm learning Elixir and am very excited about the nerves project: http://nerves-project.org/ http://nerves-project.org/ https://www.youtube.com/watch?v=kpzQrFC55q4 https://www.youtube.com/watch?v=kpzQrFC55q4 Edit: There also seems to be a good Elixir/Erlang community here in Berlin Germany where I live at the moment.
  - ccozan 10y ago
    Do you have some link or contacts in/to this community? I am in process to develop a quite interesting application on Erlang and I am struggling to find a community (in Germany) where I can either ask questions or have a pool of possible people to hire.
atemerev 10y ago
The future is already here: http://erlangonxen.org/ http://erlangonxen.org/
- thenewwazoo 10y ago
  Ling is cool stuff, but I have the impression that it's a clean-sheet Erlang VM implementation, not a port of BEAM. BEAM is time-tested and battle-proven, and I'd really like to see BEAM itself rely less on the underlying OS (e.g. epmd as a separate OS process, quirks in how it uses select/poll). I know Peer Strizinger did a lot of work on this[0], but hasn't (to my knowledge) yet released any of his work, sadly. [0] http://www.grisp.org http://www.grisp.org
- abrookewood 10y ago
  Except they haven't really released anything in ages ... I keep checking back and it's very quiet.
ragnar123 10y ago
Linked article "power-wall" (http://daimi.au.dk/~zxr/papers/treewalls.pdf http://daimi.au.dk/~zxr/papers/treewalls.pdf) seems to be unavailable. Does anyone working link to this article?
- rekoros 10y ago
  Updated to point to https://en.wikipedia.org/wiki/Multi-core_processor#Technical_factors https://en.wikipedia.org/wiki/Multi-core_processor#Technical...
d33 10y ago
One word: ejabberd. That's why erlang matters to me :)
- d33 10y ago
  Also, it has a great free book on it: http://learnyousomeerlang.com/ http://learnyousomeerlang.com/
  - simoncion 10y ago
    There are at least two great free books: http://www.erlang-in-anger.com/ http://www.erlang-in-anger.com/ ! :)
    - rvirding 10y ago
      Written by the same author no less. :-)
deleted 10y ago
[deleted]
ssmoot 10y ago
This seems like it could've been called "Why Actor Systems Matter". If you're on the JVM, I'm not sure what Erlang buys you in practice. It's slower and more obscure. It has a much smaller ecosystem. While process-safety is frequently touted, in the real world this is a non-issue among non-issues. It's just not an actual thing. It's not like the JVM goes around Segfaulting all the time. I'm totally sold on Actor Systems and think it's something more programmers should expose themselves to. I'm just not sure there's much of an argument for Erlang vs the JVM unless you're completely sold on the notion of process isolation for some reason.
- wcummings 10y ago
  Erlang has pretty decent JVM integration. I assume this is why there's a nice Erlang IntelliJ plugin. http://erlang.org/doc/apps/jinterface/jinterface_users_guide.html http://erlang.org/doc/apps/jinterface/jinterface_users_guide...
- strictfp 10y ago
  I would love process isolation on the JVM (several smaller heaps), and I'm not even into the actor model. Plus I can imagine accidental mutability really being a problem. In my Akka course much effort was spent on explaining how to avoid side effect of it (no pun intended).
  - ssmoot 10y ago
    I guess the accidental mutability is a good point. Working in Scala, I've never encountered that. You do learn not to close over local scopes in futures pretty quickly though.
- vvanders 10y ago
  My Stop-The-World GCs would like to have a word with you.
  - ssmoot 10y ago
    And maybe in a project with truly massive memory requirements that's an issue. I've never encountered it (as an issue that is) But I only got into the JVM on 1.6 with Jruby, made the switch to Scala around 1.7, and have been on 1.8 pretty much since release. A 3GB heap is pretty typical, but that's mostly just room for cache. If you're writing web-apps, there's a ridiculous amount of opportunity for using Actors to good effect. On the other hand I try to keep an eye on resources. I try not to throw millions of messages at an Actor. If I'm batch processing, I'm probably work-pulling, mapping and prefetching my Sources to attempt to minimize latency. Even if I could tune mailbox sizes to avoid all that I prefer not to code in upper bounds on input. I would be surprised to hear this is a widespread problem in people's work. You don't often hear the same complaints from Rubyists for example and they're much worse off in that regard. So I feel like this case is massively overstated. But if you have that problem I can certainly see how that might figure into your equation.
atemerev 10y ago
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 aggregation), and it is still running with a few years uptime.
- dewiz 10y ago
  So is preemptive or cooperative better in your opinion ? I couldn't figure it out from your comment.
  - findjashua 10y ago
    preemptive. Cooperative scheduling runs the risk that a long-running actor might starve the other actors
    - davidw 10y ago
      Note that "better" means better for some kinds of things. Preemptive scheduling has a cost, just like running a program on top of, say, Linux costs more than if you coded it specifically to run on the chip itself with no OS.
    - strmpnk 10y ago
      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 hear Akka compared. Akka is quite impressive but I'd never consider it a true alternative to an Erlang or BEAM style runtime.
      - atemerev 10y ago
bitmadness 10y ago
Erlang is glacially slow. Even on a 20 core machine, a multithreaded Erlang implementation will usually be trounced by a good singlethreaded C++/Go/Java implementation. All this stuff about multicore scaling is baloney - who cares it is scales and is still slow?
- querulous 10y ago
  speed isn't a scalar. sometimes you care about latency. sometimes you care about throughput. sometimes you care about arithmetic. http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections http://www.phoenixframework.org/blog/the-road-to-2-million-w...
- statictype 10y ago
  Because at some point the volume of 'work' you process will be more than what a single CPU can handle. I think of it like big corps vs startups. Startups may have more efficient engineers and development cycles and produce higher quality work because of the selectivity of their employees, but the sheer amount of work a big Corp can do is significantly more. (Just an example, not saying big corps don't have talent - far from it) When designing your system you need to decide which model it needs to follow. There are places for both.
- rdtsc 10y ago
  > multithreaded Erlang implementation will usually be trounced by a good singlethreaded C++/Go/Java implementation And Go/Java implementation can be trounced by hand written assembly and ASIC accelerators probably. > All this stuff about multicore scaling is baloney You say baloney I say money in the pocket. I've seen it scale, I've seen it work reliably in large clusters, I've been able to inspect, debug and hotpatch running systems while they are still running. I have seen systems which had non-critical components crash and auto-restart for days without impacting customers and needed teams of "devops" to babysit it. Moreover I've see single and multi-threaded C++ and Java applications with threads and and data races which take weeks or months to find. Or they are screaming fast until they take a nosedive and segfault (also in some minor stupid new feature which nobody uses). You know what the transaction processing rate of a segfaulted process is? - 0 tps. That's why teams like Whatsapp could get by with only 10 or so back-end engineers handling billions of messages / day from various devices new and old, while other companies need 10x or even 20x more than that. It is not just being able to run fast. Assembly runs very fast. It is also about being able to have the right tools and abstraction to define a problem. Erlang has those and they come built-in (the OTP library, the distribution protocol etc), C++ doesn't, so have to start from STL and boost and so on, then get serialization, monitoring, supervision, etc bootstrapped.
amsha 10y ago
Any programming language can do IPC, but Erlang/Elixir is the only language I've seen that makes it really easy. Erlang IPC is transparent whether you're sending messages between to local processes or remote processes. Most languages have trouble with local IPC (usually because of race conditions in data). Every other language I know of, including Go, needs custom code to handle remote IPC.
- MichaelGG 10y ago
  It just seems that all the effort going into Erlang would be better spent on making the OTP stuff as a library for a popular, cross-language platform. Like the JVM (or maybe .NET.)
  - querulous 10y ago
    sure. we can start when the jvm can do preemptive scheduling of processes erlang isn't great because of a single feature or library, it's great because it's designed from the ground up for one very particular role. you can't just port the otp api to go or the jvm. you need the whole foundation
eddd 10y ago
To me the power of Erlang comes from a combination of powerful VM and OTP. In the era of hype for SOA, OTP You can run multiple apps on the same VM and they will run concurrently and communicate with each other using protocols that are core of the language. I agree, erlang seems weird at first, simply because there is not anything like it. It also solved todays problems with software a decade ago.
waf 10y ago
I'm really interested in BEAM languages, but the fault-tolerance / supervisor aspect of it doesn't speak to me. Aren't all modern application fault-tolerant, as long as you don't design something really poorly? For example, I've never had a single HTTP request bring down an entire website -- that's already isolated. Same with message-queue listening processes. For general batch applications, I've always had them short-lived and running periodically, e.g. every minute, so even a complete crash there is isolated between runs. One powerful aspect is how it strongly encourages you to design loosely-coupled message-passing systems that should be easier to scale out. But I'm not convinced that's enough to warrant a switch.
- rtpg 10y ago
  So a side effect of the fault tolerance is that you can also easily redeploy small parts of your app. So if you have a small logic bug, you can circumvent bringing down the entire app to fix it. There's also some more serious stuff like your workers getting killed by the OS for whatever reason and you might need to go in and restart it. You can do this through most queue-based systems in other languages but having everything be built-in is useful.
- rubyn00bie 10y ago
  It's more so, you don't need to write defensive code and you're actively encouraged not to... The mantra is akin to "let it fail, it will recover." Once you start doing it, it becomes more apparent what the difference is... And that's not to say you can't design fault tolerant systems, it's just "easier" to do so with Erlang/BEAM.
- jlarky2012 10y ago
  How fault-tolerant is your web server when datacenter has power outage? You can't build fault-tolerant system with one computing node by definition. That means that if you planning to provide proper availability you want to work with system of applications, not just one. That means you should look into creating networking architecture that can handle all of that. Most of the time it means that people just use tools that solve that for you, like load balancers. But it doesn't mean that somehow all modern applications are immune to failures.
tmerrifi 10y ago
"Cache coherence doesn't scale." This is a controversial statement, and an opinion that is not shared by many respected computer science researchers: http://research.cs.wisc.edu/multifacet/papers/tr2011-1_coherence_stays.pdf http://research.cs.wisc.edu/multifacet/papers/tr2011-1_coher...
- brazeon 10y ago
  It does scale when being considered by software running on it. Even more with some alternative approaches like directories. What OP means is that it does not scale for software to be oblivious to underlying cache coherence and to operate on "one flat shared RAM" assumption. E.g. false cache line sharing etc.
simula67 10y ago
Please let me ask some noob questions. > Erlang matters today because it demonstrates how these semantics can be elegantly packaged in one language, execution model, and virtual machine. Why is it so important to demonstrate that these semantics can be packaged into such a homogeneous environment ? Is it even a good idea ? Is this way of doing things superior to having micro-services that talk to each, all managed by a supervisor system ? Wouldn't that allow us to take advantage of the unique upsides of multiple programming languages, virtual machines and execution models ?
- Tomte 10y ago
  You may underestimate the difficulty of writing a bullet-proof and feature-rich "supervisor system". That has pretty high complexity and lots of nasty edge-cases. Erlang happens to nail that part with OTP.
amelius 10y ago
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?
dschiptsov 10y ago
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.
zwischenzug 10y ago
I made an argument that we were reinventing many of the ideas of Erlang in the DCOS model (Docker, Kub, and cloud etc). Text is here (CTRL-F erlang): https://zwischenzugs.wordpress.com/2015/11/17/dockerconeu-2015-talk-you-know-more-than-you-think/ https://zwischenzugs.wordpress.com/2015/11/17/dockerconeu-20... Video here: https://www.youtube.com/watch?v=-qHwL8C9UoA https://www.youtube.com/watch?v=-qHwL8C9UoA

423 points by _oakland 10y ago

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 enormous constant time penalties that the scaling can't overcome the hurdle until you're talking about thousands of processors. Every single state change requires a function call, every function call involves a pattern matching algorithm that has to account for all of your program arguments (effectively almost the entire state of your thread!) and isn't even strongly typed. And then there is synchronization and data sharing between threads, which seems a bit handwavy and effectively requires a database running in your program that the threads can poll. If your problem set is lots and lots of small independent tasks that don't have to finish overly quickly, then Erlang is fantastic. Stuff like switching voice circuits for example. But I'm trying to imagine manipulating a 1TB dataset with thousands of worker threads if you have to make a copy on the stack for every change every worker makes. I know people do some big data stuff with Erlang, so these have to be solved problems somehow, but I can't help but to suspect that they have to compromise some of the ideals espoused in this article to make it work.

elihu 10y ago
For years, I didn't see what the point of Erlang was. It might scale well, but if it takes an Erlang process running on a hundred processors to equal the performance of a single-threaded C application, what's the point? When I learned a bit more about Erlang, I realized that the point is that there are a lot of applications that are IO bound rather than computation bound, and for those apps Erlang performs very well and is easy to program in. Crunching numbers the fastest isn't always the most important thing.
- rdtsc 10y ago
  One of the main points of Erlang is fault tolerance. Everyone forgets about that and talks actors and scalability, which is fine. But without fault tolerance and proceses with isolated heaps it doesn't matter how fast the C code is, it can process millions of transaction a second, and then segfault, and the availability and transaction rate goes to 0 on that node. The other advantage is power of abstraction. With Erlang it is easy to describe and program distributed system with lots concurrent components. Sure you can do it with C++, Java, and Node.js etc, but those things are awkward there -- either threads share memory and have to deal mutexes, or you in are in callback/promise hell.
actsasbuffoon 10y ago
Erlang excels at high throughput and fault tolerance. Number crunching, even in parallel, isn't really the goal.
jerf 10y ago
Erlang may be useful for coordinating computation tasks, but, yes, even with HIPE it is not a good numerical language on its own. It would be interest to re-engineer a language today that tries to fit into Erlang's niche but has a stronger performance focus. Rust, Cloud Haskell, and Go all sort of cluster in the area I'm thinking about, but none are quite what I'm thinking of. Cloud Haskell is probably closest but writing high-performing Haskell can be harder than you'd like. Rust shows you don't have to clone Erlang's immutability and all the associated issues it brings with it for inter-process safety, but Rust of course is "just" a standard programming language next to what Erlang brings for multi-node communication.
- aaron-lebo 10y ago
  This is an easily solved problem. You've been around so what I'm about to tell you is nothing new, but... In the aughts Ruby and Python were really slow so if you had computational-heavy problems you had to drop into C. It worked but C isn't great. The thing is - we have a lot of languages that can do computational problems easily now - Rust, Go, Nim, and the list goes on.... It becomes relatively trivial to create libraries which could wrap these languages for Erlang/Elixir. In the few cases where Elixir isn't fast enough, just drop down to something else. Write a small piece of code in Rust (you may as well call Elixir/Rust peanut butter and jelly). Optionally, you could create some kind of DSL which compiles down to another language in Elixir. I did the same with xjs (Elixir syntax, Javascript semantics) [0], and I must say, for a 200-line hack it works really well. This isn't even considering the fact that a lot more work could be invested in Erlang's VM. Yes, Ericsson is its corporate sponsor but imagine if you had companies trying to make it fast the way they try with Ruby, Python, JS, or another of other more complicated languages. I think this is relatively low-hanging fruit. You can't tell me that Erlang and Elixir are harder to make fast than other dynamic languages (in most contexts). [0] https://news.ycombinator.com/item?id=11444499 https://news.ycombinator.com/item?id=11444499
  - eggy 10y ago
    The drive for fault-tolerance, distributed computing and on the other hand, speed, are all becoming prominent leaving Erlang in a good place right now, but in need of other major changes in the computing world. Wrapping languages or 'dropping down to C' is no longer going to cut it, even if it is low-hanging fruit. Rust or Pony's guarantees only hold if you stay in their pen. We need a way of marrying PLs like Erlang/LFE/Elixr and Pony to newer hardware paradigms to take advantage of all those multicores, and potentially custom FPGA vs. ASIC chips rigs that will be arriving to market. Why Erlang matters is that it showed you can allow for failure, albeit brief and inconsequential failure, to succeed. No zero-risk or failure here. Acceptable bounds that are easy to see now, but revolutionary at the time. Custom hardware is already in use at HFT and bitcoin mining companies. The U.S. is going to try and beat China's Tianhe-2, that is currently the world's fastest supercomputer. I'm not sure why, since the Chinese scientists say it would take a decade of programming to utilize the potential of the Tianhe-2's hardware. If you think I'm calling the spirit of Lisp Machines from the dead, you're close ;) I think the von Neumann HW architecture, and its straddled type of OS, are straining at the edges of high-stakes usage, not the common user. We don't need supercomputers, we need new hardware architectures at a lower-level than 'super', that can be programmed in months not decades. Programming languages in the OTP/BEAM category, old, battle-tested languages like APL and J, which have always dealt with the array as their unit of computation, will be the basis for new languages, or they will be adapted in an new one. The money, big data, and mission-critical business needs will drive it to market.
Jtsummers 10y ago
> even strongly typed. A nit: Erlang is strongly typed. You cannot (ok, excluding numbers) almost transparently convert a string into a number into a tuple like you could in C, to which everything is merely memory so casting allows trivial but potentially erroneous conversions. Erlang is dynamically typed, not statically typed. Dialyzer + type annotations (and some inferred) allows for static analysis, but it's not directly part of the compiler so it can't be strictly enforced (automatically). EDIT: Also, consider that erlang processes are a dual of objects in the OO sense. They can receive various messages and respond by changing state and/or transmitting messages. This interaction is similar to the way objects (instances of classes) behave in OO languages. The difference being that they're all running concurrently. So you could put a massive amount of state into one process. OR you could have a handful of processes that act together like you have a handful of classes in an OO language. If I write a server for playing a game, I don't include all of a player's state and their connection in one process. I have a process that handles the network connection. It sends messages to a process (or processes) that handle player state. Which connect to some game state processes, and on until the network handler sends messages back to the player or gets more messages from the player.
- jandrese 10y ago
  You've hit on the tradeoff though. By decentralizing your state, you've increased your inter-process synchronization requirements. In the worst case everything ends up being tightly bound and your application runs like a single threaded application because everything is always blocked waiting for the state update from a remote thread. Huge parallelism is easy if your data and processes are largely independent, but the real world is rarely so kind.
  - catnaroek 10y ago
    > In the worst case everything ends up being tightly bound (...) Your tradeoff is between “tightly bound by shared data structures” vs. “tightly bound by process synchronization”. I don't see how either is better than the other. > the real world is rarely so kind In the real world, from what I've seen, while everything is interconnected to everything else, not all the connections are equally strong or important. If you want to compute exact results, without possibility of failure, no matter what the computational cost, then sure, you need to take all the connections into account. If you can trade some accuracy for performance gains in the average case, you'll probably want to find ways to prevent minor failures from bringing down the entire system.
runchberries 10y ago
I don't see why it is confusing that applications for high concurrency would solve problems differently than big data. I am also an Erlang noob, but I don't think pattern matching has to account for all parameters. To my understanding erlang pattern matching is very efficient, and anything you would pattern match on function parameters, you would have to do some type of logic in the function if you had no pattern matching, so I don't see how pattern matching would negatively effect performance. ETS tables to share data between threads actually make a lot of sense if you think of your program with the idea that no matter what "x" is, this process should properly handle it, because you can't guarantee when the message you sent will be processed. An ETS table is a DB, but you can replicate it by having a single genserver hold that data, and use calls to retrieve and manipulate it. It gives you one spot for your data to be. If you had that same data in messages or function call stacks, by the time the process executes it, it could be stale. Its useful if you need one "true source" of individual pieces of data that needs to be synchronized. Its about decoupling data from processes.
jlouis 10y ago
The interesting aspect of scaling up is that it doesn't matter how fast you are at individual single-core computation. Fast single core computation, or even SIMD GPU processing, is largely an "easy" problem: get a stream of data going, or get a chunk of data into the system, and work away on it. What makes scaling up hard is moving data around. Once you have more than a single computer, there is no way you can easily share memory between them, so you have to impose some kind of copying for the system to work. If you want to demux a stream for multiple workers, you have to distribute work to the workers. If you have massive amounts of data in a cluster, you have to move the computation to the nodes in the cluster on which the data resides. Moving data around requires you to have good orchestration of "mostly stateless" computations, with a couple of pinches of persistence strewn in as well. You can do this well in any language, but what makes Erlang well suited for it is that it provides some decent primitives for you with a lot of time sunk into the architecture. Beating this architecture in any other system requires you to spend some time doing that. And chances are it isn't as general, so when the world around you change, the framework you used is left behind. Before Erlang, Tandem systems built hardware/software with many of the same ideas in them. They built these systems primarily for fault tolerance and robustness, but they found, somewhat to their surprise, the same architecture is good at scaling. The reason I believe, after 10 years of Erlang programming, is mostly that the computation model of isolated services forces you to think distribution into the system from day one. Your solution naturally gravitates toward the distributed model, and this in turn means it is easier to scale out later. The model also makes it hard to accidentally build a part of the system which can slow down everything. I think this should be given more credit than it is normally given. And once you have your problem distributed, you call into that CUDA GPU code on the node to obtain the high computation speed. Or you call into your FPGA or DSP ASIC. Any problem on the CPU is slow because of its general purpose behavior (the exception: You are Fabrice Bellard)
- signa11 10y ago
  > Before Erlang, Tandem systems built hardware/software with many of the same ideas in them. Indeed, Jim-gray's (from tandem) paper 'why computers stop and what we can do about it' is an quite good. It contains a detailed report of machine failure including s/w and h/w and details techniques for reducing the mtbf by these. Erlang's language and runtime seems to have picked seminal ideas from here...
jallmann 10y ago
> the fundamental architecture of Erlang seems to be in conflict with big data and high speed computing Because they are different problems. Concurrency, meet parallelism. Concurrency: many smaller tasks that can be multiplexed over one core. The core doesn't need to be particularly fast; it just needs to be able to handle multiple tasks in-flight at once. Web serving, etc. Parallelism: one big, honking task that can be split over multiple cores (or nodes), and each core needs all the horsepower you can eke out, so it can finish its part of the task quicker. Big Data, etc. Erlang is not particularly fast (bad for parallelism), but it excels at concurrency. > I know people do some big data stuff with Erlang Not sure who is doing big data with Erlang, or why anyone would want to -- unless they have some very fundamental misconceptions about the problem at hand and the tools available. > compromise some of the ideals espoused in this article to make it work The article was really nonsense. Most of the terms it throws around have nothing to do with Erlang specifically, and proclamations like Erlang being used for a hypothetical "data center on a chip" are... what? The author's gist basically boils down to this: Use supervision trees with unikernels. I have had the same fantasy, for what it's worth.
- adrusi 10y ago
  I know you weren't aiming for maximum accuracy in your definitions, but I think this is worth bringing up. Parallelism and Concurrency are not mutually exclusive terms. All parallelism is concurrent. Concurrency is whenever more than one thing is happening at the same time conceptually. Everything from iterators to threads. Parallelism is whenever more than one thing is happening at the same time physically. From a user-space perspective, this means threads or a coprocessor (like a GPU).
  - jallmann 10y ago
    Yes. The intuition is a good one of parallelism being a deliberate way of designing a system to run its parts simultaneously (physically), with concurrency being a property of a system that may or may not have its parts running simultaneously (conceptually, 'overlapping', whether physically or logically). There are many, many ways to think about this difference, and it's fun (and beneficial!) to do so every once in a while. > From a user-space perspective, this means threads Interestingly enough, before SMP and multicore, thread-level "parallelism" was actually disguised by a time-sharing concurrent implementation. That remains true for most threading libraries in languages with a GIL, and any time you have threads exceeding the number of physical cores. In fact, the primary purpose of threads was (and still mostly is) to get a semblance of concurrency... Even the Erlang implementation was single-threaded 2008 or so.
adrusi 10y ago
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 have an existing erlang system that has a lot of data and you want to perform some computations on all of it, you'd probably use erlang to get the data onto the appropriate servers and then spawn another process, that can compute efficiently, with numpy or just C or similar. Distributed systems aren't just a way of scaling performance beyond the number of CPUs you can have using the same memory. It's about reliability. Erlang's design enables you to create network services that have decades of uptime. It achieves this through its concurrency model, through its error handling approach, by allowing hotswapping code (an operation that's relatively easy to reason about without mutable state), and probably more ways that I as an outsider am not aware of. [1] http://benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=python3 http://benchmarksgame.alioth.debian.org/u64q/measurements.ph... [2] http://benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=hipe http://benchmarksgame.alioth.debian.org/u64q/measurements.ph... [3] http://benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=racket http://benchmarksgame.alioth.debian.org/u64q/measurements.ph...
- igouy 10y ago
  Also http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=hipe&lang2=python3 http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=hipe&lang2=racket http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

tombert 10y ago

You know, even if Erlang didn't have great SMP scaling, or wonderful distributed properties, I think its fault-tolerant, actor-model-ey nature would make it wonderful anyway. The fact that you program expecting failures, and forced isolation of everything allows for incredibly "sturdy" code. The other features are fantastic, but they're just gravy as far as I'm concerned.

dboreham 10y ago

Doesn't the existence of Golang remove most of the reasons to use Erlang these days?

tombert 10y ago
Nah, Golang is wonderful and I use it for a lot of stuff, but it's sort of a different thing than Erlang. Go is more of a systems-ish language that has an emphasis on concurrency, but also on being relatively C-like. It's much more general-purpose than Erlang. Erlang is more about fault-tolerant, concurrent applications, and more specifically servers. It's not designed to be especially fast, it's designed to make it very simple to write systems with a ton of throughput, that can handle outages, and perform passably in the process. They're different things, and the only thing they have in common is that they both advertise concurrency, really.
rubiquity 10y ago
Personally, for me it was the other way around. Discovering Erlang (and Elixir) removed all uses of Go that I had. I primarily used Go for writing networked applications. I never needed crazy CPU throughput on a single point of execution. Erlang's way of modeling concurrency and the built-in facilities of OTP made me way more productive than re-inventing the wheel via channels.
andrewfromx 10y ago
specially with this stuff http://www.jerf.org/iri/post/2930 http://www.jerf.org/iri/post/2930 https://github.com/thejerf/suture https://github.com/thejerf/suture golang for the win!
- tombert 10y ago
  This is certainly something useful for Go, but it's only one aspect of Erlang. You still don't have to guarantee of thread-safety, you still don't have the immutability, you still don't have tail-call optimization, and perhaps most importantly, you don't have a REPL for hot-code updates.
jlouis 10y ago

rb808 10y ago

I'm really tempted to use Erlang/Elixir for a project at work but unsure of its traction. Is it leading edge or trailing edge? I don't even know, but don't want to saddle the firm with a white elephant - even one that is impeccably fault-tolerant. Is Erlang too esoteric?

PetrolMan 10y ago
We've pushed a couple of Elixir apps in the past six months. There was definitely a bit of worry that no one would be able to maintain it, but I have to say that the code is very readable. So many languages integrate some functional aspects that the code doesn't look foreign in most cases. Also, the Phoenix Framework (if you're building a web app) is really, really nice.
tombert 10y ago
It depends on your location, I think. Here in New York, it's not too hard to find Erlang enthusiasts, particularly ones that work on Wall Street. That said, no one seemed to have even heard of the language in Dallas when I lived there. So the long-story-short of this is that if you don't mind doing some remote-hiring, it's not too hard to find workers, and things like Ejabberd have a ton of tutorials on writing modules.
SpacemanSpiff 10y ago
Embedded systems programmer here. I'm learning Elixir and am very excited about the nerves project: http://nerves-project.org/ http://nerves-project.org/ https://www.youtube.com/watch?v=kpzQrFC55q4 https://www.youtube.com/watch?v=kpzQrFC55q4 Edit: There also seems to be a good Elixir/Erlang community here in Berlin Germany where I live at the moment.
- ccozan 10y ago
  Do you have some link or contacts in/to this community? I am in process to develop a quite interesting application on Erlang and I am struggling to find a community (in Germany) where I can either ask questions or have a pool of possible people to hire.

atemerev 10y ago

The future is already here: http://erlangonxen.org/ http://erlangonxen.org/

thenewwazoo 10y ago
Ling is cool stuff, but I have the impression that it's a clean-sheet Erlang VM implementation, not a port of BEAM. BEAM is time-tested and battle-proven, and I'd really like to see BEAM itself rely less on the underlying OS (e.g. epmd as a separate OS process, quirks in how it uses select/poll). I know Peer Strizinger did a lot of work on this[0], but hasn't (to my knowledge) yet released any of his work, sadly. [0] http://www.grisp.org http://www.grisp.org
abrookewood 10y ago
Except they haven't really released anything in ages ... I keep checking back and it's very quiet.

ragnar123 10y ago

Linked article "power-wall" (http://daimi.au.dk/~zxr/papers/treewalls.pdf http://daimi.au.dk/~zxr/papers/treewalls.pdf) seems to be unavailable. Does anyone working link to this article?

rekoros 10y ago
Updated to point to https://en.wikipedia.org/wiki/Multi-core_processor#Technical_factors https://en.wikipedia.org/wiki/Multi-core_processor#Technical...

d33 10y ago

One word: ejabberd. That's why erlang matters to me :)

d33 10y ago
Also, it has a great free book on it: http://learnyousomeerlang.com/ http://learnyousomeerlang.com/
- simoncion 10y ago
  There are at least two great free books: http://www.erlang-in-anger.com/ http://www.erlang-in-anger.com/ ! :)
  - rvirding 10y ago
    Written by the same author no less. :-)

deleted 10y ago

[deleted]

ssmoot 10y ago

This seems like it could've been called "Why Actor Systems Matter". If you're on the JVM, I'm not sure what Erlang buys you in practice. It's slower and more obscure. It has a much smaller ecosystem. While process-safety is frequently touted, in the real world this is a non-issue among non-issues. It's just not an actual thing. It's not like the JVM goes around Segfaulting all the time. I'm totally sold on Actor Systems and think it's something more programmers should expose themselves to. I'm just not sure there's much of an argument for Erlang vs the JVM unless you're completely sold on the notion of process isolation for some reason.

wcummings 10y ago
Erlang has pretty decent JVM integration. I assume this is why there's a nice Erlang IntelliJ plugin. http://erlang.org/doc/apps/jinterface/jinterface_users_guide.html http://erlang.org/doc/apps/jinterface/jinterface_users_guide...
strictfp 10y ago
I would love process isolation on the JVM (several smaller heaps), and I'm not even into the actor model. Plus I can imagine accidental mutability really being a problem. In my Akka course much effort was spent on explaining how to avoid side effect of it (no pun intended).
- ssmoot 10y ago
  I guess the accidental mutability is a good point. Working in Scala, I've never encountered that. You do learn not to close over local scopes in futures pretty quickly though.
vvanders 10y ago
My Stop-The-World GCs would like to have a word with you.
- ssmoot 10y ago
  And maybe in a project with truly massive memory requirements that's an issue. I've never encountered it (as an issue that is) But I only got into the JVM on 1.6 with Jruby, made the switch to Scala around 1.7, and have been on 1.8 pretty much since release. A 3GB heap is pretty typical, but that's mostly just room for cache. If you're writing web-apps, there's a ridiculous amount of opportunity for using Actors to good effect. On the other hand I try to keep an eye on resources. I try not to throw millions of messages at an Actor. If I'm batch processing, I'm probably work-pulling, mapping and prefetching my Sources to attempt to minimize latency. Even if I could tune mailbox sizes to avoid all that I prefer not to code in upper bounds on input. I would be surprised to hear this is a widespread problem in people's work. You don't often hear the same complaints from Rubyists for example and they're much worse off in that regard. So I feel like this case is massively overstated. But if you have that problem I can certainly see how that might figure into your equation.

atemerev 10y ago

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 aggregation), and it is still running with a few years uptime.

dewiz 10y ago
So is preemptive or cooperative better in your opinion ? I couldn't figure it out from your comment.
- findjashua 10y ago
  preemptive. Cooperative scheduling runs the risk that a long-running actor might starve the other actors
  - davidw 10y ago
    Note that "better" means better for some kinds of things. Preemptive scheduling has a cost, just like running a program on top of, say, Linux costs more than if you coded it specifically to run on the chip itself with no OS.
  - strmpnk 10y ago
    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 hear Akka compared. Akka is quite impressive but I'd never consider it a true alternative to an Erlang or BEAM style runtime.
    - atemerev 10y ago

bitmadness 10y ago

Erlang is glacially slow. Even on a 20 core machine, a multithreaded Erlang implementation will usually be trounced by a good singlethreaded C++/Go/Java implementation. All this stuff about multicore scaling is baloney - who cares it is scales and is still slow?

querulous 10y ago
speed isn't a scalar. sometimes you care about latency. sometimes you care about throughput. sometimes you care about arithmetic. http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections http://www.phoenixframework.org/blog/the-road-to-2-million-w...
statictype 10y ago
Because at some point the volume of 'work' you process will be more than what a single CPU can handle. I think of it like big corps vs startups. Startups may have more efficient engineers and development cycles and produce higher quality work because of the selectivity of their employees, but the sheer amount of work a big Corp can do is significantly more. (Just an example, not saying big corps don't have talent - far from it) When designing your system you need to decide which model it needs to follow. There are places for both.
rdtsc 10y ago
> multithreaded Erlang implementation will usually be trounced by a good singlethreaded C++/Go/Java implementation And Go/Java implementation can be trounced by hand written assembly and ASIC accelerators probably. > All this stuff about multicore scaling is baloney You say baloney I say money in the pocket. I've seen it scale, I've seen it work reliably in large clusters, I've been able to inspect, debug and hotpatch running systems while they are still running. I have seen systems which had non-critical components crash and auto-restart for days without impacting customers and needed teams of "devops" to babysit it. Moreover I've see single and multi-threaded C++ and Java applications with threads and and data races which take weeks or months to find. Or they are screaming fast until they take a nosedive and segfault (also in some minor stupid new feature which nobody uses). You know what the transaction processing rate of a segfaulted process is? - 0 tps. That's why teams like Whatsapp could get by with only 10 or so back-end engineers handling billions of messages / day from various devices new and old, while other companies need 10x or even 20x more than that. It is not just being able to run fast. Assembly runs very fast. It is also about being able to have the right tools and abstraction to define a problem. Erlang has those and they come built-in (the OTP library, the distribution protocol etc), C++ doesn't, so have to start from STL and boost and so on, then get serialization, monitoring, supervision, etc bootstrapped.

amsha 10y ago

Any programming language can do IPC, but Erlang/Elixir is the only language I've seen that makes it really easy. Erlang IPC is transparent whether you're sending messages between to local processes or remote processes. Most languages have trouble with local IPC (usually because of race conditions in data). Every other language I know of, including Go, needs custom code to handle remote IPC.

MichaelGG 10y ago
It just seems that all the effort going into Erlang would be better spent on making the OTP stuff as a library for a popular, cross-language platform. Like the JVM (or maybe .NET.)
- querulous 10y ago
  sure. we can start when the jvm can do preemptive scheduling of processes erlang isn't great because of a single feature or library, it's great because it's designed from the ground up for one very particular role. you can't just port the otp api to go or the jvm. you need the whole foundation

eddd 10y ago

To me the power of Erlang comes from a combination of powerful VM and OTP. In the era of hype for SOA, OTP You can run multiple apps on the same VM and they will run concurrently and communicate with each other using protocols that are core of the language. I agree, erlang seems weird at first, simply because there is not anything like it. It also solved todays problems with software a decade ago.

waf 10y ago

I'm really interested in BEAM languages, but the fault-tolerance / supervisor aspect of it doesn't speak to me. Aren't all modern application fault-tolerant, as long as you don't design something really poorly? For example, I've never had a single HTTP request bring down an entire website -- that's already isolated. Same with message-queue listening processes. For general batch applications, I've always had them short-lived and running periodically, e.g. every minute, so even a complete crash there is isolated between runs. One powerful aspect is how it strongly encourages you to design loosely-coupled message-passing systems that should be easier to scale out. But I'm not convinced that's enough to warrant a switch.

rtpg 10y ago
So a side effect of the fault tolerance is that you can also easily redeploy small parts of your app. So if you have a small logic bug, you can circumvent bringing down the entire app to fix it. There's also some more serious stuff like your workers getting killed by the OS for whatever reason and you might need to go in and restart it. You can do this through most queue-based systems in other languages but having everything be built-in is useful.
rubyn00bie 10y ago
It's more so, you don't need to write defensive code and you're actively encouraged not to... The mantra is akin to "let it fail, it will recover." Once you start doing it, it becomes more apparent what the difference is... And that's not to say you can't design fault tolerant systems, it's just "easier" to do so with Erlang/BEAM.
jlarky2012 10y ago
How fault-tolerant is your web server when datacenter has power outage? You can't build fault-tolerant system with one computing node by definition. That means that if you planning to provide proper availability you want to work with system of applications, not just one. That means you should look into creating networking architecture that can handle all of that. Most of the time it means that people just use tools that solve that for you, like load balancers. But it doesn't mean that somehow all modern applications are immune to failures.

tmerrifi 10y ago

"Cache coherence doesn't scale." This is a controversial statement, and an opinion that is not shared by many respected computer science researchers: http://research.cs.wisc.edu/multifacet/papers/tr2011-1_coherence_stays.pdf http://research.cs.wisc.edu/multifacet/papers/tr2011-1_coher...

brazeon 10y ago
It does scale when being considered by software running on it. Even more with some alternative approaches like directories. What OP means is that it does not scale for software to be oblivious to underlying cache coherence and to operate on "one flat shared RAM" assumption. E.g. false cache line sharing etc.

simula67 10y ago

Please let me ask some noob questions. > Erlang matters today because it demonstrates how these semantics can be elegantly packaged in one language, execution model, and virtual machine. Why is it so important to demonstrate that these semantics can be packaged into such a homogeneous environment ? Is it even a good idea ? Is this way of doing things superior to having micro-services that talk to each, all managed by a supervisor system ? Wouldn't that allow us to take advantage of the unique upsides of multiple programming languages, virtual machines and execution models ?

Tomte 10y ago
You may underestimate the difficulty of writing a bullet-proof and feature-rich "supervisor system". That has pretty high complexity and lots of nasty edge-cases. Erlang happens to nail that part with OTP.

amelius 10y ago

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?

dschiptsov 10y ago

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.

zwischenzug 10y ago

I made an argument that we were reinventing many of the ideas of Erlang in the DCOS model (Docker, Kub, and cloud etc). Text is here (CTRL-F erlang): https://zwischenzugs.wordpress.com/2015/11/17/dockerconeu-2015-talk-you-know-more-than-you-think/ https://zwischenzugs.wordpress.com/2015/11/17/dockerconeu-20... Video here: https://www.youtube.com/watch?v=-qHwL8C9UoA https://www.youtube.com/watch?v=-qHwL8C9UoA