
Sketches of Elixir - signa11
https://blog.zdsmith.com/posts/sketches-of-elixir.html
======
neya
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.

~~~
spapas82
Have you tried python/ Django?

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!

~~~
weberc2
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.

~~~
jashmatthews
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?

[1] [https://www.slideshare.net/e456/tyma-
paulmultithreaded1](https://www.slideshare.net/e456/tyma-paulmultithreaded1)
[2] [https://eli.thegreenplace.net/2018/measuring-context-
switchi...](https://eli.thegreenplace.net/2018/measuring-context-switching-
and-memory-overheads-for-linux-threads/)

------
mistinthewind
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.

Here's a nice blog post by one of our Principal engineers on Elixir, it's a
great read: [https://www.pagerduty.com/blog/elixir-at-
pagerduty/](https://www.pagerduty.com/blog/elixir-at-pagerduty/)

------
gfodor
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.

------
Maultasche
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](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.

~~~
PopeDotNinja
> 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.

------
dnautics
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.

~~~
losvedir
> _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.

~~~
dnautics
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.

------
mattferderer
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.

It has one of the best communities around.

~~~
patrickdavey
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.

~~~
mattferderer
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.

~~~
patrickdavey
I made
[https://github.com/patrickdavey/caster](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 :)

------
pmontra
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.

~~~
jimbokun
"They are two very different languages."

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.

~~~
brandall10
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.

------
baby
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.

------
thegabez
I've always wondered what Kubernetes would be like if it was written in
Erlang/Elixir instead of Go.

~~~
danellis
Unless you're one of its developers, probably exactly the same.

~~~
thegabez
For example would nodes have more resiliency?

~~~
danellis
What makes you say that?

------
holtalanm
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.

~~~
iLemming
Have you tried Clojure. Elixir borrows many ideas from Clojure. Author of
Elixir himself stated that numerous times.

~~~
holtalanm
I have. I like Clojure, as well.

------
wmock
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.

~~~
xutopia
Have you tried using IEx.pry?

------
jb3689
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

------
rs86
Noooooooo it's erlang with Ruby syntax, powerful meta programming, ad-hoc
polymorphism and many other things...

------
Exuma
I completely love elixir

------
gcb0
I always assumed most people arriving at Elixir were Erlang neophytes, and as
such, had never seen Ruby.

Maybe the ruby crowd is more pronounced in the elixir IRC inner circles?

~~~
qaq
? Most of the adoption I've seen for Elixir is Ruby shops (and I am not a Ruby
developer).

