
How I Start: Elixir - kungfooguru
http://howistart.org/posts/elixir/1
======
rdtsc
I like Elixir and Erlang. For some Elixir will be an easier and more
accessible path toward using Erlang VM (BEAM), which, I think is an
outstanding piece of engineering.

Elixir besides looking more familiar has macros and can let you re-assign
variables (data structures are still immutable).

Usually I hear complaints about Erlang syntax. My personal opinion is Erlang's
syntax is consistent and elegant. I prefer consistent and elegant over "curly
braces" but with ambiguity and complexity. Usually it is things like thinking
about actors, of functional paradigms (using recursion vs iteration), dealing
with distributed nodes that are much interesting and harder. But everyone is
different, so for those that syntax itself is a stumbling block, Elixir is an
option.

And just to be complete there are also Lisp, Prolog, Lua and basic Python
integration all in various stages of maturity:

[http://lfe.io/](http://lfe.io/)

[http://joxa.org/](http://joxa.org/)

[https://github.com/rvirding/luerl](https://github.com/rvirding/luerl)

[https://github.com/rvirding/erlog](https://github.com/rvirding/erlog)

[http://erlport.org/docs/python.html](http://erlport.org/docs/python.html)
(integration with Python not Python implemented in Erlang)

~~~
jdeisenberg
Another advantage of Erlang's unconventional syntax, as well as its single-
binding variables, is that it doesn't look like a typical imperative language.
Because of this, I'm not as tempted to think in imperative terms when
programming in Erlang. That having been said, I do like Elixir's string-
handling functions.

~~~
exo762
> That having been said, I do like Elixir's string-handling functions.

That's impressive, considering that Erlang and it's standard lib is mostly
string agnostic. I need to do my research on Elixir's libraries.

------
MCRed
Anyone interested in a job programming elixir full time?

We've got a startup-like environment, without the hassle of trying to find
backing or traction.

We get to work with new technology all the time, though we're primarily an
Elixir/Ember shop.

If you're located in Austin or interested in relocating, drop a line to:
jay.prince@clutchanalytics.com

PS- We are running elixir in production, right now.

------
CMCDragonkai
Elixir is awesome. A syntax similar to Ruby, but with all the fault tolerance
and scalability of the Erlang virtual machine. So all the cool stuff of Erlang
with none of the warts!

------
e12e
Is it me, or should there be a bit at the end of how to reach the variables
instantiated in room2 in room1?

I realize the "blue" "channel" is in room1, but shouldn't I be able to
inspect/instantiate some form of "portal" handle on both "sides"?

Other than that, great article.

Btw, there's a recent enough erlang in wheezy-backports to play with elixir,
for those running conservative desktops, like myself.

~~~
e_proxus
To bring it back to a normal Erlang analogy level, the rooms are instances of
Erlang VMs. Since Erlang has isolated memory between processes, the only way
to ask one process in one virtual machine (reaching it either by its
registered name or if you know the pid somehow) for data (i.e. values of
variables) is to send messages to it. You can't access variables/data across
VMs/processes directly, you have to talk to them.

Regarding Erlang on Wheezy, I'd recommend the Erlang Solutions repository with
pre-built and tested packages: [https://www.erlang-
solutions.com/downloads/download-erlang-o...](https://www.erlang-
solutions.com/downloads/download-erlang-otp)

~~~
e12e
I suppose I want the example to show how, when I push data through the portal,
it appears on the other side. I'm guessing the idomatic way has to do
something with registering a function to be called on message/data received on
the "other" end. It just feel like the article could/should be extended a bit
there, to make it "full circle" so to speak.

What's already there is good, but it leaves me hungry for more, and a little
lost as to how to achieve more.

Thanks for the tip on upstream packages for Debian -- I somehow missed the
fact that there was a repo for Debian (well, that, and I already had wheezy-
backports enabled, and it turned out to work fine with Elixir from source).

~~~
alco
I don't understand what you are asking here. The example at the beginning of
the "Distribution" section shows how to get the value from the door in room1
while running on the node corresponding to room2.

The same way you can call 'Portal.Door.get({:orange, :"room2@COMPUTER-NAME"})'
on the first node (the one corresponding to room1).

~~~
e12e
Hm, I believe that is what I was asking :) I'll have to look when I'm back at
my computer with the example code (and and more importantly an elixir
install).

~~~
e12e
Ok, now I see a little more of how things are connected. In my opinion, it
would've been nice to be a) more explicit about the naming/aliasing of
blue/orange in the final section, and b) Show how to actually read data sent
from room2 in room1, eg:

    
    
        # Start session for room1, shoot orange portal in room1
        $ iex --sname room1 --cookie secrit -S mix
        iex(room1@COMPUTER-NAME)1> Portal.shoot(:blue)
        {:ok, #PID<0.67.0>}
    
        # Start session for room2, shoot orange portal in room2
        $ iex --sname room2 --cookie secret -S mix
        iex(room2@COMPUTER-NAME)1> Portal.shoot(:orange)
    
        # set up aliases/variables for blue/orange in room2
        iex(room2@COMPUTER-NAME)1> blue = {:blue, :"room1@COMPUTER-NAME"}
        {:blue, :room1@COMPUTER-NAME}
        {:ok, #PID<0.68.0>}
        iex(room2@COMPUTER-NAME)3> orange = {:orange, :"room2@COMPUTER-NAME"}
        {:orange, :room2@COMPUTER-NAME}
    
        # Use aliases to set up portal transfer in room2
        iex(room2@COMPUTER-NAME)4> portal = Portal.transfer(orange, blue, [1,2,3,4])
        #Portal<
          {:orange, :room2@COMPUTER-NAME} <=> {:blue, :room1@COMPUTER-NAME}
                        [1, 2, 3, 4] <=> []
    
        iex(room2@COMPUTER-NAME)5> Portal.push_right(portal)
        #Portal<
          {:orange, :room2@COMPUTER-NAME} <=> {:blue, :room1@COMPUTER-NAME}
                           [1, 2, 3] <=> [4]
    
        # set up aliases/variables for blue/orange in room1 (saves typing!)
        iex(room1@COMPUTER-NAME)2> orange = {:orange, :"room2@COMPUTER-NAME"}
        {:orange, :room2@COMPUTER-NAME}
        iex(room1@COMPUTER-NAME)3> blue = {:blue, :"room1@COMPUTER-NAME"}
        {:blue, :room1@COMPUTER-NAME}
    
        # Anything in the door?
        iex(room1@COMPUTER-NAME)4> Portal.Door.get(orange)
        [4, 3, 2, 1]
        iex(room1@COMPUTER-NAME)5> Portal.Door.get(blue)
        []
    
        #Switch to room2, push a value:
        iex(room1@COMPUTER-NAME)6> Portal.Door.get(blue)
        [4]
        iex(room1@COMPUTER-NAME)7> Portal.Door.get(orange)
        [3, 2, 1]
    
        # Verify that we're communicating, in room1:
        iex(room1@kuromaki)6> Portal.Door.get(blue)
        [4]
        iex(room1@kuromaki)7> Portal.Door.get(orange)
        [3, 2, 1]
       

I'm still not entirely clear on if it's possible to access the "portal" from
both rooms [edit: to call push_right from room1 on the portal instantiated in
the session in room2] -- could I get at it from room1 by qualifying it with
room2@COMPUTER-NAME? If so what would the implications be? I assume functions
are called via message passing, so this would be safe?

I think a lot of the stuff up to the very last bit is good, I just feel the
article stops a little short. Maybe I just need to read it again (and play
more with elixir).

------
arms
I love the concept of Elixir, but is it used out in the wild much? A
language's popularity, or lack thereof, has little influence on whether I'll
learn it or not, but I'm always curious about this.

~~~
careersuicide
I use it for some minor automation tasks at work (munging data in files and
the like). That's one of the coolest things about Elixir in my opinion; it's
great for the kind of stuff you used to use Perl for, while still being
fantastic at the kind of stuff Erlang is used for. I'm obviously not using the
full power of the language by any means and I'm yet to use all the OTP stuff
except for toy applications for fun. But it's a refreshingly enjoyable
language to work in. I haven't built anything that a client has directly paid
for with Elixir yet, but sooner or later I hope to get something like an
Elixir version of one of our Rails apps going in my free time and convince my
boss we should give it a try for real.

~~~
arms
I definitely see how this would be useful for automated tasks. I have some
python scripts doing a fair bit of automated data munging that would probably
benefit from being written in Erlang/Elixir.

Slight tangent - people often say learning Haskell is worth it for the eye
opening experience it provides, regardless of whether you get to use it day-
to-day. Would you say the same of Erlang and Elixir?

~~~
careersuicide
Funny you should ask. I actually started giving an honest go at learning
Haskell before I started learning Erlang and later Elixir. So for me, I
wouldn't say they were as eye opening as Haskell (truthfully Common Lisp and
Scheme gave me more "woah!" moments than anything else so far) simply because
of the order in which I learned them.

However, if you've never learned Haskell, OCaml, or F# I don't think it's a
stretch to say that Elixir/Erlang's similar use of pattern matching and guards
would have an eye opening effect that makes it worth learning. In both Haskell
and Elixir/Erlang they're a core part of using the languages idiomatically.
Once you see it in action you'd be hard pressed to not take some of the
lessons with you elsewhere.

So, yes. Elixir and Erlang will make you rethink some assumptions about how to
solve problems you probably never knew you had. Such as the "necessity" of
explicit conditional statements. If anything you'll get better at using
recursion to solve actual problems instead of just for contrived classroom-
type problems.

------
glesica
I am kind of a fanboy for this concept and I'm super excited that Jose was
willing to contribute a write-up! Elixir is an incredibly exciting language in
my opinion, mixing some of the things that attracted me to Python years ago
with some extremely powerful tools and capabilities borrowed from Erlang's
virtual machine, check it out!

------
rubiquity
If you're out shopping for a new language to learn, I would recommend giving
Elixir as much (or more :)) weight as you might give Go, Rust or Clojure.

Here's a few things that I really like about Elixir:

\- There's a ton of great resources already out for learning Elixir. José's
article here is a good intro but Elixir's official website has a very in-depth
getting started guide[0]. Dave Thomas, the author of Pragmatic Programmer and
Programming Ruby (arguably the book that helped Ruby grow pre-Rails), has
written a great book titled "Programming Elixir"[1]. Authors at Manning and
O'Reilly are also working on Elixir books to the best of my knowledge.

\- Elixir ships with a great build tool, task runner and dependency manager
named Mix. There is also a package manager already built named Hex[2].

\- Elixir compiles directly to Erlang byte code, so you get to not only take
advantage of a very mature virtual machine, but you also get direct
interoperability with Erlang libraries! This gives Elixir a robust ecosystem
of tools and libraries to use right out of the gate so you can be productive.

\- I try not to judge a language by its syntax anymore, but I realize that
some do. If that's your thing, Elixir has a Ruby-inspired syntax as well as
great support for metaprogramming via macros.

\- Elixir development is going very fast and the language is stabilizing more
and more by the day. If you need the "1.0 stamp of approval", that should only
be weeks to a couple months away at most. The community feels very strong for
a language this early in the game. The creator of the language, José Valim, is
also very fair and considerate when discussing the language.

\- The pipe operator lets you take all of your small functions and easily show
the flow of how the operations are applied. This is one of the killer features
of Elixir for sure and I'm not sure when I'll feel like I've overused it.

\- Testing is at the very forefront of Elixir. All projects generated using
Mix (the build tool described above) come with a ready to go test runner. You
can also embed tests in the documentation of your code and they too will be
tested for correctness.

Now, to be fair, here's a couple things to keep in mind when learning Elixir.
These might seem like negatives or challenging at first, but they quickly
become some of your favorite parts of Elixir:

\- Elixir is a functional programming language, so that can be quite different
as most of us on HN I feel come from OOP backgrounds. You have to stop
thinking in classes, methods and state and start thinking about data
structures, functions and immutability. Elixir is dynamic though, so picking
it up isn't quite as challenging as learning a functional language and type
system at the same time.

\- Pattern matching and recursion are going to be at the core of writing
expressive systems. Thinking about problems recursively is mind-bending at
first but will start to feel natural. Pattern matching will both make you
never look at an equals sign the same way again and help you write very easy
to understand function bodies.

\- OTP and its well thought out patterns are going to be pervasive to your
Elixir programs. If you've ever ran into an Erlang zealot, they probably were
ranting and raving about how well Erlang scales and handles failure. OTP and
the Erlang VM are the secret sauce. How this all gets accomplished will feel
very foreign at first (thinking in Supervision trees and message passing) but
stick with it.

0 - [http://pragprog.com/book/elixir/programming-
elixir](http://pragprog.com/book/elixir/programming-elixir)

1 - [http://elixir-lang.org/getting_started/1.html](http://elixir-
lang.org/getting_started/1.html)

2 - [http://hex.pm](http://hex.pm)

~~~
fisher-lebo
I've considered Elixir as something worth picking up next, but my question is,
why would I chose it over Clojure when Clojure gives me similar functionality
(macros, some concurrency), but much deeper library options?

~~~
klibertp
The concurrency model of Clojure is different than that of Erlang (and
Elixir), especially Erlang is easier to scale to many machines (it's actually
built right into the language/VM).

But to be honest, I think you should just learn both. Clojure is an
interesting language, even if I disagree with some design decisions (no reader
macros...), with interesting capabilities and so is Erlang and even more so
Elixir, but that's really the end of similarities between them. Error
handling, metaprogramming, concurrency and pretty much every other aspect of
these languages are different, so learning both is not redundant IMHO in the
least.

~~~
kaonashi
Out of curiosity, what use cases do you have for reader macros that tagged
literals do not cover?

[http://clojure.org/reader#The%20Reader--
Tagged%20Literals](http://clojure.org/reader#The%20Reader--Tagged%20Literals)

------
amrtn
¿No RSS or ATOM feed available? Feedly doesn't find any feed on
[http://howistart.org/](http://howistart.org/)

I know I can get updates by twitter but feeds are a commodity I'm used to :(

~~~
saraid216
[https://dev.twitter.com/discussions/1603](https://dev.twitter.com/discussions/1603)
?

------
polysics
I work in the telephony field, and Erlang comes up every other sentence. I
have limited experience with that, but Elixir in my opinion makes it far
easier to jump in.

I sort of agree with the common argument about OTP needing a rename, but in
the end if a developer can't get past a name, he can't get past a lot of other
things either.

~~~
delian66
What is wrong with Outlaw Techno Psychobitch [1] ?

[1] [http://www.gar1t.com/blog/erlang-the-movie-ii-the-
sequel.htm...](http://www.gar1t.com/blog/erlang-the-movie-ii-the-sequel.html)

------
resca79
Yes it is nice language, but why the author did not create a ruby
implementation over Beam? Maybe elixir has extra features than ruby, so why he
does not create a superset of ruby? Try to image all ruby gems that support
the feature of Elixir at zero cost, instead we have a new language new libs...

~~~
klibertp
Ruby semantics wouldn't map to BEAM cleanly. Pervasive immutability, error
handling and concurrency constructs are very different between Ruby and
Erlang, I don't think trying to bridge the gap would be an easy task.

