The biggest project I used Akka for, in a production system, was the election reporting and analysis system at NBC. It was surprisingly capable on minimal hardware. The key was in its ease of decoupling potentially blocking processes as their own actors. I'm mainly going to talk about the architecture, and hopefully it'll tell you what the experience was like.

The web application processed HTTP requests from the client via Servlet 3.0. The "AsyncContext" was retrieved from the request object, which lets you hold the connection to the client (until you call its "complete" method). Pass that off to a temporary RequestHandler actor.

The RequestHandler's job is to store this one AsyncContext and fulfill the request. It queries one or more "service actors". The RequestHandler is free to block until it gets a response. It's just devoted to that one client request, so nothing else will try to use it.

A service actor has no knowledge of the web application server, database, or other I/O processes. A nifty thing is you can load this actor up quickly and independently, via perhaps a Scala REPL, and test its functionality (number crunching perhaps) without needing external inputs and outputs.

We also had an actor to handle database I/O, and also separate actors for each of the external feeds we were reading from (data being provided from other companies).

We had one service actor maintaining in-memory state (persisting it asynchronously via the database actor). The key was to always have it respond with an immutable object, which is totally safe to pass between Akka actors. When a change is written, the new state would be a copy of the previous immutable state, but with that one change made. Behind the scenes, this is extremely efficient. When you're passing around data, you're not passing around actual copies of the data. You're passing pointers to specific versions of the data. Client requests might regularly ping the service actor for the latest state, and the service actor is able to respond lightning fast with a pointer.

You could have one actor "subscribe" to updates of this state, or subscribe to changes of a subset of the state. (The exit poll service actor may have only been interested in updates to the exit poll data.) There's no issue with providing a pointer to a subset of a immutable object.

Also, I didn't mention this running on multiple servers. This runs on one server, which allows it to benefit from the speed of immutable object transfer, and it overall simplifies the architecture. Akka makes remote communication fairly easily, but it was unnecessary.

The previous system they had required ... I think it was 20+ servers (including redundant systems). This Akka-based system was capable of running with one server, with a couple others for backups. When one system goes down, it's very easy to let it fail. All communication runs on sequence numbers, (i.e. Give me all the updates since change #15), so if there is a glitch, everything can get back up to date in an orderly fashion.

Building a performant production Akka system was very simple as compared to more complex options I've endured in the past. There's some additional trickiness with actors in terms of how you log exceptions, and how you initialize them with "initialize objects", which you have to learn, but... in general, I found Akka in production... very nice.

I didn't stick around long enough to get detailed metrics, but my coworker reported that the system has been handling just fine. During the last major election in November, it was "properly fault tolerant", and all the election calls were processed smoothly. Mission accomplished.

Is Elixir (elixir-lang.org) production ready? What would you say are the distinct positives of using Elixir over Erlang? Why would/wouldn't you go for it?

Is Elixir the programming language that Jose Valim was working on ready for production usage? Is anyone already using it? I've been extremely curious about it and I'd like to know of developer experiences with it and how its compares to erlang. What would you say are the distinct positives of using Elixir over Erlang and why you wouldn't go for it.

First of: Yes Elixir is production ready for a while now. I use it already at a second company (to be honest: I introduced it in both).

I started with Erlang in 2013 while looking for an alternative for Ruby. Ruby lacked so much and Erlang seemed to offer solutions to many of my problems. But the syntax was not very nice. This was something which I found much better at Ruby. Then I attended a workshop by Chris McCord during the RailsConv 2014 and I fell in love with Elixir. Elixir is a bit more pragmatic than Erlang since it comes with simpler patterns e.g. for GenServers. And the code is much better to read from my perspective.

Regarding performance there is no difference. Both compiles to the same byte code. So there is no loss. Up to now I used it for several projects and many are currently running in production like:

• A data client fetching information about call center’s telephone lines
• An application serving structured data about customer devices. It is able to sync automatically to some other micro services to ensure no manual seeding of data is ever required.
• An application which does some database alignment tasks between two backend services. It was more or less a quick fix. The initial script was written in Python, but was not very reliable. It often crashed. Since it is now done by this Elixir app the supervisors ensure it stays up and running. There were no issues any more after the exchange.
• An application restructuring customer data. Initially it was just a small mix project too fix the structure of some customer data. But since we needed to do this task for more and more customers it became a serious part of my current tool belt when dealing with customer problems.

Further Elixir applications (mainly RESTful backends) are already planned. The stack of our company includes along with Elixir, Python and Scala (plus some Java legathy). If you monitor the load of all the applications you will see that the Java app consumes 10 times more RAM compared to the Elixir app while the Scala apps consume about 5 times as much. All applications currently have a similar amount of requests to handle, but regarding infrastructure Elixir is so far the most lightweight solution here.

Erlang VM was developed with concurrent systems in mind. Node joining and process separation was the main reason of all the decision making while developing the BEAM machine.

JVM was always supposed to be universal and because of that some of its already settled standards are limitations to making concurrent systems as good as they could be done.

One of the main decisions is for instance garbage collection system - Java pauses all threads to clean the memory, which makes availability substantially worse. The processes can share memory, and because of that the GC has to be universal for all of them. Erlang VM does garbage collection on per process basis. Which means the process gets cleared after its death, and it’s totally independent from other processes which means no availability tradeoffs.

There’s a lot of decisions like that which cannot be changed because of inherent VM infrastructure.
And although there are frameworks for JVM that try to mimic some existing concurrency systems (f.i Akka) they’re still hacks and workarounds to make JVM be something it isn’t. And though they grew to be mature and war-tested frameworks they still have to carry the weight of JVM’s legacy

They aren't better isolated. They are isolated.

Erlang processes are memory isolated. They are not capable of effecting the memory of other processes. This provides safety from unintended effects but also limits the ability to use some concurrency models. Erlang users the actor model but can't have several threads acting upon a single object transactionally with software transactional memory, for example.

Isolation is a very interesting model and provides a lot of security and potential for performance enhancements but also makes several options impossible. So it's not better.

Also Haskell threads are not isolated worse. They are not isolated at all. They aren't trying to be. They are making use of STM and MVars for concurrency which share memory and are great for their own reasons just like Erlangs model.

Green threads are an orthogonal concept. It means implement threads in a light weight way in the runtime rather that using heavy weight operating system threads. This means you can start up hundreds of threads without using up tons of resources. Both Haskell and Erlang have green threads.

One of the contributors here (core, genx, expm, other libs).

We have been using Elixir since around end of the spring 2012 and so far our run is pretty decent — bugs get fixed quickly enough, detailes are ironed out as we go (José is very communicable) and we couldn't be happier.

After all, after you compile Elixir, it's an Erlang's AST that gets down to erlang's compiler and we're still running on the same BEAM emulator.

I find one of the most important strengths of Elixir to be macros. They allow for creating DSLs, avoiding code repetition and more unexpected things (checkout how we implemented String.Unicode or type specifications!)

Feel free to come over to #elixir-lang IRC channel (FreeNode). Will be happy to chat about Elixir!

It isn't. Erlang is better at concurrency and parallelism partly because it isn't a threaded model. Java only really supports threads natively. Erlang supports processes that may run on top of threads, separate system processes or even separate machines. That is just the beginning of the differences though.

Erlang processes don't share memory or state. Each one is independent and communicates by passing messages. This model of concurrency comes from Communicating Sequential Processes (CSP) which is a formal system for safely handling concurrency. While Erlang doesn't strictly follow CSP, it is close enough to make well designed Erlang programs safely concurrent on large jobs.

Java threading on the other hand provides a lawless wasteland inside a single process memory space. Threads can stomp all over each other and the programmer has to use clear design to prevent it. The Java programmer can do the same thing Erlang does (there is a version of Erlang on the JVM), but they don't have to and the results can be a steaming pile of wrecked code. Sure you can do anything you want, but in the same sense as this picture.

Tõnis Pool at University of Tartu published an in-depth comparison, available here: http://ds.cs.ut.ee/courses/course-files/To303nis%20Pool%20.pdf. It’s not very long, so give it a read.

In short, they are quite different. Erlang’s VM is designed for the Actor model, where ligth-weight, independent processes communicate through messages. They don’t have shared memory, so sending a message means copying the data. All data is immutable. This means that the BEAM is very good at what it does, but less flexible than the JVM.

The JVM is less opinionated about what you do with it, so it can support many different approaches to concurrency, programming paradigms etc. There’s even a very successful implementation of the Actor model on the JVM called Akka. If your problem at hand doesn’t fall nicely into Erlang’s actor model, then the JVM is likely a good choice.

But if the actor model fits your problem, then the BEAM will be hard to beat. It let you easily spawn millions of processes on a single machine, and OTP (Erlang’s framework for building distributed, fault-tolerant systems) will help you create a distributed application that can be updated while the system is running. Few other language runtimes will let you do that.

Well, the obvious ones would be the following:

• A lot more people to ask for help if you run into problems
• Fewer bugs (in the language) since Erlang is very mature
• Generally more written about the language on the web
• Simpler (in my opinion) abstractions, with fewer ways to shoot yourself in the foot (with the drawback that it’s slightly less expressive)

Edited to add:

• The Erlang community, simply by virtue of being around for a long time, has a lot of very experienced people who have worked a long time in the industry with a good idea of what works and doesn’t (and why) - they’ve seen a lot of fads play out over time (not to say that Elixir is a fad - it’s probably great - even Armstrong says so =P)

At CommerceHub, we have integrated Akka with about a half dozen of our components. We have two component classes connected via Remoting in production (something like 400 installs of the "client" component and 20 of the "server" component) and have experimented with Clustering in a new component.

The primary benefit we get out of Actors is a clean pattern for building pipelined processes without having to worry about threading at design time. It's also helpful for specific concurrency problems that Java makes very difficult to solve. For example, we'll use Actors to replace lock-heavy systems by creating an actor that represents all the locked behaviors and have actors representing each use case message the lock actor. The lock actor we'll pin to a single thread and the actors we'll distribute as necessary to meet load. Using a priority mailbox allows us to control which use case "wins" in a race condition, something difficult when synchronizing threads.

And that's the secondary benefit we get out of Actors (and really out of Akka itself): you can program the performance characteristics of your currency code separately from the code itself. Tuning the size and behavior of actor pools and their mailboxes is very straightforward and shaves time off the optimization phase of development.

In our experience, the ease of tuning spread to Remoted systems as well, with us able to spin up specific actor "servers" independently and on-demand (more on this later). Moving functions in a pipeline from one component to another was reasonably seamless, too. And when we outgrew Java serialization, adapting our remoted systems to interchange via JSON instead was similarly straightforward.

The downside to Actors is that they can be difficult to reason with. As an example, we found difficulty when testing both business code and actor orchestration ("conversations") at the same time. This lead us to adopt a pattern where we use Actors to deal with messaging concerns and keep the business code in POJO "services" which Actors call. We also maintain "conversation" diagrams for each component to help assert the correctness of orchestration tests...making sure that hand-off operations that include a Remote client properly handle message loss, for example.

And you WILL have message loss, or at least what looks like it. Network quality notwithstanding: during Actor startup or shutdown it's pretty much guaranteed that even if messages are delivered they won't be handled.

Always integration test with a dead node and a node that accepts but doesn't respond in the cluster/pool. This will force devs to consider the very real problem of dead / zombie systems up front. Similarly, dead Letters should be considered a big deal during development, as these can indicate problems with the actor lifecycle.

For remote systems, securing and load balancing actor systems can be a challenge for engineers used to firewalls and load balancers fixing everything. Addressability of individual actor systems is essential for the bidirectional comms required for remoting to work, so you can't just have a big "actorpool.my.co;" if you want to have two or more Actor systems on the same IP, you'll also need to care about their port. For service discovery, we use DNS SRV records and client side load balancing with Remoting systems. Our clustered system uses the same technique to identify the "seed nodes." (BTW I've been meaning to open source the "SRV Routing Actor" we built to make this process seamless to client code. If you've got the same problem, bug me and I'll get on it).

Logging and auditing can be annoying at times, especially when porting a legacy system whose logs feed downstream processes. A common logging pattern is to build a collection of context (such as an MDC) as a side effect of processing, and many loggers expect that this is an okay thing to put into a ThreadLocal. This obviously doesn't jibe with the desire for side-effect free programming and the evasion of thread affinity that's implied by an actor system. We got around it by moving the MDC as part of message content wherever contextual logging is important (and at least one of our components uses an actor whose job it is to do logging on behalf of other actors, who communicate with it via tells). Somebody with more time than me could probably solve this in a less clunky fashion and indeed I've seen "plugins" that improve the situation (though they introduce the problem of, well, depending on the plugin).

Akka (and Scala) moves fast. My components are rarely in lock-step with each other w/r/t their versions of the framework and while things commonly work great in this configuration we've had some "heisenbugs" that have cleared up with an upgrade.

My engineers have found Kamon to be an indispensable tool for visualizing Actor systems at runtime.

I've used lots of different concurrency libraries, application servers and job scheduling frameworks. Akka is an excellent balance: not hard to write against nor hard to control. It can seem needlessly verbose at first, but then you remember how important it is to bound everything in systems programming and Akka's verbosity is often there to force those boundaries. My devs used to reach for ThreadExecutors first when building utilities. Now they reach for Akka.

This is from someone who has just played with the language, not a professional developer, so have a boulder of salt with it.

That said, they are the same language. If they were cars, Erlang is the totally stripped down, no frills, any color as long as it's black model and Elixir has all the fancy bells and whistles, like a great sound system, climate control, GPS system, and so on.

The mechanics are the same, same engine, transmission, suspension and so on, but the creature comforts of Elixir are much nicer.

It's not like the translation from C to C++, where the differences are significant in how they work. Both Erlang and Elixir run on BEAM, use OTP, and Elixir can literally call anything from Erlang directly. It just has some extra fancy doodads.

And they are nice ones. The pipe system is lovely and it's definitely easier to read, being more verbose and fewer symbols, but at the end, they work the same way, with the same weird quirks inherited from their common ancestor as a pure telecommunications systems control language.

I designed Bamboo which is a big data analytics engine; which uses the Typesafe stack heavily. This work is an end-to-end solution for Hewlett Packard and delivered in several ways to customers (as a native package using something like `dpkg ...`, virtual images deployed by docker) . We are a big fan of Akka, Scala and Play. So, how do we use it?

We have a distributed Akka cluster that caches the result of large-scale queries and we introduced several techniques as described in Amazon's DynamoDB paper and benchmarking this piece of work using TCP-H and so far, its been more than satisfactory though we had "secret sauces" embedded into that implementation and largely drawn from the excellent work of Gil Tene and Martin Thompson.

We have another Akka cluster that handles the recording of user's actions in the platform and is able to replay the trail of the user at any point in time; this cluster hosts a number of actors using the Akka persistence.

There's another Akka cluster that was designed to handle stringing jobs of different types together into a workflow and managing the lifecycle of the workflows and we've crafted the dynamic deployment of actors to different execution environments. Each stage of executing the workflow requires input and output where the next stage would consume the output from the previous. Actors are used to process the input and output and stream them, if necessary.

That's about all i can say, really. I'm a big fan of the Typesafe stack and of Scala really and i wanted to put it out to the folks that Scala and Akka really allowed my team to put their imagination to the test, literally.

The Erlang community has been around for a long time. I hear from many that they love the language. For someone passionate about Erlang, there is not really any benefit to switching to Elixir. If there was a feature in Elixir you needed (like macros), you could write a small module in Elixir and us it in your Erlang code.

Programming language choice is a very subjective. People choose languages and frameworks out of personal taste. Some people love the Erlang syntax. Other prefer Elixir. For those coming from a ruby background, the Elixir syntax may feel Elixir is a lot less foreign than Erlang.

For me, I just found there was too much punctuation in Erlang. I was forever missing a comma, semi-colon, or a period. I occasionally forget the `do` in Elixir, but not very often.

With all that said, I do find myself wondering why someone new to the Erlang VM would go Erlang over Elixir, but hey, to each his own.

Most people that believe one language is better than another do so for personal preference. Their personal preferences are influenced by the languages they have become familiar with, as well as the areas they work in, or would prefer to work in.

Elixir is much more comfortable to me that Erlang with my Ruby and Prolog background, because it seems to be less of a learning curve and “reads” better to me that Erlang.

Elixir also adds some missing functionality to Erlang, which apart from a friendlier syntax as some of the reasons Jose the creator gave. For more info read Why did José Valim create Elixir? - Adolfo Neto - Medium

Eric des Courtis's answer to How would you choose between Elixir and Erlang? gave some useful pros and cons for both languages, with Erlang being the winner (currently) for him.

How meta. Question about one of my answers. Did I just level up in this game?

Ok, I’ll pile on here. Elixir (Erlang) will use as many cores as it can get it’s hands on. It will cross machines, rooms, countries and continents to do so. You can call those a lot of things, to include threads, but they are somewhat different than what a C++ or Java programmer would call a thread. So in essence, Erlang is far from single threaded.

What I was saying there is that the performance of any single thread is low. Pitifully low compared to many other languages out there. If I’m computing something that is not parallelizable, like computing the millionth digit of the Fibonacci sequence it will take longer in Erlang than it will in many other languages.

That said, most programs are not doing long computational tasks where this is a problem. Very often code is waiting for an external resource or signal. In those cases Erlang is just as fast as every other language. In some cases it will be faster as it can handle those waits efficiently with it’s concurrency model (which acts like threads).

Super open-ended question, but I'll bite.

Erlang, or more specifically the Open Telecom Platform (OTP) portion of Erlang, was designed specifically for long-lived, concurrent applications. While the original use case was for telephone switches, Erlang/OTP can run on most hardware these days.

One of the best features of a concurrent, long-living platform that Erlang/OTP offers is the ability to hot-swap code modules without restarting the application. This allows your code to evolve naturally with theoretically 0 downtime whatsoever, pretty awesome.

Also, since Erlang was designed itself as having referential transparency/immutable variables and communication via message-passing, it makes Erlang extremely well-suited for concurrent systems. It was essentially built to do exceptionally well at concurrent problems.

To be fair, I've only dabbled in Scala, but it's my understanding that the Scala ecosystem is attempting to build in some of the same patterns that Erlang has, specifically around Akka and decoupled message-passing.

Hope that helps! Really need more info into the details of your app to really help though.

I can only write my own experience with it. I did not give it up completely as yet (still have class of problems I believe I could solve by using it). So far I only managed to form some kind of opinion.

After trying it out and spent some time on it, I realized the potential, but it is still not clicking with me on how to do even some basic processing things.

I find that critical things are not explained anywhere in documentation and that concept is at some areas a bit constrained. It needs more explanation especially more explanation for people who come from OO and procedural worlds.

Yes, it is easy to get basic concepts, and write some more advanced suitable mickey mouses, but translation from real problems to functional thinking is not there. (first shock comes when finding out that there is no ‘loops’ and that ‘if’ is discouraged but you first read a more than half of the book to reach it if it is told at all). I have read 3 books about it and start getting impression that authors lie to us intentionally trying to push us to think in differently in order to sell but not explaining how to do it, just expecting if we get basic blocks we would naturally start building more complex code - let’s be honest - it does not happen - at some point I was left alone with absolutely no help or hint, and still do not have idea how to deal with some issues.

It kinda looks to me that is mostly suitable for problems that are on high scale and where process is break down in arbitrary complex selection (or rule based - because it is essentially rule based). But I cannot stand behind that claim as I do not know as much as I would like.

I believe it could be used much more like Haskel could be used more or Lisp can be used more, but personally languages that close the gap between OO and functional (like Rust) kind of promise more and are kind of more friendly. Possibly prolog inheritance has to do something with it. Its Elixir -> Erlang -> Prolog way of thinking. I never had use for Prolog after programming for 45 years (and for good of that time I was very aware of Prolog) but prolog used to solve certain class of problems that I never really needed it- possibly Elixir is just very modern way to package same thing. One of basic blocks here is forgetting everything. Erlang is perfect for telephony system as process can be stopped at any time at no technological cost. But these are not only problems to solve.

All of this is speculation and impressions, and would like to learn some more and see how it can be useful to me. For example I love to use AWK for some things and it is no less weird programming language. But with AWK I went from learning in 2 days to production code which now works in and out 24/7 on a significant mission critical process. I have spent a month on Elixir and still have no idea how to write useful program for me. I am taking awk as example because it is essentially rule based language as elixir is so they can be compared at some conceptual level.

Will add just one more thing - I know for example that CouchDB is written in erlang (which base language for elixir) and it is extremely good and well behaved system - but it is what I would call mile wide and inch deep - the operations are relatively simple and whole strength comes from being able to scale to arbitrary large demand and intercommunicate flawlessly. But there is no complex algorithms to fulfil. I am not saying here that some complex algorithms cannot be done in elixir but big question is what is class of problems elixir tries to solve as I am not seeing it clearly.

that my 2c why I am not using it more.

ps - added later - there is interesting comparison to ponder. In 2009 Ryan re-introduced the idea of using javascript at server side (idea was not original as netscape had it in mid 90ties - you could write both run at browser and run at server javascript). Since than node exploded like wildfire. It took maybe 2–3 years that everyone got aware of it. In 10 years it is system so big that you need a lot of time just to see its size not to mention to know details. How come that essentially bad programming language like javascript gets so much attention and essentially quite fine elixir with very interesting concepts unlike other that additionally solves some erlang problems (on a user side) does not get even a tiny fraction of attention. What is the problem here?

I can't offer a comprehensive answer, but my impression is that the different VMs make for very different semantics under the hood.

The Erlang VM offers ultra-lightweight processes, which makes the "let it crash" philosophy a no-brainer. Process isolation in Erlang extends to both heap and stack, which I don't believe is true for Akka, and makes both for safer code and virtually invisible garbage collection (at least compared to the JVM).

The biggest advantage I see to the JVM is the plethora of libraries that support it, and I imagine that array and matrix manipulation are much faster because Erlang doesn't offer mutable data structures.

I used to work with it at Ericsson (the company that invented Erlang) and contrary to what you may think, it isn't widely used. It's the usual politics of being worried that you won't find enough developers who know it, that it's strange, and that it's relatively slow.

Where we did use it was in the test environment for the LTE (4G) radio base station. We used Erlang to fake everything from other base stations (3G and 4G), UEs (User Equipment, basically phones), the core network nodes such as MME, and other services, like a DHCP server.

It was easily the best test framework I've worked with, and making new additions was a breeze. We used Common Test to run our tests which works really well for larger integration tests (it's too slow to be suitable for unit tests though, but to be fair, that's not what it aims to do either).

The process oriented paradigm works really well in an environment like this, where you have a large number of independent nodes that all communicate asynchronously. In our test environment we could spy on all the messages being sent and also intercept and change them at will which helped a lot in keeping the test cases readable and compact.

I would say that readability is one of the key strengths of Erlang actually. The code is rather WYSIWYG once you've gotten used to the syntax.

Specifically on the topic of OOM errors, there is no support for handling them after the fact in Erlang. In general, it's very hard to do this in an environment with dynamic memory management and green threads. The thing that will trigger an OOM error detection would most likely be a garbage collection, but since they are per-process in Erlang, there is no way of knowing whether the process detecting the OOM condition is the actual culprit. Also, any hook responding to the OOM would need to run in constant, pre-allocated memory, which is "un-erlangy" (it could be done, of course, but would require some custom approach.)

What you can do in Erlang is use the memory supervision library, subscribe to system monitor warnings about large process heaps, profile your applications with garbage collection traces* etc. There are also good load regulations solutions (such as Jobs) which can let you throttle incoming traffic in e.g. high-memory conditions.

When it comes to isolation in general, Erlang and Haskell provide great isolation by default, but there are pragmatic ways to subvert it. I tend to think that this is the way to go: offer an intuitive and useful default, but don't be too militant about trapping users into it; commercial development tends to call for dirty compromises now and then, and the people maintaining the code are adults and should be allowed to take risks. Erlang, for example, allows for user-provided C code to run inside the VM. That obviously voids any guarantees of isolation and real-time characteristics, and there are well-known horror stories in the community related to this. But when you really need it, it can be a godsend.

* Erlang's trace facility is amazing. The GC trace will let you know when GC kicks in, in which function, how much memory was reclaimed, and how large the heap is afterwards. It's easy to write a small program that identifies wasteful processes and points to the code segments that are most likely the cause.

So what happened? The world changed, and continues to change:

• Moore’s law ends,
• I am sitting in front of a 16 core SMP computer,
• It has more memory than I could ever use,
• It is really fast,
• I am writing simple networked & distributed services,
• Reliable code, not just features, differentiates,
• Scalability is standard, and not special.

Some years ago it might not have been practical to use Erlang because there is no mutable state and performance would suffer. Now distributed and network services are pervasive. At the same time these services tend to be much simpler, and there is new awareness that simple, safe, and reliable code (and systems) are differentiators. Languages built on Erlang, like Elixir, provide a familiar environment and toolset which allows programmers to adopt more easily.

1. We are currently using Elixir for development of a couple of production applications.
I am a programmer with Erlang background and switching to Elixir is rather hard, but I have a feeling that it's worth the shot. It's important to be ready to follow the releases and changes in the libraries up until the version one of the language.
2. It's good that non-erlangers pick basics of Elixir rather quickly, that Elixir fixes some things in Erlang, adds even more neat introspection while Elixir libraries provide handy DSLs for doing stuff being less verbose and more expressive; on the cons side of things — the only concrete aim of the language I see is being Erlang++ with nice syntax and extensive macro support and I can't get the *big* picture of language architecture (which doesn't mean that Elixir lacks one) and also, it's not that stable cause most of the developers develop their stuff against master. But hey, after all, it's only 0.7.0!
--
Hope that helps,
Jonn Mostovoy

Nope.

Erlang Virtual Machine (known as BEAM) is probably the best concurrency/parallelisation solution on the market. Not only does it use all of the system cores, it implements it’s own lightweight threads with custom scheduler upon them.

What you get is the system that can handle tens of thousands or even millions of threads on accessible hardware. That allows you to use Erlang processes (aforementioned lightweight threads) without really limiting yourself, while being sure that scheduler will handle their execution in the most efficient manner, while utilizing all OS resources.

It’s the best feature offered by the platform.

EDIT:

Question was merged, the original did not have the screenshot attached. The commenter means single-threaded performance of Erlang is not great - which is true. Erlang power is not in fast execution of code(that’s C++), it’s the ability to parallelize execution with low cost involved. However, claiming it’s slower than Ruby is dubious - see fast-faster-fastest (64-bit Ubuntu quad core)

I don’t think its a matter of suitably. Erlang has added features over the past few year, but is still the same language it was years ago. The Elixir language adds a few features over Erlang, but not many.

Personally, I think that José and Chris coming from Rails has influenced that exposure to the languages followed by some key contributors that help build the eco-system we have today (mix, Hex.pm, etc).

My experience has been that once designers see the language, many love it. The more noise, the more people investigate it.

Furthermore, Erlang had the stigma that it was for telecommunications with some barriers to entry like being functional and its different syntax. Functional language popularity is on the rise. With that and Elixir’s syntax closer to other modern languages, I’m not surprised its rapidly gaining popularity.

Elixir and Erlang have great features for concurrency and fault tolerance, it does not get in the way for a general purpose server side programming language.

I should probably mention testing also. When I first started looking at Erlang, I was not impressed with the way testing was done. Elixir resolved that by bringing a very usable testing solution into the eco-system.

The answer by John is definitely true, with respect to lightweight processes in Erlang that do not impact each other if one fails. Since Akka runs on the monolithic JVM, an OutOfMemoryError is not an event you can supervise.

That said, the clustering feature that has been rolled out in Akka 2.1 and 2.2 allows you to build clusters of JVM nodes that we believe will allow us to approach the "9 nines" of Erlang. They aren't lightweight processes, but they are isolated and watchable. Nodes can join and leave the cluster, providing increased uptime with less self-management as existed with the Remoting solution that preceded it.