
Learn Elixir with a Rubyist (IV) – Types, Data Structures and Pattern Matching - joaomdmoura
http://joaomdmoura.com/articles/learn-elixir-with-a-rubyist-episode-iv
======
rebelidealist
As a Ruby programmer trying to take a look at Elxir, i still find it hard to
read. Maybe functional languages take time to get used to but it doesn't seem
as "clear" as procedure or oop style. I know the added benefit of speed and
concurrency, but for most apps we build it is not needed for now.

Do any Ruby programmer find Elxir easier to write or read? Im genuinely
curious to hear about this because a lot of Ruby devs are writing Elixir.

~~~
gamache
I slung Ruby 2008-2015, and started using Elixir heavily in late 2015. Aside
from simple scripts that typically involve shelling out to Unix utilities, I
find Elixir easier to write in just about all cases at this point. The syntax
is even more consistent than Ruby's (to the point that it's homoiconic) and
the language docs rule. Once you get a few concepts like pattern-matching and
pipelines under your belt, it gets easy.

It was helpful that I wrote a bunch of Scala from 2013-2015, so I was familiar
with working in an immutable FP style -- that made it a gentler transition for
sure.

What have you found hard to read about it? The community is still settling on
what code style "should" look like, so maybe you saw some funky Elixir, or
maybe it's something deeper.

~~~
jablan
> What have you found hard to read about it?

Not the OP, but: keeping state: Agents, GenServers etc. FP/immutable approach
does offer some great advantages, but also makes some otherwise trivial stuff
(say, something akin to setting an ivar in Ruby) convoluted and tough to read.

~~~
gamache
Elixir does make you think hard about the global state you keep. It's an "eat
your vegetables" decision, and I've acquired the taste. Keeps me out of
trouble when designing things. Contrast this to Ruby, where class variables
and globals are all over the place and thread safety is a pipe dream. [EDIT:
it's not that Ruby-the-language forces this worldview, but Ruby-the-community
adopted it and most Gems show the effects of that.]

As far as ivars, you'll have to work hard to emulate that. There are no
classes or instances. Probably you want to just use a map or a struct to
represent an instance and its state.

------
raarts
Can the Ruby people please stop blogging about Elixir and explain things
relative to Ruby? There are way too many 'Elixir-for-Ruby-programmers'
tutorials on the net already.

Elixir is pretty great and enthusiasm is good but I feel this leaves a large
group of people in the dark.

~~~
sotojuan
The last thing I want Elixir to be is shoehorned into the web app space and
community of Ruby, but it seems inevitable. Oh well.

~~~
enraged_camel
This might be a controversial thing to say, but Ruby would be a pretty obscure
language today if it wasn't for Rails.

If you want Elixir to remain obscure as well, keep hoping that it doesn't get
picked up by web developers and Rubyists.

I for one want the language to eventually overtake Ruby in popularity
(hopefully with Phoenix overtaking Rails). So yeah, the more individuals and
communities that adopt it, the better.

------
aecorredor
If you had to make a comparison, what would be the pros and cons of using
elixir vs node.js?

~~~
vikingcaffiene
I'm currently working in both. If we are just talking about them in terms of
their respective merits, Elixir is my preference. It has a wonderful compiler,
pipes allow for composable chains of logic, the Phoenix framework is wonderful
for web development. Literally every interaction with it I've had has made me
think "wow that's just a great example of excellent programming taste...". In
terms of scaleablilty, I've heard stories of a single server able to handle
millions of requests. Not personally been able to verify that (nothing I've
done in the language has reached that kind of scale sadly...). Once you get
used to pattern matching, you'll wonder how you ever lived without it. The
community is amazing and supportive. The language creator Jose Valim has
responded to my emails directly which is really cool.

With Node, you can cobble together pretty much everything I've described
(except for maybe pattern matching) above but it's a bit of a kluge IMO. You
can program functionally. And you can make yourself a kind of "compiler" via
linting or perhaps by using Flow or Typescript. I've yet to find the
experience fluid or pleasant. The language is just not designed for that
stuff. ES6 is a huge improvement that said. And before you go thinking I am a
node hater, I love JavaScript and use it all the time. I'm just painfully
aware of its shortcomings because of how much I work with it.

My biggest issue with Elixir is that it's hard to set up a proper
CI/Deployment pipeline. It CAN be done and I've done it but nothing "just
works" like it does with Node. Try dockerizing a phoenix app or setting up a
heroku instance to see what I mean. All of these things work but it's an
obscure language so one needs to be more advanced to understand and address
problems in that area.

To sum up: very excited about Elixir and hope it continues to grow. If I was
starting a new project I would probably use it.

~~~
thibaut_barrere
I'm working on both too, and one point that I faced was the Node 1.5GB RAM
limit per node process (at least on Heroku
[https://devcenter.heroku.com/articles/node-
concurrency](https://devcenter.heroku.com/articles/node-concurrency) \- I know
it can be worked around though, although not on Heroku), which can force you
to run multiple processes (aka clustering) depending on your use cases (e.g.
thousands of client websockets connections from the process, if you need to
listen to a large number of e.g. Slack connections).

This can lead to a more complicated architecture than with Elixir, where a
single Elixir process will be able to use more RAM & all the cores, too.

On the other hand, I love the dynamism of the Elixir ecosystem, but it's not
yet as rich as Node's one, and it's still harder to find a proficient Elixir
developer, than a Node one.

But personally yes: the fundations of Elixir are very, very strong, and I'm
investing in it completely (in addition to Ruby & Node, which I already use).

~~~
bhelx
Good points!

> where a single Elixir process will be able to use more RAM & all the cores,
> too.

I think you mean a "single instance of the BEAM" here as a single Elixir
process is pegged to 1 CPU core.

~~~
akeating
It's useful to think of the work of m Elixir processes being distributed to n
cpu cores by the BEAM scheduler. An Elixir process is not a system process in
the way we usually think of the word process if coming from a non-BEAM world.

