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.
1) Immutable data throughout- prevents certain classes of bugs
2) 10x faster- obvious benefit
3) Actual macros- the ultimate metaprogramming: http://elixir-lang.org/getting-started/meta/macros.html
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
9) A bunch of neato things such as build-your-own-sigils, which felt even more "Ruby-like" than Ruby's own capability (or lack thereof) here: http://elixir-lang.org/getting-started/sigils.html
10) Trendy Actor model built-in from the get-go ;)
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.
Given Erlang is sometimes slower than Python [1] I am surprised if it's 10x speed improvement over Ruby.
1: https://news.ycombinator.com/item?id=9417453 (start at last comment & work up)
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 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.
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?
If your're looking for more traditional server stuff, there's RabbitMQ.
I get a lot of recruiting interest from my time at Powerset as an erlang engineer, from the most surprising places. Game companies come up a lot.
Please put down the kool aid. If you can't back statements like this up, you're not helping anyone.
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
http://www.bigdatalittlegeek.com/blog/2014/7/10/ruby-vs-elix...
Are you kidding me? Look at Pusher, which is literally EM sitting behind Route 53
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.
Now you know someone. :)
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.
Also theres a good writeup on how Erlang was used for some of Call of Duty's infrastructure. http://www.erlang-factory.com/upload/presentations/395/Erlan...
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-...
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 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.
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.
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.)
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.
[0] https://code.google.com/p/ganeti/wiki/GanetiFAQ#Why_does_Gan...
http://devintorr.es/blog/2013/06/11/elixir-its-not-about-syn...
I think it's silly that we have a generation of programmers who are unwilling to learn a language without a C or Ruby like syntax.
But I must admit that I find Elixir easier to read and more comfortable than Erlang.
Crossing the Chasm strikes again. In general, grabbing the early adopters doesn't inherently mean you'll be successful.
(Not that everyone wants to cross said chasm. Haskell's motto has been 'avoid success at all costs' for a while now, if I remember correctly.)
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.