I'm a hardcore Ruby fan who moved to Elixir and rarely writes/maintains Ruby code. The language grows on you and once you master it, there's nothing quite like it.
You could argue this for other languages - But, I am an experienced programmer who has written production applications in quite a handful of major languages and frameworks out there. I've tried almost everything that trended on HN in the past years - Scala, NodeJS, Ruby, Python, GoLang, R, PHP, Java, and a handful more and I can tell you this - there's nothing quite like Elixir for me till date.
These days, even for my consulting work, I use Elixir. It's almost as if I just push code and forget. (Except for watching out for security vulnerabilities, other regular audits). Everything isn't as green since it's a fairly new language, there's still libraries lacking for some basic stuff - such as authentication (only a handful of them are maintained). But still, I wouldn't consider downgrading to anything else.
Elixir has drastically improved my productivity, and you get to find errors in compile time, leading to much, much better quality, reliable code. I love how fast I can develop apps, SPAs and what not with Elixir/Phoenix. Coming from a NodeJS experience, Elixir is a 100-fold upgrade from JS. In fact, you will realize how terrible JS is (as a language) once you start programming in Elixir.
The closest to Elixir that I like is Scala. They are almost like cousins. Elixir runs on Erlang's VM, Scala runs on JVM. In fact, I prefer Scala.js for my frontend these days, which converts Scala code to JS with strong typing support.
But, Scala is more verbose and way too advanced for someone new to the language. There's a 101 ways to do the same thing and it's very academic as well (The Scala book was over 700 pages when I bought it).
If you are looking for a new language/framework to learn in 2019 - pick Elixir + Phoenix. If not, then go with Ruby + Rails, you couldn't be wrong with either choice.
I would really like to try Elixir or Erlang, but the learning curve seems steep and I haven't heard much in the way of specifics to justify why it would be a good time investment (just "supervisor trees are the shit!" and "functional languages are great!"). I'm particularly wary of dynamic languages; I program in Python and JavaScript all day, but I use Go and TypeScript in my spare time and find myself both more productive and more confident that my code works as intended. I'm aware that Elixir has some sort of optional typing, but the vibe I get is that few really use it and it's not very practical. I would be really interested to hear someone speak to these concerns.
You sound like you have similar tastes to mine. If so, I'm guessing Scala.js's slow compiles and heavy output size is an annoyance. Check out BuckleScript/ReasonML. Reason provides a new syntax for OCaml, in a way like what Elixir does for Erlang. Compile times are instant (I'm not exaggerating ... much), type system and inference are powerful (more than Scala), and output is extremely minimalistic ES5.
> I'm guessing Scala.js's slow compiles and heavy output size is an annoyance
Compared to BuckleScript, sure, but that's an extreme outlier, near instantaneous whole project (wtf) compilation times with tiny output is most definitely not the norm.
As a Scala.js user that is also subjected to the Angular/Ionic/Webpack world, the former is very fast, as in, 1-2 seconds incremental compilation, whereas the latter is a lumbering beast, often taking over 10 seconds for "live reload" for even the simplest of changes.
In terms of output size, yes, there is the Scala collections "tax" (@150KB), but thereafter the bang-for-buck factor pays off -- all the power of Scala with minimal increase in bundle size.
I’ve been working in Node for a few years now, on a project that suffers a lot of warts from adopting Node early and not benefitting from the wisdom of the group.
Something I didn’t know about myself as a full stack developer is that I work on UI because I like human factors, and I work on backend because I like solving architectural or data problems and sometimes I’m just tired of writing Javascript.
Trying to homogenize everything at work removes a vey important pressure relief valve, both for individuals and team dynamics.
I figured this out about a year ago and if not for major life events I’d be out there somewhere writing Elixir or Rust or Scala code.
ES6 and beyond has some things worth experiencing so I’m focusing on that as much as I can. Just a few more months and I can pivot outta here.
I haven't used elixir but I my productivity with Django is much bigger than when compared with other solutions like php, node, java/spring, c#.net etc.
I am talking about good ol' traditional web apps, no fancy spa stuff where I can use Django in all its glory: cbvs, forms, admin, auth and the huge package ecosystem.
Give it a try if you haven't, even just the Django tutorial should give you a hint of the productivity enchantment you'll have!
One thing that plagues us about async Python in production is the propensity for a single synchronous call to bring down a server. The problem tends to be difficult to debug since it often manifests itself in timeouts for requests that aren't actually issuing the blocking request, but for which can't be serviced because the event loop is blocked nonetheless. It's also easy to add bugs in async code (e.g., forgetting to 'await' and getting back a promise instead of a response object). Of course, we could stick with sync Python, but that has lots of other problems (namely it's difficult to pack Python server processes onto hosts with passable efficiency).
Elixir and Go just skirt these problems altogether because all I/O is async under the hood (no need for "await" keywords), and both languages support efficient concurrency and parallelism. One process can fully utilize a host.
Of course, this doesn't speak to the quality of available web frameworks, which may or may not matter for your application.
Not a Python dev but I worked a lot with Ruby performance a lot for the past few years.
Do you really need async IO? Even at Google scale[1] it's kinda a waste of time for web/job servers and only required for proxying etc. The overhead of threads is massively overstated [2]
Ruby scales a long way using Puma or Phusion Passenger with one process per core (just like NodeJS) and adding threads until you hit CPU saturation. Python must have something similar?
You don’t understand the problem you’re criticizing. If you’re using an async web framework like aiohttp and something in the depths of one of your routes does sync IO, it will block your event loop. Nothing clever required.
There isn’t a web framework that I’m aware of which magically makes all sync requests async.
Funny that you insult me and then backup my vague comment with more specifics. My point is that you need to be aware of what is blocking all the way down, all frameworks you are using. It is possible, maybe not magical or trivial, to making everything async.
Please don't assume you know what someone understands. Try asking questions when comments seem vague or stupid like mine did.
> There isn’t a web framework that I’m aware of which magically makes all sync requests async.
Waitress gets part of the way there. IIUC Request/response is done via asyncio but the actual web app part uses a thread so you can't accidentally block the whole thing.
Thread per request works because the GIL is released during blocking IO. You only need one process per core and each process runs multiple threads. It saves a massive amount of RAM compared to trying to cram 50 (g)unicorns onto a server.
Of course, I have used Django (and I still do for data-heavy applications). Python and ruby are quite similar syntactically, but very different philosophically. This is beautifully elaborated on this page here: https://rubyonrails.org/doctrine/ and hence my preference for Ruby over Python. Not saying python is bad at all, just that I only have specific use cases I like to use Python for, mostly stuff that needs Pandas.
I've written some rather large python apps with Django and Flask. I'd never voluntarily choose it again over
Elixir/Phoenix. (Only if there was heavy numerical processing or something of the sort where a library like Pandas would be necessary.)
Working with Elixir/Phoenix is a far superior experience in nearly every way for web/api IMO.
I made nearly all of my money with Phoenix and Django in 2018 so I'm probably not biased. For projects that can run on a single machine I'd say that Phoenix is slightly better than Django but Rails is much better than both of them. Metrics: ease of development, developer happiness, ease of debugging, ease of deployment, framework coherence (Django is almost not a framework compared to the other two), the ORM, the underlying language.
Phoenix wins on parallel jobs because thanks to Elixir it doesn't need ActiveJobs or Celery. Django doesn't win on anything IMHO, except maybe the ease to create an admin CRUD (but Rails has a gem for that.)
To add another tool I used, even Django would win against server side JavaScript. I'm using that only in special cases and for demos, because so many more people knows it than other languages.
Considering yours and the other answers I'll definitely give elixir a go. This isn't very easy when you are fully productive with a different tool (Django in my case) and you have projects with expected deadlines...
I'm mostly convinced to take the red pill thought! Can you recommend any good elixir/phoenix learning resources?
Now that I mentioned learning resources I think that you should agree that this is a point where Django wins: Its documentation and learning resources!
You should probably start with Elixir but you can do as I did with Ruby/Rails, start with the framework and learn the language as you need it. If you do, in the case of Elixir you'll probably be puzzled by all the Supervisor and Gen* stuff based on OTP. Hint: GenServers are more or less objects with their own CPU https://hexdocs.pm/elixir/GenServer.html#content and Supervisors are kind of a systemd internal to the language.
I have used Ruby, Python and Node. Built Angular and React apps using Typescript, Coffeescript, Babel. I haven't tried Elixir, but I tried Clojure. It took me sometime to learn the ways of Clojure but now I feel nothing can make me more productive. I simply cannot even think about going back to writing imperative/OOP code and working with no REPL. Clojure makes sense to me today, but if for some reason it stops making sense I honestly can't think of an alternative.
> Elixir has drastically improved my productivity, and you get to find errors in compile time, leading to much, much better quality, reliable code.
Interesting, I haven't seen that as a strong point for Elixir.
Granted I'm comparing it to Haskell and Rust which really give you errors in compile time. They aren't very popular for web dev though and compared to the other languages you list I guess I can see where you're coming from.
Relative to Ruby it's a lot better without sacrificing the rapid prototyping. If you need real correctness then Haskell and Rust are in a class of their own, but they'll never be as fast for hacking (although admittedly Rust has a high ceiling). I think the magic of Elixir is the happy middle ground where you get more correctness than a multi-paradigm highly dynamic language like Ruby with minimal overhead, and then you strengthen the operational story with a deeply embedded crash-and-restart tooling from Erlang/OTP encouraging less statefulness and easier recovery by design across the board.
Relative to Ruby it has more upfront checking of some things. In Elixir, calling a function that doesn't exist or with the wrong number of arguments is something that will error out at compile-time; with Ruby, you don't find out until you run the code with the bad call.
I agree, though, that compared to Haskell and Rust it doesn't give you much. Dialyzer is (intentionally) a fail-open checker that doesn't allow expressing generics; I've had a rough time getting it to tell me my code is wrong. Credo is (intentionally) just a style linter. "Just let it crash" isn't useful when you're talking about code that is going to break because of its structural incoherence (a class of errors type-checker are good at catching), and not because of transient errors in external dependencies.
Elixir doesn't do type-checking by default, but you can rather easily get it to enforce that records must specify certain fields on creation. Other things, like setting up the optional typechecker (Dialyzer) and writing type specifications for your code, take a bit more effort but do help find problems.
Im new (1yr or so) to elixir, never really believed in dialyzer, but a few weeks ago I noticed my vscode started dialyzing my code in real time and it's caught several errors that would have been hard to catch, and whatever vscode plugin I'm using makes it hard to not write typespecs.
Dialyzer really gives you what you put into it. It never false-positives (by design), even while working with limited information, so if you're not writing typespecs, there's only so much it can do.
If, though, you make a habit of writing typespecs for everything, and defining domain-specific types rather than relying just on the primitives, it can get you surprisingly far.
It'll never be as powerful as Haskell or Idris, but it's absolutely a tool all Elixir (and Erlang) developers should be using.
Also, if anyone ever wants an easy way to contribute to open-source Elixir, just start running Dialyzer on popular projects. Every warning that pops up will be a bug, and often they'll be easy to fix.
Ah, you're probably using the ElixirLS extension, IIRC it has an auto-setup process for Dialyzer when it first gets installed. After that one-time setup it continuously typechecks open projects.
I think Rust will get there if you look at say Rocket app and compare to say express app it's about the same amount of code and equally readable but with obvious benefits that Rust has.
Rust is a really fantastic language but trivial examples can be misleading. We run a Rust app in production at ChartMogul.
Real life Rust business logic is much, much gnarlier than in a GCed language like JS. You need to manage memory so you need to deal with references and deref, lifetimes, Box, Cell, ARC etc.
Wow. Coming from a C++ background, why is it necessary to first dereference, then reference again? That is, `&foo`? And why is triple dereferencing needed? There are some `&foo`. I thought I had read somewhere that Rust does auto-ref/auto-deref...
> why is it necessary to first dereference, then reference again?
This is a conversion; * calls the Deref trait. This is used by smart pointers to return the type inside the smart pointer, so for example, Box<T> is kinda like uniq_ptr<T>. So if foo is a Box<T>, then * foo is a T, and & * foo is a &T. Does that make sense?
> And why is triple dereferencing needed?
This can happen in generic contexts, sometimes, you end up with a &&String, so if foo is one of those, * foo is a &String, * * foo is a String, * * * foo is a str, and & * * * foo is a &str. (HN formatting does not like this, haha)
That's what's happening here.
> I thought I had read somewhere that Rust does auto-ref/auto-deref...
Only for method calls, that is, foo.bar() will attempt to auto ref/deref foo.
Getting data from the request to the DB requires dealing with all those memory management issues. The Rust compiler is amazingly helpful but the complexity is still there.
We use Elixir very heavily here at PagerDuty. The vast majority of our services are written in Elixir. There's generally a shared sentiment across engineering that developing in Elixir is indeed rather satisfying.
From a technical standpoint, it's highly suited to our business due to how well it does with concurrency along with its fault tolerance.
Elixir is often said to have similar syntax to ruby but this is overstating it -- Elixir chooses a similar set of tokens in its grammar to Ruby ('def', 'if', naming rules, list/array literal delimiters, atoms/symbols, map keys) but the actual higher level syntax for the most part is very different. (And obviously the semantics have nearly nothing in common as others have mentioned.)
Some clear syntactic differences (that clearly show that the design decisions were driven by building a good language over erlang, that happens to tokenize similarly to ruby, not a ruby-looking erlang powered language):
- ruby uses sigils on variables to confer metadata, no similar syntax in Elixir on bindings
- access modifiers are different (private vs defp)
- map syntax is different (%{} vs {}), tuple syntax doesn't exist in ruby. (could have been swapped if ruby-syntax was a higher goal vs idiomatic erlang being the driving motive)
- function definition syntax is slightly different, but arguably more consistent in Elixir (no do in ruby)
- most of the control flow operations in ruby do not exist as macros in elixir, or have wildly different syntax and vice versa. the only exception i can think of is the humble "if" statement, which is generally avoided in elixir if it can be anyhow
- closures and anonymous function syntax greatly differ
- the entire syntax of pattern matching and deconstruction in elixir does not exist in ruby
- no ternary operator in elixir
- pipelines are central to elixir, no syntax in ruby
I think Elixir's successful adoption by ruby programmers despite having nearly nothing in common with ruby than a similar choice in tokens for parsing (and even then, only when erlang doesn't pull in a different direction) show that just choosing similar tokens to a language can be a good strategy to enticing developers from that language without actually having to make any impactful design decisions (in either syntax or semantics) to favor that goal over others.
I'm learning Elixir right now, and I'm enjoying it so far. I've never learned Ruby, having worked with Javascript, C#, C++, and Python in the past. Interestingly, what prepared me to understand Elixir the best were the Rambda and Bacon.js libraries in Javascript, which use a lot of functional programming concepts.
I've been learning Elixir over the past couple months and writing about it on my "Learn with Me: Elixir" series at https://inquisitivedeveloper.com. The idea was to give any interested developers a way to learn Elixir as I learn it. I do make the occasional comparison to languages like Javascript and C#, but any experienced developer should be able to follow along. I'm getting toward the end of the basics of Elixir and starting to learn about the more intermediate functionality.
I'm looking forward to getting into the more advanced features of Elixir and creating real software with it.
I find it interesting that Elixir is a common upgrade path for Ruby developers. I wonder if that's actually a handicap because the syntax similarities would cause them to make the wrong assumptions about how Elixir works. The syntax is completely new to me, so I had no preconceived notions of what the syntax meant.
> I wonder if that's actually a handicap because the syntax similarities would cause them to make the wrong assumptions about how Elixir works.
In my experience, yup. Most Ruby devs, my self included before playing with Elixir, are not accustomed to dealing with concurrency. They try to make everything synchronous, and it goes downhill from there.
1) I would argue that the pipe operator is *more erlangey than ruby-ey. It is crazily enough possibly the most useful syntactic sugar feature I've ever seen, especially coupled with labelled IO.inspect. I've never had to go down to the debugger, and reverting the inspect is nearly instantaneous.
2) my number one wish-that-will-never happen for elixir would be the inverse of the mutability issue, variables should be immutable by default but have a sigil or postfix (like !) that lets you make it mutable. Of course, as it is, this is trivially implementable as a credo linter feature.
3) I think generally the biggest problem with macros is the risk of nonlocal side effects in your code, and elixir does a nice job of containing it lexically.
> 2) my number one wish-that-will-never happen for elixir would be the inverse of the mutability issue, variables should be immutable by default but have a sigil or postfix (like !) that lets you make it mutable.
Just to clarify for others, and as the article notes, variables aren't "mutable" in Elixir but rather can be rebound. Even rust, where - just like you desire - you have to explicitly tag something "let mut" if you want mutability, will let you re-bind the variable without that tag.
I've programmed in Elixir full time now for two years and I can't recall any times accidentally shadowing a variable has bit me (but I do `mix compile --force --warnings-as-errors`) as part of my development routine, and that has caught it before for me.
(Oh, unless you mean you wish Elixir had _real_ mutability. That _would_ be quite the change, as obviously no functions in the standard library support that and you have to make do with GenServers and the like. I'm not sure I'd like that as the whole language ecosystem is predicated on immutability and message passing...)
While we're throwing out "one wish-that-will-never happen" ideas, though, here's mine: I'd love for Elixir to be able to automatically add guards to functions based on the type spec. That is, if you had this code:
@spec foo(String.t(), MyEnum.t()) :: boolean()
def foo(str, enum) do
# ...
end
I would love it if that got compiled to essentially:
def foo(str, enum)
when is_binary(str) and enum in [:enum1, :enum2, ...] do
# ..
end
In general, dialyzer is the weakest part of the ecosystem for me, and I've had `nil` and other random things sneak into my functions before despite being against the type spec. I'd much prefer to have the function call crash early by just not matching any clauses.
Yes sorry I was being inexplicit about variable rebinding. I'm used to Julia where variable refers to the lexical form.... Identifier? And not to the actual underlying data, which is called the value.
I'll write up my credo linter and see if you like it.
Your guard idea is pretty good, but I would appreciate it even more if those guards existed in dev and test and got yanked in prod.
You can get mutability, you just need to be explicit with it using a GenServer or some other process abstraction. It just has to be explicit via message passing because your local node is just a special case of the overall network topology that Erlang needs to service.
I would love to use Elixir day to day. As the author points out, it's an enjoyable language. I highly recommend every developer to try it out, especially if you've never done any functional programming before.
I sure do love Elixir, the language, the dev experience (code as documentation!!!), the docs themselves are something of a gold standard to me. (If you've ever tried to wade through OCaml docs... you feel me) The only gripe I've had is that when speed is a requirement, I have to reach for other stacks. Erlang is an uptime workhorse, it's just pretty slow compared to the JVM. Speed isn't always the most important thing... I get that. But when it is, Elixir/Erlang has some room to grow. I totally agree though, I wish I could write it every day.
Yip, I'd love to program professionally in it someday. No idea how to get there though. I live in a smallish town in New Zealand and there are two Ruby shops here, no one is doing elixir. I can't imagine getting a remote elixir job without prod experience first. Also, as Beam, OTP etc is quite different, I'd really like to work on that with a team who really know it.
Still, someday in the future, it's a great language.
Elixir & Ruby both seem to be two of the best languages to work in for finding remote jobs. Elixir is new enough to where I think you could show some open source code & get a job without prod experience in it. Especially if you have prod experience in other languages.
I made https://github.com/patrickdavey/caster as a small toy app and I did Advent of code in elixir a couple of years ago. I haven't used it in a while though, it's just hard justifying the time at the moment.
Maybe when my current (remote Ruby) job comes to an end I'll take a look. I fell into my current role, not quite sure where to start finding a remote roll! Anyway, thanks for the reply and encouragement :)
I agree with the author. Elixir and Ruby share almost only the R letter in the name and some name of modules/method/functions. They are two very different languages.
A complaint of mine about Elixir is that `with` is a macro and not a statement of the language. That probably made it easier to implement but moving code inside/outside a `with` is a pain: transform the = into <- and add a comma at the end of the line. This is against programmer happiness.
The feature I love most is pattern matching in function arguments. It makes the code more readable by removing almost every single case/if.
Then you later mention "programmer happiness". And I think an emphasis on "programmer happiness" is exactly what Elixir and Ruby share, and is probably the reason Rubyists are drawn to Elixir.
Elixir was literally written by a Rails core team member as a response to issues he had in working on enterprise Rails apps. The Phoenix framework as well was written by a long-time Rubyist, and the book they wrote together, Programming Phoenix, reads in places like a treatise on lessons learned from working with Rails.
So Rubyists (I myself have been one since 2011) are drawn to it because it essentially has been billed as a successor to Rails when you need to be concerned with highly concurrent, fault-tolerant, TDD-driven web apps. Most companies who have embraced it are former Rails shops... most devs who use it are former Rails devs.
`with` is an oddball. It's a macro but it's also a special form that has unique syntax that's not used anywhere else. It's basically the only variadic function in the language and it doesn't fit IMO.
It could have been implemented without needing the same special treatment with something like:
with do
x <- foo()
y <- bar(x)
z <- baz(y)
blah(z)
else
err -> handle_err(err)
end
with
x = foo()
y = bar(x)
z = baz(y)
blah(z)
else
err -> handle_err(err)
end
No do (uselessly verbose, it litters all the language) and = instead of <-
It should be normal code and take the else branch whenever there is any error, pattern matching included. The advantage is that the code can be indented in or out a with block, without any change. Much more convenient.
> In Elixir, we avoid using try/rescue because we don’t use errors for control flow. We take errors literally: they are reserved for unexpected and/or exceptional situations.
> No do (uselessly verbose, it litters all the language) and = instead of <- It should be normal code and take the else branch whenever there is any error, pattern matching included.
Using '=' insead of '<-' would break how with works. I can understand why one thinks the syntax looks weird. I avoid with when possible, but sometimes it's the easiest abstraction to use.
I think generally the issue of when to use <- and when to use -> and when to use = is one of the few things about the language that makes my head spin.
<- is used for with as well and that is not a comprehension, and in feel way more like an = pattern match. -> is used in lambdas, which is kind of like case (but not cond).
Very nice article! I gotta admit I felt/feel the same way, I really like Erlang and although I also like Ruby, Elixir felt/feels weird to me and I don't see why I wouldn't write Erlang instead.
I think this post has managed to convinced me to try what's on the other side of the fence for a bit.
elixir remains my favorite language. i code in java/kotlin daily and while I love all the things that kotlin provides over java (including the functional support via arrow-kt), I still find myself writing elixir whenever I have a pet project at home.
I've been learning Elixir as well and practicing my Elixir with this year's Advent Of Code. So far, I've really been enjoying writing in Elixir but if there's one thing I wish it was better at, it would be debugging in Elixir. Maybe its because I'm so used to using Chrome's developer tools, but I wish there was something as easy and simple to use like that for debugging Elixir.
Elixir's comparisons with Ruby are almost totally superficial. It borrows only high-level concepts from Ruby (strong metaprogramming, clean syntax, concise stdlib, excellent tooling, excellent testing tools, REPL)
Elixir's stdlib is designed completely differently though and the design patterns and execution models are completely different
You could argue this for other languages - But, I am an experienced programmer who has written production applications in quite a handful of major languages and frameworks out there. I've tried almost everything that trended on HN in the past years - Scala, NodeJS, Ruby, Python, GoLang, R, PHP, Java, and a handful more and I can tell you this - there's nothing quite like Elixir for me till date.
These days, even for my consulting work, I use Elixir. It's almost as if I just push code and forget. (Except for watching out for security vulnerabilities, other regular audits). Everything isn't as green since it's a fairly new language, there's still libraries lacking for some basic stuff - such as authentication (only a handful of them are maintained). But still, I wouldn't consider downgrading to anything else.
Elixir has drastically improved my productivity, and you get to find errors in compile time, leading to much, much better quality, reliable code. I love how fast I can develop apps, SPAs and what not with Elixir/Phoenix. Coming from a NodeJS experience, Elixir is a 100-fold upgrade from JS. In fact, you will realize how terrible JS is (as a language) once you start programming in Elixir.
The closest to Elixir that I like is Scala. They are almost like cousins. Elixir runs on Erlang's VM, Scala runs on JVM. In fact, I prefer Scala.js for my frontend these days, which converts Scala code to JS with strong typing support.
But, Scala is more verbose and way too advanced for someone new to the language. There's a 101 ways to do the same thing and it's very academic as well (The Scala book was over 700 pages when I bought it).
If you are looking for a new language/framework to learn in 2019 - pick Elixir + Phoenix. If not, then go with Ruby + Rails, you couldn't be wrong with either choice.