More like "Elixir and Erlang". It's certainly interesting to compare the relative momentums of each language and think about why that may be, but I hope people don't see it as a zero sum competition.
I was intrigued by Elixir, coming from a ruby background, but one of the key points for me was the robust and battle-tested Erlang VM and OTP. And as I've played with my Elixir app, I've found myself looking at Erlang code.
Erlang is one of the main draws of Elixir, and conversely the enthusiasm around Elixir will be hugely beneficial to the Erlang community.
Excellent comment: it's definitely not zero-sum, but there is a bit of rivalry and duplication of effort. If someone's using ecto, they're using postgrex rather than epgsql, for instance. Elixir is definitely a gateway drug for Erlang, for many people. I think one of the things that José has done so well with Elixir is layer something on top of Erlang that adds to it without muddying what was underneath, if that makes sense. You can see Erlang sticking out in places, but what's on top if it fits there nicely.
Sure, Erlang has an issue with gaining forward momentum, but I feel like people are really overstating the momentum Elixer has.
It is easy to gain huge percentages of momentum (if you could ever measure that) when you have little to start with. That's the case with Elixir. That's the same situation languages like Factor and even Haskell saw seven years ago. The former is more or less dead and and the latter still never "broke out".
When Elixir is competing library-wise and ecosystem-wise with the likes of existing languages like Python, Ruby, Java, Javascript, and then some of its major selling points are in competitors like Go (though not 100%) or Clojure/Scala (which can leverage the JVM), it really, really has to distance itself.
As great as Elixir is, it is hard to make a bet on it ever crossing the threshold of "this is really cool" to something you can goto because library x y and z are available.
>> I feel like people are really overstating the momentum Elixir has
I don't think so at all. I see elixir gaining a groundswell of momentum very much like the early days of rails and node. Of course it's the beginning, but I see a whole different crowd of people interested in elixir - the "gets things done" crowd rather than the "this is cool/elite" crowd I see playing with factor or haskell (sorry, but it's true).
Elixir does not compete with Python, Ruby or JS - it solves a whole different problem, which is the "massively multiplayer" requirement the apps world is obviously moving towards. No-one I know likes Go or Scala. Clojure is a genuine competitor, you are right about that, but it lacks the ruby community spirit showing itself in elixir. Say what you want about ruby but its community moves mountains.
It's early, yes, but I know a lot of good rails devs who are embracing elixir and they're all "smart and gets things done" types. A lot of torque is building behind taking elixir mainstream, and there's excitement in the air. Time will tell, but it's a bet I'm increasingly ready to make.
I think it does, actually, though not intentionally. José Valim was a Rails core dev and as far I can tell he took on Elixir to address concerns with performance.
In http://elixir-lang.org/blog/2013/08/08/elixir-design-goals/ he says, "Given my previous background in Ruby, it is natural that some of the constructs added were borrowed from Ruby. However, those additions were a by-product, never a language goal." He follows this with a comparison of Ruby code to Elixir.
I'm heavy into Ruby but looking forward to Elixir gaining strength.
You may be right, but what I meant is that every rubyist i know looking into elixir is after massively persistent connections. Websocket, basically, to thousands or more clients. They are leaving ruby because it simply cannot offer that (I don't care what DHH says. No-one big is doing EM WS in production, nor should they).
Phoenix has a steeper learning curve than rails but is addressing the new paradigm of persistent duplex connections. Rails remains unapologetically a request-based framework, ActionCable notwithstanding. That is fine. 99% of today's apps don't that. Right tool for the job! But to me, the future is very clear.
I'm heavy into ruby too, but speaking pragmatically, it and elixir are playing different games in different ballparks. That's why I said they don't compete.
4) Functional paradigm- encourages decoupling of code by forcing state to be passed around explicitly as arguments, this also aids unit testing, it also reduces bugs further
5) Instant "forking" without having to worry about thread safety, and good semantics around it
6) Potential 99.999999999% uptime reliability (thanks to Erlang's OTP)
7) Hot-swappable code upgrades with no downtime
8) Pattern-matching reduces the amount of "switch logic" code greatly. In Ruby code I often saw complex logic branches with no test coverage- it's easier to cover those in Elixir when every "branch" is a different pattern-matched function
> A bunch of neato things such as build-your-own-sigils, which felt even more "Ruby-like" than Ruby's own capability
I like custom sigils, those are pretty cool, e.g.
def sigil_i(string, []), do: String.to_integer(string)
But, having to put that char into the method name rather than argument, doesn't that limit the characters that you can use? Seems like would be better as arg.
I believe for the sort of thing typically done in these sort of languages (which usually boil down to doing lots of string processing) Elixir may well be 10x faster.
The reason?
Lack of dynamism.
Function calls in python/ruby? SLOOOOOW
Function calls in Elixir? Hella fast, because it's all resolved at compile time, there's no dynamic lookup, no creating a locals dictionary for each call, etc.
(PS: Most typical web frameworks make a LOT of function calls - all that data sanitizing, templating, and formatting has to happen somewhere)
It's true that Elixir is slower if doing numerics heavy code since it can't just call out to a highly tweaked numeric library like NumPy.
(This is all talking single threaded, of course. With a parrallizeable task you won't even be in the same zip code.)
Erlang and Elixir are both dynamically typed and do dynamic dispatch.
Erlang does not know the types flowing through a call site in advance and therefore has to do dynamic dispatch.
In particular, Erlang has a "code server" that all calls throughout the system must thunk through, versus a statically typed language where a call is optimized to a single JMP instruction. Smarter JITs, like Java's HotSpot, can also do this, and HotSpot is smart enough to inline both virtual and dynamic dispatch at runtime. BEAM can't.
Erlang's closest thing to a JIT (HiPE) cannot inline calls across modules, has no support for deoptimization, and is in effect a naive, crappy, AOT compiler which does the bare minimum to work in an otherwise dynamic environment.
Source: I made this... it was basically Elixir before Elixir:
These days I like languages that can actually avoid this overhead through the use of static typing, like Rust.
Note that it isn't necessarily bad that Erlang works this way. When it comes to Erlang's core strength: coordinating the concurrent activities of a massive number of processes/clients, it really does shine. Just don't use it for anything CPU-intensive.
6) Potential 99.999999999% uptime reliability (thanks to Erlang's OTP)
I don't have much understanding of programming language internals but why we don't thing see low level stuff like distributed file system written in Erlang.
I genuinely interested in knowing why this is not tried by someone?
It will be a long time before we're rid of EventMachine. It's served (relatively) well considering, but I wouldn't say any of us are fans or would recommend it for new projects.
Hi. I'm Dave. I really like Go, and I write and maintain a real-time and turn-based multiplayer game backend.
I liked Elixir a lot too, but when trying to pick the right tool, the learning required around Elixir/Erlang, the VM, and OTP didn't make sense when writing a production system that needs to handle 1000 req/s or more with a small staff. Go handles what we do fantastically.
Actually OTP makes even more sense though. WhatsApp processes billions of messages per day and they only have 10 or so engineers working on the backend.
At any large scale what becomes more important is fault tolerance. Even though Go has goroutines and sane and modern concurrent IO handling, goroutines still share memory. So then even a super fast 1M req/s system is no good if it is down 50% of the time because it crashed.
Sounds like you're already committed to Go, but just wanted to make the case. Concurrent, fault-tolerant, highly scalable systems is Elixir's sweet spot.
[edit] One more, great talk from the Elixir Conf on how Martin Shurrer used Erlang to build a multiplayer card game. This one is particularly good because it deals with scaling, game states, and is very practical:
http://confreaks.tv/videos/elixirconf2014-otp-in-production-...
To be clear, I really liked both Elixir and Erlang. It's just that purely functional programming, the Erlang VM, OTP, and so on all required learning, and so introduced so many possible points of failure.
Go was familiar from the jump, and easy to reason around coming from primarily Objective-C, C, Python, and C#. Considering timeline, it wouldn't have made sense to be so behind the learning curve.
With more time or breathing room, I think Erlang would be a space I'd jump into with both feet.
Edit: I know Martin through common colleagues and have worked with him in Austria. He's a great dev, and that was a good watch. Thanks for the link.
"I feel like people are really overstating the momentum Elixer has."
I think the real problem is overly broad generalizations about languages in general. I'm just a sysadmin, so I have to keep up with the big picture overview of things, and one thing I have learned is that certain languages have momentum in certain areas of application where they don't in others. The devs in one area see language A as awesome and language B as sucky for their work, while the devs in another see it the opposite. Elixir/Erlang for example has concurrency that is only challenged by a small set of languages like Go. (Henning Diedrich got 877k TPS with Erlang and VoltDB. )
Anyway, my point is that for those of us more specialized and deep instead of jacks of all trades, we need to keep in mind our biases when we speak so broadly about languages. Also, when it comes to momentum, some languages can pull others behind them. For example, I am recently fascinated with Racket, which seems to me a perfect way of pulling Scheme (SICP) into a modern setting. Elixir may have enough momentum that it brings Erlang with it, etc.
Have you explored Lisp Flavored Erlang (LFE)? http://lfe.io/ It is another way to participate in the BEAM ecosystem and might align well with your Racket interest.
> That's the same situation languages like Factor and even Haskell saw seven years ago. The former is more or less dead and and the latter still never "broke out".
Kind of a nitpick, but "breaking out" was never a goal of the forces behind Haskell, and in fact contrary to their stated desires. Much of Haskell's value was always (and continues to be) its variety of tools for expressing the semantics of the problem the code tries to solve — features which we now see spreading rapidly among mainstream languages. The rest of its value (and its primary purpose) was as a research tool for developing such features. There's still a lot of work to be done in exploring that frontier.
I thought the more prevalent attitude was "speak to developers like the wretched ignorant peasants they are." followed closely by "A monad is just a monoid in the category of endofunctors, what's the problem?".
There is a difference between blog posts and conversations about Haskell. The community is extremely friendly to beginners, but many blog posts are not, and most are largely geared towards experts familiar with the more esoteric terms. If you actually answer the "what's the problem?", explain your trouble, you will, with extremely high certainty, get explanations from people that are neither condescending nor deliberately obtuse.
Anecdote: I was at a dinner with Simon Peyton Jones once, and he was about as nice and kind and polite as could be, despite me not holding a candle to him in the computer science field. He was genuinely curious about my job as a consultant "in the trenches", selling coding time for money. I came away extremely impressed with him as a person. Hopefully some of that attitude gets passed on throughout that community.
The Haskell community is very friendly in general (same with OCaml). You will find a few "I figured out how to open a file in Haskell, therefore I am smarter than John Carmack" types, but they're not prevalent.
That said, if you have to understand a sufficient amount of math concepts to code in a language... that's an impediment. (Perhaps an empowering learning curve, to be sure.)
I don't think you're giving Haskell enough credit. I just went to a Haskell meetup last weekend and was very impressed by the attendance and engagement level, it was a very lively and interactive group. A lot of software companies are using Haskell now, I know Microsoft has Haskell code in production and I think Facebook does too. I really feel like the language is gaining steam lately.
Google also uses Haskell for Ganeti, their cluster-based virtualization management software. [0]
Why does Ganeti use Haskell?
Ganeti first used Haskell as an experiment when we needed a compiled language that could perform fast computations on cluster metadata. Eventually, we found that Haskell had advantages in its type safety that made it easy for us to develop better code with fewer common errors without having to write extensive “type-specific” unit tests. At this point, we decided to expand our use of Haskell.
As of January 2014, we plan to convert only “infrastructural” code (job queue, locking) that was already very complicated in Python to Haskell. We’ll continue to use Python for Logical Units, backend RPCs, and hypervisor, storage, and networking implementations.
There are two main reasons why Haskell constitutes a low barrier:
- Haskell doesn’t have any runtime dependency on the target systems.
- For setup, Haskell only requires a development environment.
Exactly, Erlang is a highly concurrent distributed system out of the box but this does not mean too much for Rails developers, on the other side the syntax is kind of hard to get used to. I think this is primarily why Elixir was created. I think if we see the usage or Erlang in the world it has enough momentum already and it proved itself with empowering startups like WhatsApp. On the top of that, the Erlang community is absolutely amazing. I guess I don't understand what the author means in terms of momentum. Is Erlang popular on Github? Certainly not. Should we use this to measure momentum? I don't think so.
Elixir is one of the best ways to program erlang. I learned erlang first, many years ago, and I don't really think of them as different languages. Yes, they have different syntaxes and yes Elixir has added features. But when I'm programming in Elixir I'm using the same part of my brain that loved programming in erlang. I think in the same way.
More importantly, I think, for some reason so many programmers just can't get past erlang's syntax. I've never seen any really good criticisms of erlang that made sense-- other than the syntax. While it was fine for me when I was doing erlang all the time I did spend a couple years away and find it frustrating again. So Elixir fixes that.
Further, there is no other language/platform that does distributed computing correctly, or on such scale, and with such battle testing. Haskell may do it correctly (I'm not sure) but it's very new. Go, Node.js, every "actors" library you can think of, they are single-threaded-thinker's attempts to scale, and they are not correct.
Yes, in computer science there is such a thing as "correct" and "not correct", and way too many young programmers seem to think popularity determines correctness.
IF you haven't learned Elixir and you want to write code that runs on multiple machines without a lot of hassle, and you've seen how tough this is to do on other platforms, head over to http://elixir-lang.org and learn. It's really a delight!
Edit: Fixed some typos. Oops. Want to add, my intention is not to bash languages like Go. Go has some good ideas and is appropriate for certain use cases. It's just frustrating to see these things being pitched as "distributed" when they have not incorporated the lessons learned building erlang over 20 years ago, and the 20+ years of development since.
It really is concurrent and at a fundamental level, eg: it's supported in the VM. The JVM does not support it. It's not a language feature that simulates concurrency and it's not throwing the baby out with the bathwater and just using events (node.js).
The book recommended by the other replyer is probably good. I'd also suggest you check out Joe Armstrongs thesis or his ProgPRog book "Learning Erlang".
There are many necessary things to do things right. It's not a single feature. Erlang the language, the VM, the OTP platform are a collection of all these choices...
I understand and appreciate your enthusiasm and excitement over the Erlang vm, but you really shouldn't misrepresent what's possible with the JVM, the Go VM, or even with Node.js.
All support parallelism as well as concurrency, and all can do so with an actor paradigm (and predictably, Node's support is the weakest).
Erlang's solution is more exciting because it offers a transparent mapping between local and remote code, so long as "transparent mapping" ignores the performance overhead.
> ou really shouldn't misrepresent what's possible with the JVM, the Go VM, or even with Node.js.
He's not saying it isn't possible. Everything is possible with assembly, it doesn't mean assembly is a good choice for distributed programming.
> and all can do so with an actor paradigm (and predictably, Node's support is the weakest).
There-in lies the problem. The main benefit of actor programming programming is about programming with isolated actors. Such that one actor doesn't see the heap or memory of another one. Because at a large enough scale fault tollerance start to become more important than other things. If a single goroutine panics and takes down other 100K connections, it doesn't matter that it is lighting fast or cool or whatever, it will be broken.
In other words langauge that claim "Erlang-like concurrency" never get is right. They put a queue and a thread together in a class and call it "Erlang". But that is not Erlang. The closest thing to Erlang's model is probablh the operating system with its processes.
It even makes sense to think of your code in that way -- your langauge platform is an OS for your code. If you write in Erlang or Elixir you are writting on a modern sane OS like Linux, Windows, OS X. If you are running with pthreads or goroutines, you are back to Windows 3.1.
> In other words langauge that claim "Erlang-like concurrency" never get is right. They put a queue and a thread together in a class and call it "Erlang". But that is not Erlang. The closest thing to Erlang's model is probablh the operating system with its processes.
That's not really right.
> It even makes sense to think of your code in that way -- your langauge platform is an OS for your code. If you write in Erlang or Elixir you are writting on a modern sane OS like Linux, Windows, OS X. If you are running with pthreads or goroutines, you are back to Windows 3.1.
That's not true at all. I have no idea why you'd try and use such an emotionally loaded argument. Just earlier in your post you made a point that different tools have different sweet spots.
The Actor model is useful for some things, but not all. There are many effective techniques for parallel computation that do not rely on the actor model. There are several ways to model distributed computation that are not the actor model.
My principle objection to this entire thread is that people are making a mistake ignoring these other techniques and in fact directly misrepresenting the state of the art for the sake of their rhetoric about Erlang. By and large, the Erlang community itself tries not to do this!
The problem is that there is a leaky abstraction of concurrency in Node and Akka. Anytime you want to do some blocking computation or IO, you put the whole application at risk. This even applies to garbage collection. There's a whole class of things that you shouldn't do in that concurrency model. You also have to be sure that none of the libraries you use are doing these things. (zealots will say "don't do blocking IO in Akka!", which missing the point entirely)
Erlang's solution shines (in addition to reasons you cite) because of its efficient scheduler. That's something that you can't have in another language without essentially building Erlang itself.
> Anytime you want to do some blocking computation or IO, you put the whole application at risk.
It is true that you should not do this, and it's a fair point. Of course, you don't do it with Erlang either! Erlang carefully takes all file I/O out of their actor model and has it so that one (and only one) process can interact with a file handle. Operations to this have to be serialized by the actor. Since there is only one implementation of I/O and it's non-blocking, this works fine, but if your application is an actor pipeline you run exactly the same risk as your mailbox overflows. Needham's Duality is real.
And naturally that ignores the fact that JVM concurrency and parallelism can handle that outcome perfectly well (and in fact Akka appeals to these primitives). It's absurd to suggest that java.util.concurrent doesn't have great tools for parallel anything, let alone parallel I/O.
Golang, by the way, doesn't have this restriction. The runtime supports non-blocking, parallel-friendly I/O from the ground up.
And as for Node.js, well the general abstraction here is the most parallel of all. I'm not a huge fan of it and I agree it's a bit leaky, but Node's cluster stuff is serviceable and used by many. You cannot argue the actor model is essential, threadpools and actors ultimately model the same process and as Go has shown can do so with similar sharing semantics.
Finally, Erlang's scheduler is not black magic nor an arcane work of wisdom. It uses well-known, well documented principles and techniques. Quite frankly, its not the secret sauce of Erlang. Erlang's secret sauce is the HUGE some of very good code for building a distributed system with all the robust goodness that OTP provides.
Erlang's great, Elixir is interesting (albeit it took one stinky old syntax and exchanged it for another stinky syntax). I wanted to reply to that prior post and talk to why Erlang has a magical recipe for distributed code, not parallel code. Quite frankly, Erlang's parallelism story only makes sense in the context of its decision to make remote and local execution indistinguishable at the call site.
In the context of sharing IO, Erlang does have the same problems. I was however referring to IO in the sense of "I'm going to block until I get a response." And not have to deal with callback shenanigans (be it futures or callbacks). Golang does solve these issues fairly well except for GC issues (which I've heard have gotten better).
> I was however referring to IO in the sense of "I'm going to block until I get a response." And not have to deal with callback shenanigans (be it futures or callbacks).
Callbacks and futures are very different modeling techniques and I'm not sure why you'd suggest they're inherently inferior. They have their uses just like the Actor model.
People obsess on the existence of blocking I/O (proponents of Node.js do this too) and I find it strange that this is still a subject of conversation. It's by and large a solved problem.
> Golang does solve these issues fairly well except for GC issues (which I've heard have gotten better).
Golang's GC issues were no to much about GOMAXPROCs as just needing a really good optimization pass. As a younger language, it's unsurprising it needs some time to reach production readiness. Erlang has the benefit of many years of testing in anger.
In Akka, multiple actors share a pool of threads. This has a lot of implications:
1. Garbage Collection. Garbage Collection on the JVM is not isolated to actors. One actor causing a lot of memory churn will prompt a garbage collection and prevent all other actors from executing until the Garbage Collector is finished. BEAM (the erlang VM) has per process (aka per actor) garbage collection, so actors will not interfere with each other during garbage collection.
2. Shared Memory. Since the JVM does not provide proper isolation guarantees, actors can in fact access shared memory. Safety in concurrency is accomplished via best practices rather than guaranteed by the VM. The BEAM VM does not allow shared memory. It is impossible for two processes to write to the same memory. While this matches the convention in Akka, it is enforced at the VM level.
3. Scheduler. In Akka, actors are oversubscribed to threads. That's why you can have hundreds of thousands of actors on a single system. The abstraction is great, but the implementation means that calling Thread.sleep is going to tie up a thread. If you do that often enough then all the threads will get tied up and the rest of the actors will be unable to make progress. The BEAM VM handles this scheduling at a much lower level. Calling sleep on an Erlang process is no big deal. While sleep is a contrived example, the effect on the ecosystem is pretty big. Using a blocking HTTP client on Akka is a bad idea. You have to use something like Dispatch or Spray which is essentially callback based (via monadic Futures). In Erlang, you just make the blocking call and the scheduler takes care of it. Since the synchronous code is easier to reason about than asynchronous code, the Erlang solution is simpler, easier to maintain and often more performant.
I've spoken with a number of seasoned Scala/Java programmers who basically tell me "Of course you shouldn't do that, just do X or Y". With Erlang, I find there are fewer situations where you need to be an expert to avoid screwing things up.
3 is true because Actors are implemented on top of a language and runtime that hasn't decided to implement actors and ONLY actors. Just like Haskell, you can in fact mix paradigms of concurrency. This is generally regarded to be a positive thing! But of course it does mean you need to understand how the semantics interact.
But it's weird to call out actors oversubscribing to threads in Akka as a bad thing when that's exactly what Erlang's runtime does! And by the way, it's not difficult for even C to match the classic "quarter million execution threads" claim. Java certainly can with competitive memory overheads.
The problem with Akka oversubscribing is that it doesn't actually have control over execution. It can't pause an actor in order to guarantee fair scheduling. It's similar to Node and the event loop in that regard. That's a big deal in my book.
Competitive memory overhead in the Erlang world for a quarter million processes is 700MB (just sleeping). You can't do that with POSIX threads, where the default pthreads stack size on Linux is 2MB. Java adds more overhead on top of POSIX threads. As far as tuning PTHREAD_STACK_MIN on x86 is generally 16K, which is quite a bit bigger. So either you aren't in the same ballpark (factor of >5) or you have basically built a scheduler yourself (which is what Akka did).
> The problem with Akka oversubscribing is that it doesn't actually have control over execution. It can't pause an actor in order to guarantee fair scheduling. It's similar to Node and the event loop in that regard. That's a big deal in my book.
I mean it can if you use their libraries. You just suggest that because calling out to a different I/O library is possible that we should only evaluate it in that context. This is basically a condemnation of ALL languages that host multiple abstractions.
> or you have basically built a scheduler yourself (which is what Akka did).
Riiiiiiight.. so... what's the problem there? Someone did what the erlang folks did on the JVM. Why is that used as a refutation here?
> As far as tuning PTHREAD_STACK_MIN on x86 is generally 16K, which is quite a bit bigger. So either you aren't in the same ballpark (factor of >5)
My comment was in regards to building a scheduler yourself (erlang doesn't have that many threads of parallel execution either) or using a technique with less demanding semantics like Fork-Join.
A lot of people have mixed up a lot of concepts here in the attempt to discuss why they like Erlang, but the truth is that it can't be nearly so efficient at scheduling and executing parallel computation as the average Java program appealing to java.util.concurrent, but is tuned for greater concurrency. It's also true that for some classes of computation Erlang's strategy works great, and for others it'd require substantial engine improvements to make competitive.
The impression given on this thread is that Elixir is the answer. I don't like that impression being left for people new to the discipline, because it's not how most people who are good at distributed systems or massively parallel AND concurrent programming think about the problem.
By not having preemptive scheduling, there are a whole lot of hoops that have to be jumped through. Spray.io is a disaster in usability in my opinion, for example. I've yet to find my code simpler and easier to maintain and debug when I use callback based async techniques. That is, however my opinion and personal taste. Others may disagree.
The difference is the scheduling. In erlang, processes are preemptively scheduled, in akka they aren't. Erlang goes to great lengths to avoid one process from starving another. With akka you have to go to some lengths yourself to prevent starvation (e.g. preventing blocking calls in your event handlers).
Check out Seven Concurrency Models from Prag Prog. It does a good job of going over concurrency. It doesn't explicitly go over Node.js or Go's concurrency model, but it talks about the pitfalls of concurrency with shared memory and it also goes over the actor model, which is Erlang/Elixir model as well as Scala's Akka.
Haskell's not new compared to Elixir which got it's 1.0 release last summer. It is new compared to erlang which has been around longer than the startup CEO in silicon valley has been alive. :-)
Also "new" is one of those things that I think changes perspective with age. Probably when you're younger newer things seem more established than when you're older and looking at a longer time horizon. No offense meant to haskell. :-)
I don't really know how to compare these things since I don't think Haskell was really very useful at it's 1.0 release, but Haskell 1.0 came out in 1990, 4 years after Erlang, they're both pretty old.
This is the same feeling I have. Well mostly toward Erlang. I was at an Erlang meetup and I've mentioned that the reason why Ruby is popular was because of RoR. Erlang needs a killer framework. A web framework would be a good choice since RoR have shown that. The consensus I got from this was basically Erlang doesn't need a killer software and the majority at the meetup thought the idea wasn't valid.
Here come Elixir and so far it have decent momentum. It got mix, ecto, etc.. tools. And all of a sudden the creator started to contribute to Phoenix framework. It got 2 books now and an OTP books coming out.
In general, I think Elixir is executing pretty well. If pheonix hit 1.0 that is comparable to RoR and can make restful service dead simple with oAuth, elixir might have a chance.
edit:
From what I've gathered:
The blog posts and online community of Erlang is mostly technical. The community at the local meetup is very against new ideas, they're stuck in a cycle of continuing the same path while complaining about how to get adoption rate up for Erlang...
Erlang's killer framework is OTP. Not everything is for writing webapps.
I'm happy for Erlang to never have a decent web framework. I prefer Erlang (I don't write webapps) but point everyone to Elixir and Phoenix if they want to do webapps.
I don't agree with this. Erlang has already frameworks but that is not the selling point of this language and environment. For me the reason to use Erlang is the concurrency patterns and the tooling. RoR is great to get you off the ground but when you hit bigger scale you have to replace it with something that is more memory efficient and supports high number of concurrent connections. Several companies proved this including Twitter, Opscode etc.
Erlang on the other hand lets you to use the same environment from day 1 to the time when you have 10M+ active users. You have to work on it but it is possible and there is no need to ditch the entire system because you got popular.
Every time I read about it, I thought, it is surreal more people have not heard of this.
I have considered in the last year learning Erlang 1 or 2 times just after stumbling upon it again in my history and being very impressed by feature lists and basic stats.
I even saw a sample Elixir project. Very cool stuff.
One part of that, and Nitrogen, that I really disagree with is "writing HTML via Erlang": the number of people who can hack on a template that is HTML with some processing instructions exceeds, by orders of magnitude, the number of people who can write Erlang.
I think in part this is because there are a few very vocal elixer proponents here on HN and this being the site where those people with scaling issues and 'erlang' style problems (which most web stuff actually is!) converge the uptake could be substantial. Erlang doesn't nearly have the 'hey look at me, I wrote a language' component but it just quietly excels at what it does (reliable, scalable). Elixer being targeted at the VM it is very well possible to have the best of both worlds.
I'm curious what will happen in the longer term, if at some point the 'upstream' providers of the erlang ecosystem will take notice of elixer and will start to cater to it and then maybe actually adopt it. Until then I'm on the fence, elixer could be great but it also could end up being abandoned as more and more warts in erlang are taken care of.
And most of those warts are cosmetic rather than real problems, the lack of libraries will hurt both languages just about the same and it would be much nicer if new libraries were written with interop in mind.
That way they will have staying power regardless of which language will eventually become dominant/stay dominant.
The erlang vm and ecosystem are very well thought out, battle hardened and solid beyond what most programmers that came into the profession past say 1998 or so are familiar with but it is clearly showing its age and elixer solves some of those problems. A more open process around erlang itself could easily take the wind out of elixer's sails.
Time will tell, it sure is interesting.
And thanks David, excellent post.
edit: it could actually be that elixer will drive developers to erlang in the longer run, the syntax is a minor nuisance easily understood after a little bit of work and the 'strings' issue is mostly a different take on an old problem that you can either work around or simply accept as part of the deal. It can throw you for a loop but not worse than the things other languages will force on you and if you think about it is actually an elegant solution, re-use the same data structure to make life easier.
If under the hood those lists would be replaced with something like the clojure ones you might be able to get rid of the performance issues entirely without affecting the code already in production (unless it was C code operating directly on internal structures of erlang).
They've gone as far as making 1 in 8 tracks at Erlang Factory about Elixir. They had José give a keynote last year and participate on a panel this year. Robert Virding (one of the creators of Erlang) is fairly active in monitoring (and participating) in the elixir mailing lists. Granted, there's always a small tone of "get off my lawn", but that's just entertaining :-).
I've mentioned this before but I'll daybit again. Protocols and Macros are the game changer. The Enumerable protocol absolutely changes the way you write code and solve problems. Doing the same thing in Erlang is just not the same.
As huge fan of the Elixir language I think this article missed the point.
Elixir is gaining popularity _because_ of the Erlang VM and libraries. Yes, macros, protocols, syntax, etc may attract a first glance at the language, but I believe people stay and evangelize Elixir because of the power of Erlang/OTP.
Likewise, I think Elixir popularity will only drive Erlang, Joxa, and LFE popularity forward as the initial roadblock of grokking the Erlang VM and how OTP works are overcome.
Exactly. Just Elixir build on say Ruby VM or Python VM would not be appealing. BEAM VM is really a marvel of engineering. Telling others that yes it provides lightweight processes which also have isolated heaps is often met with disbelief. It is almost magic.
Given I had no knowledge of rebar3 before clicking the link, it took me a while to discover what it actually is.
There is no descriptive text on the landing page aside from "Build Better Erlang" which i guess narrows this down to some sort of erlang developer tool. The Getting Started page has no mention of what we are installing actually does aside from a snippet in their console output log "you can use rebar to build OTP-compliant apps". So its a build tool? Not until "Basic Usage" do I find out in writing what rebar potentially is:
"Rebar3 comes with templates for creating applications, library applications (with no start/2), releases and plugins"
So it's a project templating tool? Does "comes with" mean it has more functionality than just templating? On the sidebar I see some terms that lead me to believe it can do more than that but I would love something on the landing page that told me exactly what the tool's purpose or function is.
From my understanding it is a tool similar to Leiningen?
Yes, pretty much. I think we went short on the rebar3 descriptions just because of how known 'rebar' is as a household name. Go to almost any Erlang project, and you'll find 'rebar' or some variant.
Rebar3 is the next version of it.
But you're entirely right, the page and documentation is lacking to people unfamiliar with the Erlang/OTP ecosystem.
I had a brief look at Erlang in my spare time. Time passed, and I would have returned to it at some point, but then Elixir appeared on the radar, and it appears almost as a refreshed, improved Erlang, an Erlang 2.0. Well, why would I learn yesteryear's implementation instead of a modern implementation? So, I looked at Elixir, and now would need an unlikely compelling reason to look back in Erlang's direction with any serious effort. When people talk about Erlang, they talk about telephone switches and data stores - I'm never going to be hired to build either, how many are? Elixir being used for more modest feats of engineering makes it sound more appealing and accessible to the mortal majority, hence building momentum. That said, I've just looked at the roles advertised at a large London tech fair - two Golang, zero Elixir, zero Erlang, numerous .Net and Java, countless Javascript. Long way to go for new languages, and London feels excruciatingly risk-averse.
That's funny because JavaScript could be considered a new language (unless you were counting the "JavaScript, HTML, CSS knowledge useful" descriptions). Languages take time, two Golang jobs is already pretty good given how young a language it is.
Its popularity increasing doesn't make it a new language. If you spend seconds on a web search you'll see that two is pathetic compared to elsewhere - I'm commenting on London there, not Go, or Elixir, both of which I would love to use, hence my grumbling.
JavaScript is not a good comparison. Say I didn't like JavaScript, I can't just start writing Python for the browser. I have a choice of either shipping a product or not. So many learn, know and use it because they have no choice.
Trying to put together cowboy, poolboy, a circuit breaker, a database driver, erlydtl, and various and sundry other pieces, for someone not well versed in Erlang is a losing proposition.
How so? A framework can very much be (and often is) a reductionist endeavor: the sum of its parts connected by entry points. Particularly ones that are loosely coupled, as the one you alluded to (Chicago Boss) is
If someone is not well versed in Erlang, they should probably learn Erlang before starting a project in it. Chicago Boss still makes implicit much of OTP, the process model and records that it's easy for beginners to jump in, though.
Their friend, using Elixir, will at least have something up and running in short order.
Once again, this is just as applicable to Erlang.
A package management system, “hex”.
Do people even know why they want/need a hundred language-specific package managers anymore, or is it just a cargo cult thing to do? No, a module system, a dependency resolver (Rebar) and release management may push you out of your comfort zone a bit compared to the typical do-everything package manager blob, but it's very much doable.
Ecto database driver, with Postgres as the first database integrated (yay!).
Ecto looks more like ActiveRecord, but there's nothing particularly wrong with BossDB. The fact that BossRecords are serialized as proplists means you can perform relatively complicated operations by using list comprehensions alone. Oh, but you have to learn some Erlang. No avoiding that.
Ecto migrations.
I might grant that. BossDB migrations aren't particularly advanced. Not sure how well Ecto fairs in to it.
Porcelain, for working with external processes, where Erlang is somewhat lacking
Latter is old, but the point remains. Port drivers and NIFs can easily bridge the gap from the Erlang VM to the host OS, and it seems that Porcelain uses exactly the former, at least.
No, they aren't, they were "the simplest thing that possibly worked" for my needs (I wrote that code).
One problem with boss_db is that it uses some heavy duty compiler magic that none of the "pure Erlang" kinds of folks really want to touch because it produces un-Erlangy code. This leaves it in a no-man's land: the Erlang people don't want to deal with it, and the people coming in from Ruby or whatever are just going to go straight to Elixir which looks more familiar anyway.
IMHO when Ericsson decided to remove "experimental pmods" support from Erlang in version 16, the compiler magic in ChicagoBoss turned from "oh cool" into a liability. Ericsson's development team did release a workaround example, but the whole process how this went down left a sour taste in my mouth.
My wish is that Ericsson's Erlang development team became more transparent to the outside world, shared their bug tracker, code reviews (Go team does this wonderfully) and did all development in the open. Then we would not have these situations https://github.com/erlang/otp/pull/687 and it would save me ton of time couple years ago chasing after ssl bugs.
The Ericsson team does plan to open up things like that.
But pmods shouldn't be used like an example of them going against the community in driving the language forward. Very very few people in the community objected to their removal. Many of us were happy and thought it should have happened much earlier.
> when Ericsson decided to remove "experimental pmods" support from Erlang in version 16, the compiler magic in ChicagoBoss turned from "oh cool" into a liability.
It caused a bit of hassle, but not much, really. It was a feature that many Erlang people did not like much in the first place, so heavy use of it put them off to begin with.
I agree with you that it wasn't that much of a hassle technically, just wish that the announcement was done with more transparency instead of "OTP Technical Board" met somewhere and this is what was decided http://erlang.org/pipermail/erlang-questions/2012-October/06...
Reminds me of Microsoft's .NET development process from 10 years ago, huge corporation drives development of a platform behind closed doors with very few people from the outside having any idea what is coming in the future.
The implication here being that the Ruby folks mostly care about surface convenience, with not even using parser transforms to provide parameterized modules (remember, one of the reasons people laud Elixir so much is its metaprogramming support) to overload the language a bit and provide ActiveRecord-like patterns being enough.
It's not really an indictment on Erlang, though. The situation you present is unwinnable.
That this post has > 100 replies (good or bad) heartens me. I would be happy to see more from erl or exrl. Both are phenomenal achievements. I'm only saddened that erl doesn't move faster to modernize its obvious, and easily rectified shortcomings (modern strings anyone?).
Adding hashes to erl is a good start, and joeerl seems very open to more. There is certainly more to come in both camps, and that's good for everyone.
Elixir needs a good IDE with code completion and jump to definition. There are awesome Erlang plugins for Eclipse and IntelliJ IDEA, but for Elixir I am still hacking in SublimeText and the lack of those two functionalities slows down the process considerably, from what it could be.
A bit like lisp the metaprogramming aspect of elixir allows for really rapid domain customization with out needing to have your changes approved by the core team. I think this on top of interop with existing erlang libraries and the scalability of the erlang vm model put elixir in a really good position to have presence if not in web dev overall then atleast in areas that in the past would have been grudgingly done using erlang instead of scala or whatever for scale reasons.
> Being, among other things, a “web guy”, this is particularly noticeable to me, and perhaps less so to people using Erlang for what Erlang traditionally has done well.
What are the things Erlang has traditionally done well? In what domains is it generally used now?
I actually wrote about Erlang's "strange birth" - for an open source language, at least - here: http://journal.dedasys.com/2009/06/18/the-erlang-paradox/ and what it has meant for the language. Basically, that it was born into a production environment and therefore very difficult to change much once it was released into the wild.
Well, Erlang has kind of a cumbersome syntax, and it is hard to learn for someone who has never seen a functional programming language.
IMO Elixir does a great job at reducing the inherent complexity of the Erlang syntax, while keeping its powerful features (Erlang-procs, horizontal scalability, fault-tolerance).
As someone fairly entrenched in the Elixir community, I think the syntax is the wrong selling point. Macros and protocols add far more to the language. The Enumerable protocol (along with Enum and Stream modules) is reason enough to my mind to use Elixir over Erlang.
I think syntax matters more than some would like to imagine. I tried ruby, erlang and elixir. I went with python over ruby, lisp over erlang and I am playing with lfe (lisp flavoured erlang) over elixir. Function is important, but if you get most of it, why not choose the best syntax as a second factor in deciding? Besides, all the 'end's in elixir play out in my head of somebody ending all sentences with 'like'.
The great thing about the Erlang/Elixir/LFE/etc. ecosystem right now is that, since all these languages leverage BEAM, they're all (theoretically at least) compatible with one another. Right now the tooling isn't quite there yet (trying to manage non-Erlang dependencies with Rebar or non-Elixir dependencies with Hex isn't quite as intuitive as I'd personally like), but eventually, I'd expect it to be possible to mix-and-match BEAM-based languages freely, using the right tool for the right job without having to fiddle with microframeworks or FFIs or other such things?
This is already possible with other VM-centric ecosystems (particularly the ones surrounding the JVM and the .NET CLR), but it feels like the BEAM ecosystem is making that sort of interoperability more of an explicit goal.
> Well, Erlang has kind of a cumbersome syntax, and it is hard to learn for someone who has never seen a functional programming language.
Ok, the syntax is weird (and sometimes infuriatingly so), but I didn't find it that hard to learn, and I had never seen a functional language (I came from mostly PHP, with some perl, and a small amount of C and/or C with a C++ compiler, and a little bit of Javascript). Single assignment is new and different, but really the only thing that really causes problems with is something like a for loop; and you learn the two or three ways to do a for loop differently pretty quickly. C, Perl, PHP and Java all have function pointers too, you just don't use them as often.
The important thing is starting to learn Erlang on a project that has a lot of concurrency, so you're making that part of the project easier in exchange for having to learn to think a little differently.
I think people who are professional programmers should be able to easily get over one syntax or the other in order to gain access to something powerful, but the reality is that it does seem to matter. I suppose it's better to deal with that reality rather than gnash one's teeth about it.
I think they should keep the "end"s, but they should say what they end! "end function" tells me that a function ends here. "end if" tells me that an if statement ends here. "end" is just equivalent to "}".
Some Ruby (and Elixir and Julia and other languages that use `end`) will just add a comment at the end of the `end` if they want to be more explicit about it. For example:
def foo(bar,baz) do
...
end # foo
This brings me to why a bare `end` makes more sense (in the case of Elixir, at least): because every use of `end` corresponds to a `do`. The above code is basically equivalent to `def foo(bar,baz) { ... }`, since `def` takes a function specifier and a block as its arguments.
If you really don't like `end`, you can also (at least with Elixir) use the shorthand form:
I was intrigued by Elixir, coming from a ruby background, but one of the key points for me was the robust and battle-tested Erlang VM and OTP. And as I've played with my Elixir app, I've found myself looking at Erlang code.
Erlang is one of the main draws of Elixir, and conversely the enthusiasm around Elixir will be hugely beneficial to the Erlang community.