Hacker News new | past | comments | ask | show | jobs | submit login
Flirting with Elixir (localytics.com)
81 points by ptothek2 on Oct 15, 2015 | hide | past | favorite | 26 comments



I've been "obsessed" with Elixir lately, and it truly is a breath of fresh air in the current programming language landscape.

I've started with C, built a career with backend Python services/dashboards, and spent some time on the "fringe" learning about Lisp, Scheme, Haskell, Clojure. And once you rewire your brain with functional programming constructs or immutability, it is really hard to go back to Python, using large libraries feels too much like magic (if you ever used Django, raise your hands if you've ever had to delve into the source code to understand what is going on).

I've had a fling with Go, I really like some of its ideas, namely static linking, native compilation, no exceptions, easy deploy (I wrote a huge Django 1.6 app shipped as RPM for RHEL 5 enterprise servers, and that was truly the definition of pain). I disliked the lack of functional constructs such as map, reduce, filter, and it felt a step back from the "fringe" languages I've been studying.

Then I discovered Elixir.

It's a mix between Haskell without purity and types and Clojure without parens, with a Ruby-style syntax and a battle-tested framework for concurrency and distributed computing.

It's like an immutable Python. With built-in virtualenv + pip tooling. And first-class macros. And pattern matching.

Pair that with a sane standard library (unit testing? logging? documentation? We've got you covered), a REPL, a LINQ-style lightweight ORM, and a very interesting web framework built around modern tech (websockets, JSON APIs, ES6).

And binary compatible with the most robust concurrency and supervision system, Erlang/OTP.

I know I talk like a fanboy, but, man, programming feels like joy again.


I agree. Whenever I open up an Elixir project, there's a certain joy. I'm not sure what it is exactly. The language is simply a pleasure to work in.

> I've had a fling with Go

I've used Go for quite a few things, but it never felt quite right. I've come to like some of the tooling around the language while hating the language itself.

What really turned me away from Go was its community. There are a lot of people who think that they're smarter than everybody else for using a "systems language". Disagreement with the status quo is often fought back with religious indignation. Any decisions made by the language designers are obviously right, and you just need to accept that and do what you're told. I've found a lot of sexism and vitriol too. I've heard similar stories from others, but we could just be unlucky.

Elixir on the other hand has made it a goal to have a nice and welcoming community. That might change as it gains steam, but because of the leadership shown by community leaders, I doubt it will.


FWIW, that's sort of the reason the community code of conduct was introduced (which many of the folks you complain about pushed against). I don't know how effective it is as I tend to avoid "community" groups for programming languages, but the major parties all claim to have adopted it.

http://coc.golangbridge.org/


It certainly feels like a breath of fresh air. When you work with it and you hear some of the hype around it, you get the distinct maybe unsubstantiated feeling that it is a language which could really take off. Thinking Ruby/Rails circa 2005.


Exactly. I've recently posted a link to a talk about Phoenix (the de factor Elixir web framework), where the creator is talking about working on an integrated GraphQL server and (possibly) server side templates using GraphQL directly.

I personally feel this would be a game changer, much like when Rails started shipping and it completely changed the way we write web applications.


I too am obsessed with Elixir and LFE, being a Lisper. I am currently learning both to see, if I will choose one, or just learn and use both. This dialogue between Jose Valim (creator of Elixir) and Robert Virding (originally worked on the Erlang team, and creator of LFE) has some interesting contrastting points [1]. Summary: Elixir cannot define new syntax in the true Lisp sense, while LFE can. Elixir has improved the interface to the Erlang libraries, while LFE uses them "straight" from Erlang. I think Elixir has more momentum due to the resurgence of interest in the BEAM, and the Ruby-like syntax and Ruby's and ROR's already-large community. I've never chose a language for popularity, hence why I still use Lisp. I do like Elixir and LFE a lot. Choices...

[1] - https://groups.google.com/forum/#!topic/lisp-flavoured-erlan...


Haskell without purity and types

I'm getting quite tired of this "Every functional language I can't precisely describe is like Haskell" sentiment. It's the "tastes like chicken" of programming languages. Then again, the original article is remarkably devoid of content, so I suppose it's only fitting.

Interestingly, avoidance of excessive magic is a large reason why I stick to vanilla Erlang.


I agree that the comparison with Haskell is ill fitting.

The sentiment I wanted to express is that Elixir, like Haskell, is built around function (or module) composition, is immutable, and state is idiomatically handled separately (with separate processes and message passing, instead of monads).


Fallacy of composition. You're saying that any language with HOFs, immutability and "idiomatic way to contain state" is ergo Haskell-like, which is insane. None of these are even properties of Elixir, but of Erlang, which Elixir inherits. Erlang is self-evidently not Haskell-like. At best such a language would be merely functional. The actor model isn't even about anything analogous to monads, it's a concurrency model that happens to simplify concurrency control through isolation.


> insane

Rather than sling around heavy duty words like "insanity", you might try putting yourself in their shoes: perhaps their only exposure to a functional language is Haskell. Elixir is going to look a lot more like that, than, say, C++.


Irrelevant. Ignorance does not make inapt comparisons retroactively correct.


In technical terms, you are of course correct, and it's helpful to point that out where people are wrong. But being wrong is not "insane" - that's incorrect in and of itself :-)


Separate process are monads! They just might not call them that. ;)


I stick to vanilla Erlang.

Erlang + optional type annotations + optional dialyzer verification is perfection.


> if you ever used Django, raise your hands if you've ever had to delve into the source code to understand what is going on

This is a sentiment I don't understand at all. Why wouldn't you delve into the source code of tools you use? I do this with almost all the tools I use, be it languages or libraries (obviously I don't use non-opensource ones if I can avoid it). Looking inside libraries teaches you quite a lot and isn't even that difficult, especially if your editor+language combination support "Jump to Definition".

I think we'd be much better off, as an industry, if people learned to appreciate code reading. This would make writing readable code more desirable in the first place, which would be really great.

And BTW, Django has a really good looking codebase. You shouldn't start your reading with SQL compiler in the ORM, but, for example, class-based and generic views are a nice starting point. Another related codebase I can recommend is Django Rest Framework - really a must read for pythonistas who use Django.

> using large libraries feels too much like magic

That's actually my biggest gripe with Elixir. The fact that it happens on compile time (using) and not at runtime doesn't make its magic less magical. And it's very often not documented appropriately. The docs or examples tell you to `use` a module and that's it - you don't know what symbols are imported, let alone what the module macros will do with your code. And it's hard to tell by just looking at the module in question, because - macros. I can deal with it, but in general Elixir should either document its macros better or make things much more explicit.

> I've had a fling with Go, I really like some of its ideas, namely static linking, native compilation, no exceptions, easy deploy

Take a look at OCaml. All the features you mention and a non-brain dead type system on top of that. Multicore is a problem, but I hear it's improving fast.

> It's a mix between Haskell without purity and types and Clojure without parens, with a Ruby-style syntax and a battle-tested framework for concurrency and distributed computing.

That's probably the least flattering description of Elixir I've ever read. Haskell without purity and types would be utterly broken and useless. Similarly for Clojure and sexps. Elixir is neither - it is a nice langauge in its own right.

> I know I talk like a fanboy [...]

Well, I like Elixir too, there's nothing wrong with it. Really, Elixir has many nice features and a great potential; it's still growing, I think, and needs a bit more time to really mature, but is a viable choice for some projects already.


I've been using Erlang on and off since 2003, and used it heavily at the last place I worked to build a pretty cool product, so I'm a fan. That said, this article is a little bit hypey, although it's all correct as far as I can see.

* I'd still build most products in Rails, because there is so much ecosystem that lets you get something up and running quickly. The exception being if I absolutely knew that the system had to aim for really big numbers from the get-go (which is not the kind of market I'm particularly even interested in these days), or had to be super-reliable, or some kind of semi-embedded system like what I did in the last place I worked. I loved Joe Armstrong's answer here: http://erlang.org/pipermail/erlang-questions/2015-October/08... - "My goal would be to get something up and running as soon as possible and get users - and not worry about implementation details."

* By the same token, if you know you need something with raw computing speed, Erlang isn't it either, as the article mentions. Although it'd certainly be possible for Erlang to farm out work to something faster, if the additional architectural complexity isn't a problem.


(SRE at Localytics here.)

I think one of the biggest things for us is that, primarily, we run Rails on the frontend and Scala on the backend. Elixir is exciting because we could potentially replace a lot of our frontend stuff with it, while not being terribly far from Ruby syntax. It's "approachable". On the flipside, it's potentially taking our Ruby code and making it more functional, getting closer to our Scala side of things. It's a very nice middle ground.

In that regard, a lot of us here do feel very excited about Elixir, and so I think that comes through as a lot of hype. We're looking at it through the lens of what it could do for us, and we're naturally excited about that. :)


I can highly recommend David Thomas' book Programming Elixir, I found it complete to get a good grip and also a great introduction into functional programming overall

https://pragprog.com/book/elixir/programming-elixir


Just got the confirmation that Programming Elixir and Metaprogramming Elixir shipped. They can't get here fast enough.


I love Elixir. I come from a Ruby background, and while I prefer Elixir now, learning it has made all my code better.

LearnElixir.tv is another great place to learn it, if video screencasts are your thing.

https://www.learnelixir.tv/


My good friend's company is hiring engineer(s) with Elixir knowledge if anyone is interested. https://discordapp.com/company#join


Are macros useful in a web development context? I don't feel like I've been missing them in Django, but maybe I've just forgotten because it's been a long time since I wrote anything substantial in Scheme. (Are Elixir macros similar to Scheme macros?)


Macros are the most powerful tool for making DSLs, which means they pop up in a lot of "specialized" niches, like web dev. You can make DSLs in other ways, but without the ability to inspect and decompose code at the per-token level, there are limitations to what can be done.

Elixir macros are like Scheme macros; they're fully hygienic (no variable namespace issues), and they evaluate at compile time. The main difference is that Scheme's main syntax construction is the linked list, and Elixir uses a richer data structure, almost equivalent to JSON. Aside from the particular structure the macro's manipulating, the concepts are the same.

Elixir macros are also used idiomatically to allow "smart" loading of modules, e.g. specifying additional code to run in the caller's context rather than the callee's. They fit nicely for this purpose.


Elixir is great, and I would loosely say it not homoiconic as Robert Virding, one of the original Erlang team and creator of LFE (Lisp Flavored Erlang), posits in an exchange with Jose Valim, creator of Elixir here[1]. In terms of qualifying a JSON-equivalent data structure as richer, compared to lists in Scheme or Lisp, I would disagree. I think you lose the code-as-data (down to the languages fundamentals) win in Scheme. Devin Torres makes the statement that Elixir is 'strongly homoiconic' [2], but his reference's definition does not fit Elixir [3]. You cannot add new constructs or operators in Elixir. I would say 'weakly homoiconic' if you are going to prefix an adverb on a page that invents terms, which I still think is like 'a little bit pregnant' - not logically consistent. I do not code for a living, so I can choose things on an interest basis, not a popularity or job market index. I am learning both Elixir and LFE, and Erlang by default, but I am gravitating towards LFE. I think LFE on the BEAM and Clojure on the JVM, makes for a good argument for me to stay in the Lisp world, and not the Ruby, ROR, or Elixir one.

[1] https://groups.google.com/forum/#!topic/lisp-flavoured-erlan...

[2] http://devintorr.es/blog/2013/06/11/elixir-its-not-about-syn...

[3] http://c2.com/cgi/wiki?HomoiconicLanguages


Thanks for the reply! I read the "[1]" link you posted, and the word "homoiconic" doesn't appear anywhere. Elixir code and data share the same native data structures, ergo Elixir is homoiconic. Virding's point is that Elixir lacks reader macros. For real-world usage, I consider that more of a strength than a weakness. :)


Thanks for this interesting answer! I read most of the getting started guide last night and I'll probably try Elixir for a toy project sometime soon :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: