
Elixir v1.1.0 Released - sadiqmmm
https://github.com/elixir-lang/elixir/tree/v1.1.0
======
dv_says
I'm really glad to have recently picked up Elixir. For anyone just starting, a
few tips from someone similarly new:

a. After launching the "iex" shell, press Tab. You'll get the list of all
built-in commands.

b. The help feature is also very handy for when you're wondering what an
operator does. Type "h <command>" for a definition.

    
    
        h !/1
    

c. Try the pipe operator. Your code will closely follow the transformations of
your data.

Instead of this:

    
    
        m1 = "moo"
        m2 = String.replace(m1, "m", "z")
        m3 = String.upcase(m2)
    

Or this:

    
    
        String.upcase(String.replace("moo", "m", "z"))
    

Try this:

    
    
        "moo" |> String.replace("m", "z") |> String.upcase()
    

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

~~~
derefr
I want to rave a little bit about this:

    
    
        "moo" |> String.replace("m", "z") |> String.upcase()
    

This is always what I thought OOP _should_ be, but could never put my finger
on. Effectively, you're calling a chain of "methods" of "objects", but each
method lives in its own namespaced module, rather than automatically being
assumed to live in the class associated with the data. No "this object
implements two interfaces that both define add()" confusion; no objects
extended to infinity with extra mix-ins and interfaces just so that more
methods could be called _on_ the object rather than having the object _passed
to_ utility functions; etc.

And when you _do_ use classes (Structs), there's line-local context-free
crystal-clarity between code that expects a generic object expressing one of
the class's interfaces (where calls are made on the interface's Protocol
module) vs. code that expects that particular class (where calls are made on
the class's module, which contains the _implementations_ of the Protocol
functions.)

~~~
e12e
See also:

Smalltalk faq: "Q28. What is the difference between chaining and cascading?"

[http://www.ipass.net/vmalik/smalltalk.html#Q28](http://www.ipass.net/vmalik/smalltalk.html#Q28)

~~~
TranquilMarmot
So, pretty much whether everything is being applied right to left vs being
applied left to right?

Personally I like chaining because, since I read going right to left, in my
head I can go "x goes to y then the result of y goes to z" versus "z is the
result of y which is the result of x" (reading it backwards)

~~~
e12e
I wasn't clear, but I meant that mostly as a comment to:

> This is always what I thought OOP should be, but could never put my finger
> on.

I'm not sure what Simula did, but at least in Smalltalk this is how OOP _have_
worked :-)

> So, pretty much whether everything is being applied right to left vs being
> applied left to right?

I'm not sure that's the best takeaway; consider:

    
    
        $ gst
        GNU Smalltalk ready
    
        st> 2 * 3; * 3; * 3
        6
        st> 2 * 3 * 3 * 3
        54
    

Now, if the object on the far left was some kind of accumulator/container, the
effect of sending something like three "add the number 3" would be similar to
chaining. But even if you mulitply the number 2 by 3, three separate time, 2 *
3 still equals 6.

In fact, in order to get chaining with keyword messages, you apparently need
to define it, or especially adapt eg: containers to return ^self. But as
should be obvious, I'm not very familiar with Smalltalk. Some more on the
subject: [http://blog.3plus4.org/2007/08/30/message-
chains/](http://blog.3plus4.org/2007/08/30/message-chains/)

------
yumraj
Some random thoughts and impressions:

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 ;)

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

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

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

[1]
[http://www.paulgraham.com/pypar.html](http://www.paulgraham.com/pypar.html)

~~~
simoncion
I can't speak to Elixir/OTP, as I've not -yet- used Elixir. However, every
time I've gone to use something in the Erlang/OTP standard library [0] it has
_always_ been far less complicated and far more well designed than I feared it
was going to be.

Maybe this is a reflection of my pessimism, but I feel that it is _actually_ a
reflection of the quality of the software. :)

[0] Yes, I know that Elixir is a BEAM language and -as such- has access to
both Erlang and OTP, so this distinction is _terribly_ fine. ;)

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

[edited]

~~~
smt88
> _frankly don 't think it is the right tool for large, multi-person code
> bases_

I'm very curious what aspects of Python (especially unique to Python) made you
feel this way.

~~~
lectrick
Mutability and OO, I'd guess. :P

------
chrismccord
The changelog details all the good stuff in this release
[https://github.com/elixir-
lang/elixir/releases/tag/v1.1.0](https://github.com/elixir-
lang/elixir/releases/tag/v1.1.0)

For anyone wanting to jump into Elixir, the getting started guides are
excellent: [http://elixir-lang.org/getting-
started/introduction.html](http://elixir-lang.org/getting-
started/introduction.html)

From there, José Valim wrote a How I Start article:
[https://howistart.org/posts/elixir/1](https://howistart.org/posts/elixir/1)

There's also a really helpful community on #elixir-lang irc. Someone is
usually around to answer questions.

~~~
dwc
> getting started guides are excellent

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.

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

[0]
[http://doc.akka.io/docs/akka/2.4.0-RC3/java.html](http://doc.akka.io/docs/akka/2.4.0-RC3/java.html)

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

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

~~~
rattray
There's also Quasar for Java, Clojure, or Kotlin code

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

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

------
gjkood
Here is my highly opinionated 2 cents.

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.

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

~~~
Jtsummers
[http://www.erlang.org/doc/man/escript.html](http://www.erlang.org/doc/man/escript.html)

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.

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

[https://github.com/elixir-
lang/elixir/blob/v1.1/CHANGELOG.md](https://github.com/elixir-
lang/elixir/blob/v1.1/CHANGELOG.md)
[https://github.com/phoenixframework/phoenix/blob/master/CHAN...](https://github.com/phoenixframework/phoenix/blob/master/CHANGELOG.md)
[https://github.com/elixir-
lang/ecto/blob/v1.0/CHANGELOG.md](https://github.com/elixir-
lang/ecto/blob/v1.0/CHANGELOG.md)

------
vvanders
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)

~~~
rozap
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. :)

------
weatherlight
For anyone who wants practise Elixir exercises akin to ruby koans. Check out.
They are free :)

Études for Elixir
[http://chimera.labs.oreilly.com/books/1234000001642/index.ht...](http://chimera.labs.oreilly.com/books/1234000001642/index.html)

~~~
alxndr
Exercism.io also has a ton of little Elixir exercises (complete with failing
test suite) to get your feet wet. (Lots of other languages too!)

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

Granted, Erlang (BEAM?) processes are appealing.

If you are using Erlang or Elixir, why?

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

~~~
eatonphil
So what differentiates it from Clojure or Racket then (which are ostensibly
more interested in transformations on data)?

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

~~~
eatonphil
I'll have to check that out. Thanks for the reference

------
tedunangst
And the link goes to a page with zero information about what's changed. One of
the reasons editorializing titles is frowned upon.

~~~
rossj
Try CHANGELOG.md, it's pretty thorough.

~~~
tedunangst
Note that on mobile, it's not quite trivial to get there, especially if you
don't know that's what you're supposed to be looking for.

------
Raphmedia
Direct link to changelog: [https://github.com/elixir-
lang/elixir/blob/v1.1.0/CHANGELOG....](https://github.com/elixir-
lang/elixir/blob/v1.1.0/CHANGELOG.md)

------
rubyn00bie
For anyone trying to install from Homebrew, the new formula hasn't been
merged, you can brew edit it, if you need it now... Simply replace the
existing formula, with the new one:

[https://github.com/josevalim/homebrew/blob/patch-30/Library/...](https://github.com/josevalim/homebrew/blob/patch-30/Library/Formula/elixir.rb)

> brew edit elixir

Then just paste the new file in. You'll have to reset this eventually... which
you can do for all your formulas using:

cd `brew --cellar` git reset --hard HEAD

Installs like a charm on El Capitan.

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

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

------
arxpoetica
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."

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

~~~
15155
> CPU parallelism by forking.

Which, minus the IPC, code/dependency sharing, has similar practical
consequences as Erlang/Elixir: no shared heap.

> but instead of using callbacks/promises

At a level as high as JavaScript this doesn't matter, but, green threads are
not as performant as this model would be in a lower-level language.

Edge-triggered, _multi-threaded_ event loops + callbacks are a force to be
reckoned with on the concurrency front.

> 99th percentile latency

Single-core tests? For both Erlang (BEAM) and Node.js?

I'd like to see this testing and the reasoning behind it, though if true, I
suspect it's probably related to GC latency (and the high cost of JS execution
contexts).

~~~
rubiquity
> _Which, minus the IPC, code /dependency sharing, has similar practical
> consequences as Erlang/Elixir: no shared heap._

In Elixir/Erlang every Erlang process has its own heap. In the case of Node.js
and forking, each forked process has its own heap. You can't fork 100,000
times but you can have 100,000+ Erlang processes all with separate heaps and
all in the same process.

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

------
shadykiller
We created our microservice router in Elixir. It is rock solid and even the
deployment is a breeze with exrm.

Even though I am the only one in the team who picked up Elixir, but soon we
will have more. Elixir and its tooling is a welcoming change.

------
eddd
Release notes are not that important, the fact that this post remains on the
top of HM is the best sign that elixir is finally hitting of.

------
scardine
Elixir and Lua are among the few relevant contributions to the computer
science field originating from my country (Brazil).

------
vishaldpatel
I just started learning Erlang. Should I bother, or should I just go ahead and
learn Elixir instead?

~~~
yumraj
IMO, it depends on your background. If you have a lot of functional
programming experience in languages similar to Erlang, I'll say just go ahead
with Erlang.

If you come from a more traditional language background, such as C, C++, c#,
java, scala, ruby, python, js and others, especially ruby since elixir is very
ruby-ish, Elixir is more approachable and I'll suggest that you go with it.

~~~
eggy
LFE - Lisp Flavoried Erlang - is also an option. Created by Robert Virding,
one of the creators of Erlang, it is a Lisp-2 with full access to Erlang and
the OTP. Elixir is cool though too, and certainly is similar to Ruby.

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

~~~
vvanders
It's answered in detail a bit farther down but the tldr is Erlang VM > Java VM
for high concurrency.

~~~
aalhour
Thanks! Will check out the other comments.

------
sadiqmmm
Changelog for Elixir v1.1: [https://github.com/elixir-
lang/elixir/blob/v1.1.0/CHANGELOG....](https://github.com/elixir-
lang/elixir/blob/v1.1.0/CHANGELOG.md)

------
cpitman
I was pretty excited about Elixir: great scalability and performance? Awesome!

I had an idea for a type of reverse proxy, so I wrote in on elixir + cowboy.
Go to performance test it, and the results are nothing to write home about.
Thought I was doing something wrong, but looking around I didn't find any
performance test results that were all that different. What is the point of
"lightweight threads" if the "heavier" solutions are way faster?

Here's TechEmpower's latest benchmark results. Keey scrolling till you get to
an Erlang/Elixir based solution:
[https://www.techempower.com/benchmarks/#section=data-r10&hw=...](https://www.techempower.com/benchmarks/#section=data-r10&hw=peak&test=query&l=2i1e8&a=1)

~~~
unvs
There are multiple pull requests pending to tune those benchmarks, and reports
that the numbers are off by a factor of 10x.

~~~
perishabledave
For reference:
[https://github.com/TechEmpower/FrameworkBenchmarks/pull/1730](https://github.com/TechEmpower/FrameworkBenchmarks/pull/1730)

