Hacker News Reader

Comment by qaq | Hacker News Reader

Elixir did make Beam/OTP more accessible and more "fun" :)

And not to diminish Jose's work, but a lot of it was a coat of paint -- read the Kernel module, where most of the language core is located, it's pretty much entirely macros. Most of the code in setting up the language, outside of the standard lib, was bootstrapping the macro processor. The better docs, build system, package manager, etc. were all just icing on the cake to make it a 21st century language, with Phoenix as the cherry on top.

I am in no way equating a 20 year effort by Erlang team to that of Elixir team. But I think Elixir is making the whole ecosystem much more accessible. I once tried to bring Erlang into our shop about 6-7 years ago but could not get the team excited about it, with Elixir we will be going into production this Fall and everyone loves it.

For sure, I wasn't trying to suggest you were. I guess the point I was trying to make without actually saying any of these words is that it's really interesting that the same ecosystem with a few extra things had that effect. I always liked the idea of Erlang and I've read Joe's thesis and stuff, but never could be bothered to learn the language because it felt niche, and same as your coworkers, we're all really excited about Elixir.

How much does your team get into actual Erlang/OTP code? I'm wondering since I'm taking the long route, learning Erlang/OTP first and a distinct second for Elixir. Is this not optimal?

I think that's optimal but for us it was more people getting into Elixir first and starting to dig in into Erlang/OTP. basically Programming Elixir -> Promgramming Phoenix -> Elixir in Action -> Designing for Scalability with Erlang/OTP

See also: Little Elixir and OTP Guidebook. Currently reading that book, it's good so far.

About to finish it myself, also very good! Elixir in Action's second part moved a bit too fast for me, but I'll revisit after I am done with Guidebook.

The thing that constantly gets me about Elixir and Phoenix is the default tends to be the correct way of doing it. Let me explain.

For example, the other day, I was looking at filtering a next parameter to remove the domain... however it's unnecessary as redirect/2 in phoenix if passed a URL rather than a path will throw an error by default. As an aside different exceptions will return different HTTP error codes - for example a database not found exception from Ecto will cause a 404. There are hundreds or thousands of these little decisions that are the correct/simpler decision.

Elixir and Phoenix, for want of a better way of saying it, show great programming taste. So to say it's a coat of paint is a bit harsh; it's the right coat of paint, in my opinion.

> Elixir and Phoenix, for want of a better way of saying it, show great programming taste. So to say it's a coat of paint is a bit harsh; it's the right coat of paint, in my opinion.

Fair enough. On rereading my comment, it came off more brash than I intended. I completely agree with this statement.

Fun is in the eye of the beholder. I'm worried that Elixir will take off because it's "hip" and ruin the chances for other people to use a pure and consistent language (Erlang) at work.

It is amazing what kind of middleware bloat is forced unto people these days.

hip is one thing, we primarily do web dev. so good unicode support & Phoenix are big selling points.

If you haven't read the code for how Elixir handles Unicode support [0] I highly recommend doing so. At compile time it reads from several Unicode Character Database text files [1] and then defines a whole slew of functions using the contents of the files that take advantage of pattern matching via unquoting. I already knew all about pattern matching before I came across this but I was still absolutely floored by how awesome this is. In the past when working with C I've needed to do something similar but it required running an external tool whose output was a .c file. It worked but it was hardly elegant.

[0]: https://github.com/elixir-lang/elixir/blob/master/lib/elixir...

[1]: http://www.unicode.org/Public/8.0.0/ucd/

Yep very elegant solution

One person's middleware bloat is another's power tool.

One could argue that Erlang/OTP has had decades to be used at work, and no one wanted to (sadly). Elixir taking over doesn't affect Erlang because Erlang wouldn't had become more popular over time anyway.

I personally am doing BEAM now mainly because of Elixir. It's undeniable that a "hip", and let's face it, young, crowd, having chosen Erlang/BEAM, gives it a big breath of fresh air (this is NOT to insult the experienced Erlang devs - it's just a fact that a new young crowd choosing your tech is an endorsement). Interestingly though, I'm more and more intrigued by the underlying technology. Personally I am not a fan of some of Elixir's design choices f.() versus f() for example, and maybe, just maybe, I'll do Erlang now.

Overall though, it was a total blast the other day to just run 10 000 processes so easily, within milliseconds, and watch all my cores go to max without messing with threads or even the (somewhat obtuse) Go channels. Actors really are easy to reason about. I like this model so much that I'm even looking at it for C (C++ Actor Framework).

I'd be interested to hear about your experience with the C++ Actor Framework. It seems like without the larger ecosystem of Erlang/BEAM for fault tolerance CAF is just a nice coroutine library.

Reply on news.ycombinator.com