I use phoenix and elixir, I agree with the statement that Elixir is awesome. But don't drink too much cool-aid - Elixir might be dangerous as well.
It is essentially a big pile of macros, so sometimes number of keywords that you have to keep in your head is staggering. Also, Elixir is a pretty big language - I knew Erlang before diving into it - so the barrier and number of concepts that you have to get familiar with is huge. Don't get me wrong - all these concepts/design patterns are necessary (I am thinking about BEAM and OTP here). Erlang (and therefore Elixir) is complete as development environment, that's where the amount of knowledge is coming from.
The fear about macros in Elixir itself seems a little overblown. Most macros are consumed in the same way you would consume functions or keywords in another language (e.g. defmodule/def/defp/if/unless/etc.). The only one that I can think of that can be problematic is `use`, which is more of a problem with third-party libs where someone might do a lot of "magic", but in general is mostly used to do things like import functions, alias modules, etc. The concern about macro abuse is certainly valid, but I don't feel like it's at all a problem with the core language, but rather abuse by people who feel the need to use macros for things which do not require macros. In addition, macro usage in Elixir is always explicit - you must import/use macros at the top of a module, and the implementation of those macros is easy to find by going to that module definition. It's not nearly as dangerous as say, monkey-patching in Ruby.
In any case, just wanted to chime in with my two-cents. I've been working in Elixir for the last couple of years and have never felt like I've been bitten by macros. Elixir is certainly a bigger language than Erlang, but many of the things Elixir adds on top of Erlang are what make it so pleasant to work with. For example, the reduction in boilerplate for gen_servers which is made possible with `use GenServer` in Elixir.
Compared to? Perspective matters a lot. It is definitely bigger than Erlang but I would still classify it as considerably smaller than languages like Scala and C++ and still smaller than Ruby and Python.
> It is essentially a big pile of macros
Since "a big pile of macros" is not quantifiable in anyway, I have decided to check for macros and function definitions in Elixir source and I got 1687 functions and 169 macros throughout the whole standard library. It is roughly 10%.
The Kernel module (imported by default) has 60 functions, 78 macros, which is, for example, considerably smaller than Haskell's prelude (about 300 last time I checked?).
Considering things like `defmodule`, `def`, `defp`, `case`, `&&`, `in` are regular macros in Elixir instead of syntax keywords (as they would be in many languages), I wouldn't personally call it a big pile. Although I agree that's a matter of perspective and that's why I decided to measure it).
> the barrier and number of concepts that you have to get familiar with is huge
I definitely agree with this. There are functional aspects, like pattern matching and immutability, the concurrency aspects and the OTP bits. There is definitely a learning curve although most patterns, as you said, are necessary for building the kind of systems Erlang/Elixir enable you to.
That's why a pasted http://www.slideshare.net/BrianTroutwine1/erlang-lfe-elixir-... - slide 96 (I can't find a direct link). Elixir sits above golang but way below Java or C++. Maintainers are doing pretty good work at simplifying things as language matures - for example merging Dicts and Maps together.
Aside from pretty simple `__using__` macros, most Elixir devs come to appreciate macros and then elect not to use them in the most situations. Most people who do use macros have a very small Macro that just returns the AST for a function call after some tiny little adjustments to the arguments is made.
There are a few exceptions where there are very large projects that make heavy use of macros (Phoenix's router, Ecto), but they are by far the exception. Most of the macros you use every day are simple ones.
I don't follow how "these things are macros under the covers" translates to "i need to keep more stuff in my head"
And the argument that "the community discourages macros" isn't particularly compelling, but for whatever reason it has worked well. People seem to use them rarely, and when they are used they're reasonably straight forward. I've been using elixir for a couple years now, and I haven't run into many cases where macros ended up confusing me as a reader.
On the contrary, I stumble over the more esoteric "discouraged by the community" features in scala literally every day.
Relying on the community to exercise restraint with the powerful parts of the language is a huge gamble, but it has worked well in the elixir community.
If you're looking for a reason to migrate from a stack like Ruby/Rails to Elixir/Phoenix you should check out my RailsConf talk on that exact subject: https://www.youtube.com/watch?v=OxhTQdcieQE
Thanks for all the work you and the good folks at Dockyard put into Elixir Phoenix and Ember.js, my entire stack nowadays is run with Ember in the front and Phoenix in the back, so I very much appreciate all the great addons, packages, talks, etc., you guys have given.
This is a great talk. Have you all at DockYard considered putting these concepts in writing?
Sometimes I find that having a detailed blog post about the subject with supporting links and documents can be a fantastic resource for transition discussions.
My team has made the decision to move toward all greenfield projects being started in Elixir/Phoenix and we couldn't be happier. We have been a Rails shop for six years prior.
I should probably write it up. I've been pretty busy traveling for business and doing conf talks. The next few weeks slow down quite a bit so I should have some time.
Is it hard to find developers familiar with elixir/phoenix? Or is hiring RoR developers and training them to work on elixir/phoenix a better option than specifically hiring people familiar with elixir/phoenix?
Just curious to learn about your experience, as there is not much data available on hiring elixir/phoenix devs.
Most of our Elixir/Phoenix clients have retrained existing Rails devs. As I spoke about in the talk, the initial retraining period is about a week. Reading Part One of the PragProg Programming Phoenix book will introduce the dev to Elixir syntax and FP basics. Their existing knowledge of Rails can be applied to Phoenix apps where they can start making contributions.
However, this does not make expert Elixir or Phoenix devs. Reading up and learning about OTP and how concurrency works in Elixir/Erlang is necessary to continue to advance.
Great! We're busy rewriting a part of our Rails app that we are having difficulty scaling in Elixir. So far what I've seen is phenomenal. Coming from Ruby/OO, it's a bit weird sometimes, but the code is very readable and it's insanely fast. Really the first language since Ruby that I'm quite happily riding the hypetrain for.
Anyone here switched from a statically typed functional programming language (Haskel, OCaml, F#, Scala...) to Elixir? How would you describe the experience? What do you miss? What do you like/love? Overall, would you recommend taking that step?
I used to do Scala prior to coming to Elixir, mainly by using Play Framework to create web apps. I can tell you that I love Elixir and that I will not be going back to Scala. I miss nothing from Scala.
* Pattern matching in Elixir is superior to Scala's in every way possible (You can pattern match on function parameters!!)
* Async code is a breeze with Task.async()/Task.await() instead of mapping on Future's everywhere and making sure you have the proper implicit globals imported
* Actor pattern is built into the language and it's a breeze to work with. No need to rely on Akka to replicate it
* JSON is a joy to work with
* Documentation is fantastic in the core language and many libraries
* No more JVM!
* Building a release is much easier than dealing with SBT
If you have a functional background, I would recommend reading Elixir in Action as a starting point. It already assumes you have an FP background and takes you into more of the core features of the language. I really enjoyed it and the content is superb.
True. That bullet was more of my opinion of disliking the memory usage the JVM uses as well as my personal preference of VM.
BEAM has many great advantages such as fault tolerance and multi-node distribution built in. This allows concurrency to be a first-class citizen for applications running on the BEAM. I'm not saying that concurrency can't be done on the JVM, but that I've found it to be much simpler using BEAM. On the other hand, the JVM excels at computational work compared to the BEAM. Both VMs have their place and can be better at different types of problems comparatively.
I won't say testing HiPE with fibonacci is silly because this is exactly the kind of numerical computation where we expect HiPE to be useful: it looks like it is :-)
To me, there's an interesting point here. Elixir has the advantage of targeting a VM built for a language semantically similar to Elixir; things that have frustrating limitations in JVM functional languages like Scala and Clojure (eg, tail calls) just work on BEAM. Interop, naturally, is also much smoother. Want to call out to some Erlang code? Fine - that'll be ':module_name' instead of 'ModuleName'.
On the other hand, the Java/JVM ecosystem is much larger, so there's a serious trade-off there.
There are a bunch of different performance differences, but a couple basic differences: 1) gc is per-process, not global/stop-the-world 2) the VM is responsible for scheduling processes using threads, and can pre-empt...blocking the scheduler is considered a VM bug.
I find failure to be more fatal on the JVM. That's neither a bug nor a feature, it's just what it is.
For example, BEAM puts the process call stack on the heap, so you don't need to tune them separately. You won't hit a stack overflow, you'll just run out of memory.
Many, many characteristics like that exist. I prefer a working slow system over a broken system, but I fully understand the preference for loud failures.
Having BEAM specifically designed for Erlang concurrency gives it a number of specific benefits. Specifically in how it schedules and handles the VM processes to do efficient concurrency. For example, since the processes are in the VM, it can count the number of function calls to preempt a process that is taking too long.
Agree, sorry. Sure, here are some randomly ordered reasons:
* Immutable data. This ties into "functional" section below but it is worth mentioning separately. The benefit here is it is a better fit for concurrency and correctness.
* Lightweight processes. Can have millions of them. But they don't share the heap so act like OS processes in that respect. That means 2 things:
1) It changes the way you think and solve concurrent problems. It reduces impedance between real life problems and how they are solved. Spawning a new process for each long lived connection is obvious and easy.
2) Fault tolerance. Having one request not crash the whole server is a really a massive improvement. In C++ or Java you don't know if something got messed up because of a crash. Maybe some shared data structure or lock got left in an inconsistent state. There is just no guarantee.
* Hot code loading. This is not just a gimmick but it works. Most places don't use it to update regularly and I don't either. But used it a few times in production to add extra logging, fix a customer specific issue without shutting down the cluster before the fix was released. All the while there were 100k/sec requests pounding it. That is plain old money in the pocket. No downtime, no headaches.
* Tracing. BEAM has very good tracing support. When debugging I am quite fond of just logging into a node and using tracing instead of print or log statements.
* Functional. This is more about Erlang the language, and it kind of goes with immutable data. But because of that it means state is more visible and explicit. Looking at a piece of code on a page, I get more context of what is happening because State is passed, updated and returned. As opposed to being some "this" reference which at that point in the code, I don't have any idea how it was modified or what it has in it.
* Garbage collection. BEAM has excellent garbage collection. It is pause-less, in the sense that GC of one process won't block the world. Java has lots of tweaks for that but it is not a default state of affairs.
Welp, this is just a quick list off the top of my head.
At the end of the day, one can probably go through the above list and say I can do all that in Assembly or C. Which is true. BEAM is written in C in large part. To get fault tolerance, can just spawn OS processes in any language. To get immutability, can just go to Github and find an immutable collections library for Python or Java. Java can also do some code loading. But the difference is, it all comes in a single package ready to use. That is huge and I see it as a great benefit.
which can serve as documentation and are used by a tool called Dialyzer during the build process to find errors based on the type specs.
I have not used this particular tooling first hand, but my sense is that it is well-integrated and works well. Someone else will probably comment with first-hand experience.
The Elixir compiler seems to catch a lot of errors, for what it's worth. If you attempt to call a function that doesn't exist or with the wrong arity, you're going to get an error (even w/o any type specs). The number of compiler errors one has in a statically typed language that are really just about types may not be that many.
w/r/t static vs dynamic, in general, these are the things I'd consider (if you haven't already): you're domain (are you building a rocket or a consumer-facing web app), you're appetite for testing, size of project, size of team, specifics of the tooling w/r/t refactoring (elixir's compiler is pretty good for supporting a big rename, for example; ruby, without a compiler and with so many language features, not so much), how the language makes you feel when you use it (dynamic wins here in general for me; I don't like to be in trouble or interrupted when I'm thinking), the collections library (this is big for me -- I could never go back to a weak collections library -- Go, I'm looking at you), Etc. YMMV, qualifier, qualifier. In general, the specifics really matter -- both of what you're doing and the specific tooling and how they interact.
Elixir seems to strike a very nice balance of all these things with a just right, small, extremely powerful feature set on a rock solid VM with astounding concurrency and distributed computing facilities, if you need them. By all means, I would try it.
Dialyzer uses something called Success typing. The gist is that while e.g. Haskell won't compile unless it can prove that your code is correct, Dialyzer will only complain if it can prove that your code is wrong.
Personally, when I used Dialyzer in Erlang, I was underwhelmed by the amount of errors Dialyzer caught (type checking concurrent code is hard, who knew?) — however, it is certainly better than nothing. Plus, the type specifications you have to annotate your functions with help with documentation :)
I switched from Ruby to Scala, and I have had an absolute blast. Elixir is sort of chained to BEAM, which doesn't appear to have as bright a future as the JVM or LLVM does, so Scala seemed like a safer bet.
Reading about Elixir is cool sometimes, but then I look at Dotty, and I feel confident that I made the correct choice.
I've also been keeping an eye on Crystal (statically typed Ruby-esque language, LLVM), but they aren't making great PLT choices so far. Maybe they'll get it together later. Scala-Native will blow it out of the water most likely anyways.
Sort of the opposite of losing statically typed programming, but I've really enjoyed the journey and it's improved my work a lot more than I thought it would. I know Ruby pretty well and I used to feel really dumb all the time when things would break, and it took some time for me to realize that it was a language problem. Looking back and reading some of the Ruby that I ported, it was impossible to reason about, and very difficult to make guarantees for. Nothing was solid at all, and runtime errors could hypotehtically stop the show at any time. With Scala there's a much sharper baseline of what will definitely work or not work.
Types make a LOT of things so much easier, in exchange for making a few things SLIGHTLY more tedious. After doing it, I'd make that trade ten more times if I had to.
> Elixir is sort of chained to BEAM, which doesn't appear to have as bright a future as the JVM or LLVM does, so Scala seemed like a safer bet.
Where does this impression come from? The BEAM VM is maintained by Ericsson, we get new "major" releases every year. In the last years we got the maps data type, the new scalable timer API, better tracing facilities, dirty schedulers, and so on. Lately, at ElixirConf Berlin, we heard about the current efforts on scaling the Erlang Distribution to thousands of nodes out of the box (it is already possibly today, just not by default).
They are also plenty of research projects, mostly in Europe, about improving the VM, development experience and scalability in different ways, such as http://release-project.eu/, http://www.prowessproject.eu/ and http://paraphrase-ict.eu/. That's not including the usual suspects like Chalmers and Uppsala in Sweden, which have been exploring different aspects, specially in the testing area with property-based testing, concolic testing, systematic concurrent testing, etc.
Companies like Adapteva (behind Parallella), Basho, Erlang Solutions, Plataformatec, and many more are investing in the ecosystem too. If there is one thing I am not worried about is the VM and the runtime bright future.
In my opinion, the simple fact we have a runtime with preemptive light-weight processes from the ground-up (instead of tackled on top as a library/framework) with per process garbage collection and inter-node communication taken care of is enough to hold the VM for the next handful of years, even if all development ceased today.
I can't speak for shrugger, but when I see the manpower invested in improving Java, .Net, JavaScript, Go, LLVM runtimes/compilers, I'm personally wondering if BEAM will be able to follow. We are starting to see languages like Python fade away because of that, when fast execution starts to matter.
That's right, LLVM does support JIT compilation. But it's just one tool in the toolbox. I would hazard a guess that most projects which depend on LLVM don't use the JIT compiler.
But even with a JIT compiler, LLVM doesn't provide the kind of runtime services (e.g., memory and resource management) that we would typically associate with a VM runtime like the JVM's. Like their Web site says, "Despite its name, LLVM has little to do with traditional virtual machines, though it does provide helpful libraries that can be used to build them."
I don't think you've communicated what you were trying to accomplish very well with your LLVM comparison. Many people will see it and think you're confused at what you're talking about.
I saw about 5-6 products which use Scala.js and I haven't heard of any of them before. Who else uses that? Seems rather obscure.
Is Scala Native used widely? They just finished implementing java.lang.String 20 days ago or so. At least Erlang on Xen has been serving web pages for a few years now: http://erlangonxen.org
But most usage of Scala is on JVM still, wouldn't you agree? We are not talking CPython/Jython/PyPy/Numba... I don't know, the claim that Scala is widely implemented on other platforms while Elixir is tied to BEAM doesn't quite go far for me.
I understand, but your opinion doesn't change the facts. Scala.js is more than mature, with some huge projects already built in it. I'd not heard of erlangonxen, but it would take a lot of convincing to re-write something in Erlang to begin with, when I could write it quicker in Scala, and run on 2, eventually 3 different platforms.
Scala Native is not very far along compared to Scala.js, but it is actively being improved, and is considered an official extension. Additionally, Dotty will bring huge improvements for JVM scala.
I am not super happy with JVM most days, but I'd far and away prefer to be chained to JVM than BEAM. I mean, it's not even a question at this point, considering the billions of dollars spent developing JVM and the work of the brightest minds of several generations. Joe is a cool guy and all, but Erlang is objectively a niche platform compared to JVM.
I've never really looked into Elixir. I'm a Python guy and readability is the first thing that makes me love or hate a new language. Considering I've always found Erlang fairly obtuse visually I am surprised by how easy on the eye Elixir is.
I found this quote very telling:
> "Elixir is simply the first language since Ruby to really care about code beauty and UX of the language, libraries and ecosystem."
Of course they meant 'Python' instead of 'Ruby' but hey ;-)
I've made the switch from Ruby to Python, mostly for the scipy/numpy/pandas/jupyter support (and performance) - but I don't think I'll ever get away from the feeling with Python that I have to look up how to do things that felt natural in Ruby.
I've gone back and forth between Perl, Python, and Ruby a few times over the past 20 years...that feeling happens every time I switch, for all of them. I generally find "intuitive", and "ease of use", is almost always really just "what I'm used to".
That said, Ruby has gotten more difficult to read, for me, over the years. I just did a small-ish project in Ruby for a client, and was surprised at how much new syntax there is. It has become a large language, in the way that Perl is a large language. It took me longer than I expected to wrap my head around new idioms. Python 3 code seems simpler than Python 2. Ruby 2.x code seems more complex than Ruby 1.x. That actually surprised me, because the first time I tried Ruby (way back when DHH released the first "make a blog in 3.4 seconds" or whatever that RoR intro video was) I found it immediately intuitive, moreso than Python, which I was using at work.
Anyway, my point is that these are big, old, mature languages, with a lot of weird stuff that's made its way into them. It takes time to master something with such depth. It doesn't necessarily mean the language is worse than a new language that is extremely simple...Ruby, Python, and Perl started out simple (even simplistic); the needs of their users caused them to expand. It takes a real effort, and a willingness to break backward compatibility, to stay simple through decades of development. Python 3 made some of those hard choices and got a little simpler; Ruby and Perl haven't (though Ruby and Perl are still stronger languages than they were when they were "simple"/"easy", whatever).
But, I'm also using Python more lately because of the scientific and machine learning stuff, which is a super strong ecosystem.
I started out learning Erlang before Elixr had really crossed my radar. I have to say I prefer the Erlang syntax to the ruby-inspired Elixir. Maybe just a matter of what you know, I could see a RoR developer finding Elixir more appealing (I've never really used Ruby or Rails at all).
I am primarily a C# developer who learned Erlang (and did some small stuff in it) then moved to Elixir (I have never programmed in Ruby).
I think the huge extent of macros in Elixir is used extremely dangerously, and it can be very difficult to truly know what's going on behind the scenes sometimes.
That being said, I still prefer Elixir to Erlang for 2 reasons really.
1) I have a very iterative development style which involves a lot of refactoring and test -> code -> test -> code cycles that kept getting extremely frustrating with the ant-turd line endings. Honestly, if I could not have to deal with those line endings I probably would be more inclined to Erlang over Elixir
2) The testing infrastructure seemed much easier to use in Elixir than Erlang.
That being said, I don't see a purpose for Elixir or Erlang in the web serving space, and instead are using it for distributed (and non) stateful servers.
Agreed. The syntax and benefits would certainly appeal if I were a Ruby developer, but coming from a different perspective, I don't get the reason for all the love.
As a dev that used Python for the majority of projects I skipped over Elixir when I first saw it based on just a quick scan of the home page. "What? A dynamic, functional, compiled language that looks a little like Ruby? Why would I spend time learning this?". And I'm happy to say that I now love Elixir. Off the top of my head the 5 best features are: pattern matching[1], fault tolerance (a single isolated VM process can crash and then retry quickly), concurrency, Phoenix, and now Nerves[2].
I have to say that learning and using Elixir has been more pleasant than any other language I have ever worked with. Code is easy to follow due to the functional nature of the language, and the community is one of the best out there.
The applications I've written and deployed have been more stable and fault-tolerant than anything else I've ever done, and I've yet to have any performance issues with the language in production.
I use Erlang and plan on sticking to, but do like Elixir's community and am following it closely.
Jose Valim and team did an outstanding job being welcoming to new members, emphasizing documentation, friendliness and ease of learning and paying attention to usability. That is no easy feat and requires a lot of hard work and determination, very impressed by it.
My own personal experience doesn't matter much, though, because ultimately Elixir is Erlang and obviously Erlang has been pushed extremely hard in production (Klarna, Heroku, Riot Games, etc.).
Elixir 1.3 and Ecto 2.0 are now both released.
That means Phoenix 1.2 will be released ASAP.
Definitely give the Programming Phoenix book a read if you haven't already.
The Elixir/Phoenix stack should be ready for most production environments now.
José Valim (the Elixir creator) is soon releasing a free ebook [0] on Ecto 2.0, and it's probably gonna give some good insights into Ecto in general, so I would definitely recommend getting that :)
You won't find anything better than hexdocs and stacked overflow at this moment (not in my experience at least). You don't get the dynamic method calls of find_all or the find(:hash key) magic but once you master Ecto.Query and all the different parts that make up Ecto you'll have much more flexibility and performance out of the box. The information is hard to find on Google but the Ecto source code and official docs are much easier to parse than ActiveRecord.
> Come for concurrency, stay for metaprogramming. :-)
hehe. I've only done a bit of Elixir, but coming from a node and Python background that's pretty accurate:
- It should be the VMs job to take care of concurrency, not the programmers
- Although functions having different signatures is common in the front end JS world (mainly due to jQuery) metaprogramming is a nicer way to do it.
Also 5-10ms response times for a basic Phoenix web app is pretty rad. If I wasn't building a startup and thus had the time, I'd love to do more Elixir.
`mix test --stale` sound like a tremendous gain in productivity, can't wait to use it.
Is there a way to have `mix test` just call --stale steamlessly for me in my terminal?
The other updates to testing in general signal how important testing it to the Elixir core team, and should be a flag letting you know how robust this language and it's tooling is. Take a look for sure, it's a great language.
l used to be/still am a ruby on rails developer. I wrote a very naive web crawler in elixir within a week while learning elixir and I'm blown away by the performance. It basically maxes out my 2011 macbook air's cpu while staying under 200MB of RAM (and maybe another 500 for multiple postgres connections). It basically runs in the background on a computer that can barely handle Firefox with multiple tabs open. The only real bottleneck of my crawler is bandwidth (my internet speed). The performance you get out of the box is insane. And my app really sucks (individual database inserts, saving the entire html to the database, etc).
The transition to a functional language is not exactly a cakewalk and I honestly still miss ruby's ability to be able to hack through arrays (no way to easily get the nth element of an array, it's all head|tail recursion) and hashes (nothing like hash[:key]) to make something "work" but the pipe operators and pattern matching are addictive. The eco system is not "opinionated" at all aside from the constraints of erlang. Documentation is crystal clear. Most of the phoenix stack can be used as stand alone libraries/dependencies. There's a lot less magic and most of the "magic" comes from macros which are much more transparent.
I'm honestly excited for web programming again after being burned out on legacy rails app development and deployment. Mix is like gems/bundler/rails {console, server, etc.} in one neat package done right and minus the headaches. Jose Valim and Chris Mc Chord are brilliant but are very approachable and all around nice people to interact with. In my short time with Elixir/Phoenix I'd say the "hype" actually understates the true potential of BEAM for web development and tiny startups. Also there's also LFE (lisp flavoured erlang created by one of the creators of erlang) you can add to the mix (similar to what you have with Scala/Clojure + Java only with concurrency and multicore out of the box with a tiny RAM footprint).
Learning Elixir was one of the best investments of time I've made in learning a new language and made programming a "hobby" again for me. Being able to write a naive implementation/prototype of an app and not dreading a "real" deployment (pulling out a bag of deployment tricks or stringing together a slew if external libraries/dependencies) is the most liberating experience I've had in a long time.
I am working full time with Elixir and Phoenix for more than one year now and worked with Erlang before that. It is great to see how well thought out all the abstractions are (both in the language and in the framework). I saw couple of companies cautiously introducing Phoenix in their stack and then going all in. One of such stories will be presented at Erlang User Conference: http://www.erlang-factory.com/euc2016/ben-marx
Comparing to Ruby: Phoenix promises to be as productive as Rails, but more performant and it keeps the promise if all the libraries you need are already ported to Elixir. Even if not, people consider writing them from scratch.
Comparing to Erlang: Elixir fixes a lot of problems like encoding or inconsistencies in standard library. It introduces many new concepts borrowed from Ruby so it might be a little overwhelming for Erlang developers (Erlang is really small and simple language - the hard part is OTP).
Learning Elixir is like learning to touch type. Initially it slows you down, because you have your habits. You need to learn new abstractions, because old solutions just don't work. After short period you are as productive as before. After a month you can deliver hight quality code quicker which is the ultimate goal of every programmer :) And it magically scales on more machines or at least utilizes all of the cores.
If you're like me and didn't want to wait, it's a dead-simple build if you want to DIY:
cd /usr/local/src
git clone https://github.com/elixir-lang/elixir.git
cd elixir
git checkout v1.3.0
make clean test
PREFIX=/usr/local/elixir-1.3.0 make install
And then add /usr/local/elixir-1.3.0/bin to your $PATH.
Yes, kinda - you can compile to an escript, and mix makes that super easy. But it needs an Erlang environment - you can't easily compile to an executable that will work anywhere, so it can be limiting. If you're happy with that limitation, yes and yes to the latter two questions. Otherwise, I'd stick with what you're using.
Without digging into it, the Calendar stuff looks like a strict improvement over Erlang's tuply handling of dates, times and timestamps, which are all tuples with three numbers. This can be confusing/problematic, and something that would benefit from typing to avoid mixing up Dates with Timestamps, say.
Yes, it absolutely is an improvement over erlang-style tuples IMO, and it also vastly improves the interoperability story between the stdlib, date/time/calendar libs, and database libs.
This is good news, since a few tooling improvements have made it back to the Erlang ecosystem in general (and to lfe.io in particular, which I prefer over Elixir).
It handles all the basic things I needed to get an app up and running, and supports hot-code upgrades. It supports multi-host deployments, but I think if you want auto-scaling you'll need to do some more work.
One thing to be aware of is that if you're deploying any NIFs or any native-compiled code, not BEAM, then you can't deploy directly from Mac to Linux servers, you'll need to use VMware or VirtualBox or something to actually do the builds. This includes any packages you use which are using natively-implemented code, which I'm pretty sure includes packages that do password hashing and such.
We have a small React/Elixir/Phoenix webapp in production, and we deploy it using https://github.com/bitwalker/exrm, https://www.go.cd/, and https://saltstack.com/. I'm not the devops guy myself so I don't fully understand how much work was involved in getting all this set up, but I am extremely pleased with the results!
Thank you (and the whole elixir team) for all the work you do on this. I've been building my startup's app with ember and elixir and it's going really well.
I recently had to go back to a rails app to do some work and missed some Elixir features already and I've started writing my ruby code in a very elixir way. (well, a functional way).
It is essentially a big pile of macros, so sometimes number of keywords that you have to keep in your head is staggering. Also, Elixir is a pretty big language - I knew Erlang before diving into it - so the barrier and number of concepts that you have to get familiar with is huge. Don't get me wrong - all these concepts/design patterns are necessary (I am thinking about BEAM and OTP here). Erlang (and therefore Elixir) is complete as development environment, that's where the amount of knowledge is coming from.
Cool intro to erlang/BEAM: http://www.slideshare.net/BrianTroutwine1/erlang-lfe-elixir-...