The result of each command will be passed as the first argument to the subsequent command.
d. You get seamless interoperability with Erlang libraries.
:crypto.hash(:md5, "bob") |> Base.encode64
e. Try the Observer tool in iex to visualize various aspects of your running application, including the supervision tree, details on each running OTP process, and much more. Seriously very handy stuff.
:observer.start()
f. If you're using EC2 like I am, Amazon images have a too-old version of Erlang, but it's trivial to compile things yourself:
sudo yum install gcc glibc-devel make ncurses-devel openssl-devel autoconf
wget https://www2.erlang.org/download/otp_src_18.0.tar.gz
tar xvzf otp_src_18.0.tar.gz
cd otp_src_18.0
./configure && make && sudo make install
sudo ln -s /usr/local/bin/escript /usr/bin/escript
sudo ln -s /usr/local/bin/erl /usr/bin/erl
I had not even heard of Elixir till the Phoenix framework hit 1.0 about a month ago, and right now I'm very seriously considering Elixir/Phoenix for my next startup and have been slowly learning/hacking in it.
I come from C/C++ background, so the syntax was different as it is more Ruby-ish, but still very easy to grok. I've been looking at golang as my next language, but I think Elixir is even more simpler that it. Of all the functional languages that I've tried to get into in the past, this has the most approachable syntax, and I can see things like pattern matching helping a lot with code maintainability.
The performance, from whatever I've seen and the limited benchmarks that are out there, it compares extremely well with JVM, Node and Go. Erlang/OTP brings fault tolerance, Phoenix/Ecto etc. have been very productive, community is awesome and helpful. Erlang tooling, such as observer, is awesome and I don't think we have anything similar in golang, though I could be wrong. Dializer helps with type checking.
The one thing missing is lack of a enterprise sponsor, and also number of potential hires which can be risky for startups, but on the other hand people interested in working in elixir could be an interesting hiring filter ;)
To be honest with you, "for my next startup" strikes me as the absolute worst time to use a language/platform that is both new to you and new to the industry.
Delays kill startups, and that just begs for delays. You have to learn the language. All your new engineers have to learn it. You'll inevitably be (re)inventing the wheel because Elixir isn't in production at thousands of companies already.
Picking a shitty, slow language, as long as it's a popular one (JavaScript, Java, C#, PHP, Python), is going to have a much better cost/benefit profile.
> Picking a shitty, slow language, as long as it's a popular one (JavaScript, Java, C#, PHP, Python), is going to have a much better cost/benefit profile.
Although, keep in mind that a startup is going to be a roller coaster ride for years. You'll have days when you get tired of writing financial models for investors, or when an angry email from a customer ruins your mood, or you hit a road-block with a UI that just doesn't feel right. You'll want to take a break from all that by going back to just writing code for a day or two. At that point, you will want to get pleasure out coding. I'll be very unhappy if after those kind of days, I try to find solace in coding, and I see PHP, JavaScript or Java staring back at me.
Compared to the years it takes to turn a startup successful, the time needed to learn a new language well enough is negligible. I knew just basic Ruby when I switched to Ruby + Sinatra from Java for my new startup. Now, three years later, I can't be happier I made the switch.
Yes, you're absolutely right. Which is why I'm extremely conflicted right now. I definitely like what I'm seeing with Elixir/Phoenix, but should I take the risk or not is a really tough question. It is performant and fault tolerant, so for a startup if that means it can reduce our operational, and support, cost that itself would be a huge win. Deployment seems straight forward, much much simpler than what I had to do with a Rails app that I was experimenting with. Go deployment would be easier, but Elixir seems at worst to be inline with Play/Java (running under Play and not tomcat). There is a huge set of libraries should I need to venture outside Elixir and into Erlang, and moreover I think (not 100% sure) that Erlang can easily call into other language libraries which might come in handy.
The way I'm looking at it is implementing small examples in a couple of other options, such as Nodejs/Loopback and Java/Play and then comparing them. So far Elixir/Phoenix seems straightforward and productive, but still evaluating.
However, even if Elixir/Phoenix is the best thing since sliced bread, hiring and training is indeed going to be an issue so I've been trying to figure out how to solve than conundrum.
One counter point is the "Python Paradox"[1], though I don't know how well that conjecture was ever actually supported. However, isn't the Elixir/OTP ecosphere considered relatively practical and tested, rather than just esoteric or purist, even if it is new?
I do not agree, I have worked for a year on a startup using Clojure(Script) and I hadn't touched Clojure before. Never looked back and did not encounter any major issues springing from the choice of language. To the contrary, I have really enjoyed not having to deal with the disadvatages of older languages. The issue could possibly be in hiring, if the supply of Elixir-developers would be scarce.
It really depends on the startup. For some form of chat application or distributed system he will find himself reinventing less compared to the competition. Would be a great way to beat the averages :)
Kind of, since Elixir runs on the Erlang VM and it uses much of Erlang's libraries (e.g. OTP) I'd argue that you can look at Erlang's track record for Elixir's.
I worked for thredup.com when it was brand-new and we used Rails when it was still fairly new and we had a pretty good time all things considered. You just have to be a capable programmer. ;)
That list of languages was "popular" rather than "shitty and slow", although some of them certainly are shitty (and dynamic languages do tend to be kinda slow). I realize my phrasing was confusing.
I've been doing programming for a while now (mostly in Ruby of late, but prior to that, lots of stuff) and the more I play with Elixir, the more I want to work in it. I'm actually going to ElixirConf (which is next weekend in Austin).
They seem to have done a lot of things right, and addressed pretty much every single criticism I had of Ruby.
> I'm very seriously considering Elixir/Phoenix for my next startup
It will be a risk, but I say go for it. Others (who have probably NOT had any Elixir experience!!) will tell you your startup is already enough risk, but here's the thing- Elixir could end up being the key differentiator technology for you. Who else provides NO DOWNTIME code upgrades, and that incredible request responsiveness as well as reliability? Immutable data? Extreme concurrency? The "Actor model" that everyone is enamored with these days? The awesome community? Nobody, I think.
This is because Elixir is "just" a different syntax for Erlang/OTP which is used in very mission critical software in real world (it was originally created for telephone systems)
This doesn't need to be a language feature, but this is possible on the JVM afaik (see Clojure).
Also, NO DOWNTIME in the context of services is kind of hard to qualify: I have no downtime for say, a web service, when doing a load-balancer deploy shuffle.
> incredible request responsiveness as well as reliability
"Request responsiveness" to some degree depends on language- a language is sometimes your upper-bound on performance.
Much more often, however, do I find that this is a function of application design. And yes, language design and application design heavily play into each other, but there are many, many languages that can achieve the same responsiveness/reliability concerns.
Haskell, many JVM-hosted languages are good choices.
> Immutable data
Almost every modern functional language. Many even do it (immutable data structures) better than Erlang/Elixir. Some even have interesting (state of the art) concurrency features that perform better in different situations - see Haskell STM (I wouldn't try and compare to Mnesia).
> Extreme concurrency
Haskell, Go, anything on the JVM, the CLR is catching up.
> Actor model
This is a bit of a subjective and semantic thing - many languages have green threads (though not all would necessarily fit the bill of "actor model" in out-of-the-box implementation, and not all are truly preemptive (most aren't)) - Haskell, Go are two good out-of-the-box implementations.
I know Haskell has an Erlang Actor analogue, not sure if Go does yet.
> The awesome community
I hesitate to use the word "niche language" - but most "niche languages" have great communities (albeit small ones) - possibly out of necessity.
I don't find that this scales often
(What would you call the "Java community?", where would you find it?, where are the pockets of "good?")
This is 100% subjective, but, I feel like Ruby has one of the best, largest communities. Some of that has bled into Elixir, for sure, to be fair.
---
All in all, Elixir is a great language, but I hesitate to recommend it without knowing more about GP's requirements and business.
(What if the GP needs to do very memory and CPU-intensive number crunching?)
You can nitpick like this about just about anything — "Erlang has immutable data? Yes, but so does Haskell etc.".
That's missing the point that Erlang/OTP (and therefore also Elixir) is attractive because it's already a complete package. It's the intersection of a lot of different, neat technologies that becomes magical.
Try to accomplish the same things in Haskell or Clojure or Go and you'll find that you simply don't have the same tools available to you, and often they cannot be built as well as in Erlang because the foundation wasn't designed for it. And there's always some piece missing.
For example, you can build an approximation of supervisor trees in Go, but since goroutines cannot be killed, you're at the mercy of the runtime. (I also wonder if goroutines scale as well as Erlang's.) Similarly, no one has actually built a functional, immutable, process-oriented call-by-name-and-signature RPC mechanism for Go, so you'll have to invent your own. And so forth.
As a specific example, I was recently investigating OCaml to see if someone had implemented something similar to OTP. I found a couple of promising, nascent projects, but their activity all ended around 2009. Apparently nobody is doing it, even though the language seems damn near perfect for it. Never mind distributed processes; LWT is pretty weak even as an approximation of Go's goroutines.
> [downtime] This doesn't need to be a language feature ...
Erlang's live code replacement changes how you mentally think about versioning, I think. Instead of designing every piece of your infrastructure to transparently transition to a new version — using load balancers, multiple processes accept()ing on the same port, and so forth — you get a first-class language construct. This also opens possibilities beyond code deploys, such as temporarily injecting tracing into a running program. Also not often mentioned is how powerful it is to be able to connect to a running process and run the REPL inside it. (Ruby comes close here, but it's never been something you get for free.)
> This doesn't need to be a language feature, but this is possible on the JVM afaik (see Clojure).
You don't need Clojure; Hot Code Replacement was added in Java 1.4 (yes, that's 2002) and has been supported by application containers as well as IDEs since then.
Very much a personal opinion from someone coding for 15 years+. I'm new to Elixir but I found it to be a joyful language to work with so far. Java is a language you code in to pay the bills. Go is not bad at all but while I've heard people remark Go is fun, it hasn't been that fun for me. A bit of ugly syntax here and there. Python is awesome but I'm tired of the v2/v3 crap and frankly don't think it is the right tool for large, multi-person code bases (e.g. Openstack). Elixir has been truly enjoyable for me. If you are a jaded dev who used to love languages, give Elixir a try. I hope you get the same joy that I am getting from it because it has an ineffable quality about it.
This is very true. I had just started playing with Elixir and had pre-ordered Dave Thomas' Programming Elixir and was going through the draft ebook, and I actually set that aside and worked through the Getting Started. It's normal the see such guides, but the material there is really, really good.
Don't choose Elixir/Erlang just for the language. There are plenty of functional languages to choose from.
Choose them for what OTP provides. I doubt there is any language framework with as mature an operational framework as what Erlang/OTP provides.
For a startup it might feel like an extreme case of premature optimization but if you can make the technical investment you might reduce technical debt down the line.
I think Elixir in particular allows you to still get an MVP out the door with all the bells and whistles of OTP waiting silently in the background if your startup ever reaches the volumes to justify it.
BTW, I just attended a FANTASTIC 2 day (FREE) workshop conducted by Norberto Ortigoza (twitter: @hiphoox) at the HackerDojo that gave an overview of Elixir/Erlang/Phoenix and OTP. Thanks Hackers/Founders, Norberto and HackderDojo for arranging the training.
I feel like there's some room for building a nice scripting DSL given how strong of a macro support there is. However that does mean you're bringing in a pretty heavy VM for something that could be relatively simple.
The above is for erlang. It brings up the same VM so I imagine, if it doesn't exist, it would work as well for elixir if someone were to set it up. Perhaps we need an elixir shell project like scsh.
Honest question, and not meant to be inflammatory at all. I'm asking because I'm starting a project where an actor model may be a good fit.
Why would one choose erlang/elixir over akka[0]? Akka seems to implement a lot of common patterns for you. It has actor persistance, cross-node failover, advanced mailbox and routing logic, and is basically a superset of OTP.
The JVM is generally more efficient, has better tooling (ide support), has better libraries, and so on.
The only point I can give to erlang is the pre-emptive scheduling, which is useful for consistently low latency.
I've use both Akka and Erlang/BEAM is heavy production. There is a huge difference in multiple aspects.
1. GC and context switching internals. This becomes obvious quickly under load. While you can tune Akka in some ways and Akka will generally kick Erlang's ass in terms of performance, the response times and the number of usable concurrent entities are in favor of Erlang.
2. Libraries - what libraries are you going to use in Akka? JDBC/JPA? java.net? HTTP clients to pass REST requests around to modern integration endpoints? Most if not all are blocking and will bring Akka to it's knees when something freezes. Erlang libs are either non-blocking or blocking doesn't matter because it will handle millions of processes with little overhead.
3. Production ops - deploying and rolling back code in Erlang has tons of gotchas, but you can mostly change code and DB schemas on the fly in production, selectively or even run parts of the production load on your laptop to debug it.
4. Best part is failure recovery. In Akka, everything is a single OS process and single JVM. If you leak a file handle or some lock and a thread blocks nothing will recover you until your OS process dies. Erlang is capable of killing processes everywhere, there is no internal global state. Even if you leak something like a file handle in a process, it will be cleaned up when the process terminates like a real OS process. Even if you leak something in ets/mnesia, you can go ahead and clean it up from your erlang shell and production doesn't have to stop. If you leak something in Java and you haven't exposed specific interface to clean it, you will have to kill the JVM.
JVM threads are relatively heavyweight. The JVM would fall over trying to run as many threads per machine as BEAM will happily run. And you still have the stop the world GC in akka.
Obviously that's not the be-all-end-all measure of a VM, but in the context of actors it's pretty damn important. Akka is essentially an actor library bolted onto a VM that really doesn't like what it tries to do. Some people make it work, but there's a lot of friction from the GC that gives rise to some really undesirable performance characteristics.
Per-actor GC is pretty important, as it allows Erlang to guarantee soft real-time / low latencies. This is simply impossible in the JVM unless you go with Azul's GC, which then sacrifices throughput.
Thanks. Another point is that in Erlang/Elixir, if you have many actors, you will have less garbage per actor. Which means faster GC overall.
The best known example for Erlang/Beam "http throughput" is WhatsApp's 3 million+ concurrent connections per host. I don't think you get anywhere close in Akka. Maybe max out at 50K per server? Is even that possible?
Also, I'm not aware of good examples that use Akka with Java. Everyone I know using Akka seems to also be using Scala (not sure if it is just some kind of self-selection). I really can't stand Scala's syntax. I tried two or three times but I find it too easy to encounter Perl like unreadable code. Just my opinion though.
The problem is the JVM. There's a reason erlang has its own virtual machine. Without virtual machine support, doing concurrency is really just faking it, and will result in significant bugs later on that are essentially impossible to debug.
I take a neutral stance on this: the JVM isn't as amenable to the exact kind of concurrency that Erlang provides (green-threads with local GC backed by immutable data), but that isn't a fair assessment of concurrency.
Erlang (et. al. green thread models) has a method of concurrency that works well for situations you're using Erlang for. It's not the most efficient or most technically advanced mechanism for handling concurrency.
That being said-
> Without virtual machine support, doing concurrency is really just faking it
This is patently false, because it implies that:
- A VM is necessary for "real" concurrency
- (by deduction) Anything not utilizing an erlang-identical model is "faking it."
> will result in significant bugs later on that are essentially impossible to debug
I'm going to need to see an anecdote or citation for this.
Personally-speaking, I have a much easier time (quickly) understanding the execution of event-loop-backed cooperative multitasking than high-level, arbitrarily-preempted threads.
Also - I cannot see any reason why Quasar for the JVM would be any easier or harder to debug (from a theoretical, not tooling or practical standpoint) than Erlang actors.
The nuances differentiating the two models aren't great enough to merit bugs that you might see in one place or the other. Unbound, CPU-heavy tasks will cause problems for both systems.
I can't speak for Akka, but right now Elixir is growing hugely: it feels like node in 2011. There aren't a lot of experts but it's the first time a distributed systems language has actually cared about syntax and a lot of people are really excited about that. You go to any major city and there will be a standing-room-only Elixir meetup.
Robert Virding has a great talk on BEAM (the Erlang VM). He talks specifically about how BEAM handles concurrency. I think it would answer a lot of your questions.
A few of his points that would directly apply to your question:
1. BEAM processes are lightweight which means smaller memory footprint and cheaper context switching between processes.
2. As others have mentioned, garbage collection. Processes don't share memory, so data passed between processes are copied. Virding says that this is a tradeoff, but worth the benefits of keeping garbage collection simple and fast.
3. Since processes are VM processes and not OS processes, BEAM can count the number of function calls each process makes. If a process is long running and starving other processes, BEAM can put that process back on the run queue to give other processes necessary time.
These are the ones I can remember from off the top of my head. I recommend giving the talk a listen.
- BEAM has green-thread-local GC.
- As you mentioned, preemptive scheduling is implemented at the VM-level and is relatively elegant.
- Faster startup times (meh)
- Dynamic typing (subjective)
> JVM is generally more efficient
Depends on the scenario (and JVM implementation) - tracing, STW GC isn't always the best option.
> has better tooling (ide support)
Yes.
> has better libraries
Bit subjective, but there are certainly MORE JVM-compatible libraries.
---
Personally not a fan of Akka simply due to the underlying languages commonly used with it (Scala, Akka)
As a Haskell-user: if forced to choose between Scala and Elixir, I would choose Elixir.
I have been watching Elixir/Phoenix for over a year with a lot of interest, one thing that I really appreciate is how dedicated they are to their CHANGELOG files.
Nice to see the new code of conduct, that's not something you see in every community.
I have to say it's incredible to see how quickly Elixir has developed and what the language is capable of. Between Elixir on the server side and Rust on the native space I feel like we're seeing a real growth of practical functional languages.
(I know Rust isn't as pure functional as many other languages but it's ML roots are still refreshing for writing native code)
Elixir/Erlang aren't purely functional either (eg: ets), but they're enough functional to eliminate many common bugs and they still allow you to get stuff done. :)
It's the light at the end of the tunnel for a native language with a great type system and decent primitives.
Something as low-level as Rust can't deviate as far as, say, Haskell, from the procedural, register-machine reality in which we operate, and that's fine.
I took a look at Erlang/Elixir a while ago and didn't get too far into it after realizing there was no compile-time type-checking.
My main question coming out of it: if you are going to go with a dynamic language, why go with Elixir over Python or Ruby (or Clojure or Racket or ...)? These have a larger mind-share and a more broadly recognized syntax.
Elixir creator here. This is a very good question and a very hard one to answer because there are so many facets to consider. I will provide some bullets instead of doing direct comparisons.
* Concurrency is not an after thought. The primary abstraction are actors (Erlang processes) that are isolated and communicate with message passing. Data structures are also immutable which helps greatly with concurrency and also leads to clearer code (it is really comforting to know that a value won't change under your feet).
* The Erlang VM: we are leveraging 30 years of knowledge in building and running fault-tolerant systems, thanks to the underlying process model. We could really go deep into this topic so I will just link to an article I wrote some time ago talking about Elixir and microservices: http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-...
* Performance may also be a big deal depending on what you are doing. Elixir/Erlang are not good at number crunching but if you are running anything behind TCP/UDP, it will give you better throughput and a consistent latency compared to Ruby, Python, Node.JS, etc.
* We don't have compile time checking but we do provide type specifications and a way to check them: http://elixir-lang.org/docs/master/elixir/Kernel.Typespec.ht.... The integration between Elixir and Dialyzer is suboptimal today but if type checking is a big deal for you, it will certainly help.
TL;DR: Elixir is for building and running fault-tolerant, concurrent, distributed systems. It brings extensibility and great tooling to the Erlang VM. If what you are building requires 1. a TCP/UDP port and/or 2. running for a long time, you should definitely consider Elixir. An introduction to the language can be seen here: https://vimeo.com/131631884
Thanks for taking the time to reply here, Jose. Elixir is definitely a very impressive language and as a former PL student, I am definitely a huge fan of your work.
That said, if I were looking into a BEAM language in the future - and after this thread I am inspired to try again - I would probably be more inclined to go with Erlang. For the same reason that Java is probably an easier sell than Scala.
However, I am most likely not your target audience. I am neither an existing Erlang user nor a Ruby user (nor even a Node user).
This is a very nice book that introduces functional programming in a way that's very accessible to people coming from Python or Ruby. Elixir is probably more accessible than, say, Haskell or Scala for someone coming from one of those languages.
Have not coded Elixir in anger, but from the look of it the immutability and composability and other benefits of debugging functional programs could be a big win over writing the same program in Ruby or Python.
Not sure if you are trolling or not, but here goes.
I would choose Elixir over Ruby or Python if my service needed to high reliability or if it touched the network in any significant way. Ruby and Python suck at concurrency and are "fragile" when serving lots of connections. Clojure or Scala (seriously, no one is building a product in Racket...) would be appealing but the JVM brings its own set of headaches and even with bolt-on large-scale concurrency support the JVM languages are not significantly better at these problems.
Broadly recognized syntax? Elixir is much easier for people to read than either Clojure or Scala and is close enough to Ruby that Elixir is drawing over a lot of developers from that group.
I use Elixir because it is fun, it scales well and has high performance for the problems I am throwing at it, and it helps me develop solid and reliable solutions.
Not trolling. I used OCaml because it was "fun" and "highly-performant". Would I recommend it to my clients? No. Granted, this is almost entirely due to the POS stdlib - a problem Erlang and (by extension) Elixir do not share. However, the syntax and alternative MO are still a big sell. I'd argue that the majority of people out there doing web engineering (even the big ones) don't need it. Heck, look at Facebook using PHP.
I'm not sure what my point is - it's just not an easy sell?
The easiest sell to clients and stakeholders is reduced operational overhead, lower costs, and higher reliability. Real-world stories are coming out of 10-20x reduced server counts from Ruby and Python systems that have been replaced by Elixir. We also have stories like WhatsApp (Erlang) who supports their hundreds of million of users with a few dozen engineers. The dollar cents here make it a strong sell to stake holders, and the platform features make it a strong sell to the rest of your team and software requirements.
We have also heard stories such as LinkedIn, Netflix and Twitter migrating from different languages (such as Ruby for Twitter) to Scala. How do you think this success story of building distributed concurrent backends compare to Elixir's?
Deciding on what language to use on a new project and rewriting a large app are two different things. It's much harder to sell a rewrite than it is to sell using a different language on a greenfield project.
If you know Elixir and are confident using it, you'll understand its benefits and when best to use it. I work for a dev shop where we use Elixir for client work. Elixir is performant and you end up making the most out of your server resources. That would be great for clients who end up having huge traffic. But more important than performance, I find it easier to maintain Elixir code largely because it's a functional language. Lastly, I think Elixir's Lisp-inspired macros are a great way to write reusable libraries/modules.
In essence, I'm more productive with Elixir than I am with Ruby even though I used Ruby for much longer. I find it a more pleasant experience maintaining Elixir code than Ruby code.
I've been watching Elixir (and Phoenix Framework) as well. In addition to lightweight processes, the functional style, immutability, pattern matching and Rubyish syntax are appealing too.
> My main question coming out of it: if you are going to go with a dynamic language, why go with Elixir over Python or Ruby (or Clojure or Racket or ...)?
If your problem is one for which a fault tolerant, highly-scalable system with actor-model concurrency is an appropriate solution, Elixir (or Erlang) makes a good choice, and Ruby/Python/Clojure aren't particularly great choices for that. That they all happen to lack static type checking is not what is motivating the choice.
Also, Erlang/Elixir have fairly robust (for languages that are "natively" dynamic) type-checking available through dialyzer, which can be strength compared to other dynamic languages.
Elixir helps manage complexity by encouraging the structuring of code in terms of series of transformations on data. This makes code simpler, more readable, easier to read, reason about and maintain. It also helps avoid whole classes of complex bugs and problems that inevitable creep into large codebases of Java, Python or Ruby code.
> It also helps avoid whole classes of complex bugs
Whole "classes" indeed.
Especially for Ruby devs who are fed up dealing with concurrency and performance problems in Rails, Elixir is very attractive and will make you code in a different way.
The concurrency model. I recommend Rich Hickey's talk "the language of the system" (ironic, I know). In erlang/elixir you use the same kinds of abstractions to design your fine-grained logic and you coarse services. This makes for a very unique approach to scaling.
Elixir (probably due to the Erlang roots) seems to actively make it hard for you to hold onto state. This ends up (in my experience) being a good thing... or at least a brain-stretching thing that may lead to fewer bugs on larger projects.
Clojure allows some OO if you'd like. I see that as a drawback, personally, but I've drank the functional koolaid.
I've coded in Python and Go (which has compile time type safety and does inference to avoid verbosity) code professionally, and am loving Elixir. I build distributed systems and I while I love Python, I don't think it is the right language for that. Frankly, I prefer nodeJS's single thread to Python's GIL because you are under no illusions wrt concurrency. Go is better but I don't understand why channel communication across machines doesn't exist (I think it was there as an experimental feature early on but maybe I am mistaken). I'm very impressed by the capabilities of the Beam VM and hope that Elixir will let me build better distributed systems (despite the lack of type safety).
I'm trying to convince people at work to use Elixir but people seem to have language fatigue. The lack of a major company/product using Elixir is making me worried as well. But hey .. someone had to be first, right? :)
IMHO the main reasons compared to, say Ruby, would be: native support for concurrency, Erlang VM, fault tolerance and speed. However, I'm also disappointed that there's no type checking. EDIT: Although I don't agree with the comment below, I'm removing comment about Golang because it's unnecessary in the discussion about Elixir.
I'm not calling you out, but in general when I hear people compare Go to languages with more "intense" typing (including Erlang, though possibly not Elixir) I find it funny. Go has a very crude type system and can be more easily compared to C (in terms of types) than anything else I think.
If you ever try to do anything as interesting with types as you could in a dynamic language, you'd immediately start transporting interface{}s (essentially void*) all over the place and lose all static typing [0] (and context[1]).
> IMHO the main reasons compared to, say Ruby, would be: native support for concurrency, Erlang VM, fault tolerance and speed. However, I'm also disappointed that there's no type checking.
I tried Elixir about 2 months ago for a project and found the standard library was lacking and the quality of community contributed modules wasn't up to par with other languages. I've worked with Python and Node my career and I prefer the Multi-paradigm approach of a Language like Go or Rust than the functional approach. I'll probably give it a try again in a year when it's more mature.
What do you think the standard library is lacking? I mostly wrote Ruby before picking up Elixir and Ruby's standard library is loaded with mostly garbage. I've found Elixir's std lib to be focused to the core purposes of the language but I would love to hear what you think it needs.
This may be a perennial issue with functional langs, but using a functional lang only made sense to me after working with OO problems for YEARS.
You'll see quite a few people commenting in this thread (including me) who have spent something like 10-15+ years working with OO languages, we've seen the ugly sides of mutability, dependency spaghetti, holding onto state too tightly, too much coupling between classes, and the like; not to mention the difficulty with concurrency in a world where anything can mutate global state (such as class definitions).
n00b question: can someone give me a small summary of the main difference between Elixir and Node at a very general level, without getting into a spat about the merits of JavaScript or true functional languages. Looking more for pros/cons like, "Elixir works _X_ way, where Node lacks _Y_," or, "Elixir is great for _Y_, but if you really want to do _X_, stick with Node."
If you search HN or Google for Erlang vs Node there's a long history of this debate. Here's a brief summary:
- Erlang/Elixir (from now on I will just say Elixir) have parallelism out of the box. Node.js is a single threaded event loop so you only get CPU parallelism by forking.
- Elixir is also massively concurrent and has non blocking IO but instead of using callbacks/promises you just write your code sequentially and the BEAM (Elixir's VM) takes care of scheduling for you.
- In benchmarks, Elixir maintains a very consistent 99th percentile whereas Node's 99th percentile latency drastically gets worse as the active number of connections increase.
I guess one difference is the approach to concurrency. Node is still (as far as I am aware) single thread per process, and so tends to take the approach of using multiple processes (so that multiple cores are used) and some form of IPC.
Elixir (because Erlang) handles the distributing of 'processes' (not operating system processes but Erlang lightweight process) across cores for you. Erlang's been doing concurrency for a long time, it's very good at it.
The style of programming is very different in that you are encouraged to use processes in Elixir, rather than the callback style that is prevalent in Node. It feels weird at first, but pretty natural after a while.
I'm not sure there's much you can do in Node that you can't do in Elixir. But there are features in Elixir (again, because Erlang) like hot-code-reloading (update your app whilst it is running), and the way it can distribute tasks across nodes that I'm not sure are that straight-forward with Node.
Sorry if this sounds like a noob question. Since everyone is asking why going with Elixir and not {X}, I am going to ask why would someone go with Elixir/Erlang and not Scala? I am asking this because we are evaluating new languages at the work place.
Very excited about this, I am one of those people who theorycrafts about stuff quite a bit, and while I have been looking for an appropriate language for some of my next projects, elixir is at the top of the list consistently, mostly because I like not having to deal with concurrency myself, so I think it will be easier to rapid prototype and then scale as needed.