Why the Elixir language has great potential | Hacker News Reader

Why the Elixir language has great potential

adrian-philipp.com

349 pointsjswny107 comments

I've been a long time Rubyist (10 years now) and I'm really enjoying Elixir. What got me hooked was the simple syntax and wonderful documentation, both from the project itself and in the Programming Elixir and Programming Phoenix books.

The ease of navigating an Elixir project is a huge benefit. If I want to know where a function is defined, it's very easy to find it. There's none of this class-reopening or meta programming malarkey that you get in Ruby (where is a Rails controller's render method defined exactly?)... it's all right there in the module.

Another thing that I love is that it's trivial to separate processing of several pieces of data into separate Elixir processes. To do something similar in Ruby, I would probably need to either use concurrent-ruby or spin them off into a background job with Sidekiq. In Elixir, it's baked right in.

Elixir is well-designed, the community is very friendly and it's just a pleasure to develop in.

Oh and Doctest is quite neat too!

> The ease of navigating an Elixir project is a huge benefit. If I want to know where a function is defined, it's very easy to find it. There's none of this class-reopening or meta programming malarkey that you get in Ruby (where is a Rails controller's render method defined exactly?)...

I would view Elixir as an improvement (iteration?) of Ruby built on Erlang. The article points out it was written by Jose Valim . It derives its structure from the documented shortcomings of both parent languages.

Other than some superficial syntax similarities, I find Elixir to be nothing like Ruby. Pattern matching, immutability, OTP, and the actor model feel like building blocks from a whole different universe.

Elixir does support Lisp-like macros for doing metaprogramming.

I think this is very important. GGP wrote about Elixir's simplicty, but it's important to note that this simplicty is at risk whenever macros are involved. That said, I personally haven't had any issues with overly complex macros, but YMMV and macros certainly do open the doors to immense complexity. I do appreciate how Elixir tries to make them harder to write than normal functions, as if to say "are you sure you want to risk making this unclear instead of doing this another way?"

Elixir docs specifically warn about this.

http://elixir-lang.org/getting-started/meta/macros.html

Check out the Foreword section.

I share the author's optimism. I work for a start-up, and we just released a mobile app that uses Elixir on the back end. I'm the architect on the project, and this was my first time using Elixir professionally. I've been blown away by the speed and stability of the product, the ease of hot deployments, and the intuitiveness of Elixir's syntax. Behaviors are amazing, and for the first time in my career, concurrency isn't a huge pain in the ass. The codebase is extremely easy to maintain and organize, and Elixir just takes baby sips at our cluster's resources. Elixir has far exceeded my expectations, and has provided me with one of the smoothest product launches of my 27-year career. I cannot speak highly enough about it.

Regarding learning Elixir, I thought LearnElixir.tv was great, but wasn't nearly as impressed by LearnPhoenix.tv. The latter is good, and definitely worth the money, but it didn't feel like it went into nearly the depth and breadth that LearnElixir.tv did. I also recommend the books "The Little Elixir & OTP Guidebook," by Benjamin Tan Wei Han, and "Programming Elixir," by Dave Thomas. Elixir School (http://elixirschool.com) is great online resource, and the Hex docs (https://hexdocs.pm) are clear and well organized. Finally, "Take Off with Elixir" (https://bigmachine.io/products/take-off-with-elixir/) is a great video/book offering.

Which package are you using for deployments?

Exrm.

Author of exrm rewrote it as Distillery and says that will be where all future development goes.

You are correct. We will be updating our deployments within the next few weeks.

I think Distillery is the current de-facto standard Elixir deploy tool.

You are correct. We just haven't had a chance to update yet.

Did you implement the entire backend in Elixir? Or did you have to use any NIFs?

All of our code is 100% Elixir. We are using various Hex packages, and it seems that one or two of those rely on NIFs, but I'd have to look.

It sounds like fun to use Elixir for the entire codebase. I played around with it briefly for fun. My favorite parts were pattern matching and |>. I never got to streams though.

Is the app public? (If you don't want to mention its homepage, I'll understand since it's your employer.)

We just received notification this morning that we can start running ads and pushing marketing. The app is only available in two areas right now, but we're working hard to bring it to everyone.

Here's the website for more information: http://goskip.com.

You should write a post about it with some more details. It will get more people hooked into it!!

That's an excellent suggestion!

We just released our software into two markets on the 1st of this month, and plan to release into markets nationwide beginning early 2017. I'm compelled to secrecy until then, but yes, I do plan on doing a thorough write-up of our product and our experiences with Elixir.

That's exciting! Good luck with the launch!

Thank you!

I'm having a lot of fun with it, can't wait for winter vacation to build stuff :)

There's a lot of niceties you get out of the box (mix is pretty nice and the testing framework is included, the REPL is good, love that they improve the error messages and consider an unclear error message a bug). I'm already used to pattern matching from Prolog so that's a great plus (I wanted to use Erlang initially but Elixir has won me over). I also feel like I'm thinking in a functional way much clearer (I'm using the PragProg book and this video tutorial https://bigmachine.io/products/take-off-with-elixir/ which both stress it, both resources highly recommended).

Once I start dipping into OTP I'm sure I won't be looking back anytime soon. It's been a while since I was this excited about a language.

Phoenix (web framework) is also pretty awesome. The abstraction of chaining a request through a bunch of functions to generate a response is very fitting. Plugs make sense.

tl;dr: Try it!

Another one that wasn't mentioned: optional types. Sometimes you don't need / want em, but it's good to have the option available for when you do.

Aside from that... Elixir feels really fun. Maybe it's a silly metric, but that's just my biased opinion.

The last feature that caught my attention was their deployment tools. I haven't used em yet, but based on a conference video I watched, it looks like they have pretty sweet setup. They claim to have very easy zero downtime upgrades / downgrades. And I think preparing a release automatically bundles dependencies, so everything is contained in a single compressed file.

> Aside from that... Elixir feels really fun. Maybe it's a silly metric, but that's just my biased opinion.

I'd argue that from a hacker's perspective, this is the most important metric. It's what keep you returning to the language, and what gives it vi(r|t)ality. Don't underestimate fun!

If you use Dialyzer you get compile time type checking of for most operators too. The lack of operator overloading means that it can identify and trace variable types based on the operators they are next to (variables next to a + sign must be a number, etc).

When I started learning I didn't understand why I had to use a different operator for string concat vs numerical addition and the Dialyzer talk from ElixirConf explained it very well.

Elixir as a new language doesn't have to reinvent a lot of things because of its ability to transparently call erlang (for instance, to use crypto I could just do :crypto.strong_rand_bytes(32) |> :base64.encode_to_string ). This is an awesome advantage to have.

Coming from the Clojure world, every time I read about about Elixir, the similarity of the two langauges' values always surprise me: immutability, macros, dynamic and gradual typing, concurrency, and on.

I've yet to touch Elixir (or Erlang, for that matter). Does anyone have experience using both? Thoughts? Has anyone crossed from one language to the other over any strong preference?

Yes, you are right, Elixir feels closer to Clojure than ruby in my opinion.

Still you need to understand the whole process and OTP deal.

I you enjoyed clojure you should check: http://lfe.io/

I spent a few weeks with Closure about a year ago. To be honest, Elixir is much more pleasant to work with. However, I might be biased as my main lang is Ruby...

You still have to bend your thinking, yet, you feel that you become productive much faster.

I have used both (though Clojure less). I have not built distributed applications in Elixir yet, so I do not focus on those features in this comment. I prefer Elixir because:

1. My brain thinks in terms of editing lines, not s-expressions; I didn't get the hang of paredit, and editing without paredit required really tedious edit operations.

2. Elixir's understanding of types matches Erlang's and the host VM, while Clojure invents its own uni-typed IObj but runs on a typed VM. Interop with Java required adding type annotations. Elixir/Erlang interop seems to be almost entirely pain-free.

3. Elixir has a lot of syntax niceties like triple-quoted strings that automatically remove indents. And pattern matching everywhere.

4. I can feasibly (and in fact, have) audited and built all of my Elixir and Erlang dependencies from git repositories, while doing the same with the Maven dependencies needed for a typical Java project would be almost impossible. I wouldn't even know where to begin with bootstrapping all the necessary Maven plugins.

5. Elixir/Erlang has per-process garbage collection and memory limits, though I haven't taken advantage of these yet.

> My brain thinks in terms of editing lines, not s-expressions; I didn't get the hang of paredit, and editing without paredit required really tedious edit operations.

In my experience, learning and then working in Common Lisp, starting with paredit is tough. I disabled paredit for a while until I got the hang of thinking in s-expressions as you say. After a while when I tried paredit again, it was glorious.

Early on I did set up % as a global key that goes to the matching parenthesis if on parenthesis, and otherwise inserts the character typed.

Also, I hope you were setting https://www.emacswiki.org/emacs/ShowParenMode

Just my 2¢.

I use Vim for editing Lisp. Basic :set lisp mode that dates back to ancient Unix implementations of vi and the % command for jumping between matching parentheses. In Vim, selecting a range and typing = re-indents it, and == indents the current line. I set shiftwidth to 2. When I need to move the indentation of a whole block I use select and < or >. Or << and >> for the current line. With those basics, I comfortably do 95% of all Lisp editing.

For instance to move an expression: put cursor on one parenthesis, type v for visual select, type % to jump to the other paren, then x to delete. Move somewhere, p to paste. Adjust formatting here and there, done.

I edit C and other languages in pretty much exactly the same way.

> Has anyone crossed from one language to the other...?

Yes, I've been doing Clojure for maybe four years, and picked up Elixir over the course of 2016. Frankly, I think I'll be preferring Elixir over Clojure for most tasks from now on.

The concurrency/parallelism story in Elixir/Erlang is just so much better than Clojure, or honestly anything else. (I'm talking about OTP and Supervisors here, but even the bare Process system is nicer than working with Clojure's CSP implementation)

Plus, because Erlang is also a functional language there isn't any Functional/OOP friction when interfacing with the native VM or with Erlang libraries. It's turtles all the way down, which I really appreciate after many times getting stuck in the mire of Java/OOP that lurks beneath the surface of Clojure.

Oh, and Phoenix blows any of the Clojure web systems out of water. It's awesome.

> Oh, and Phoenix blows any of the Clojure web systems out of water. It's awesome.

Are you referring to performance, or api design? In clojure there is almost no http apis by design, you're supposed to hook a library that follows the ring spec so it's not a nice comparison imho.

Right, and that's the bit I'm not keen on. You either end up with a totally bespoke stack of libraries for each project, importing the same boilerplate for basic things like csrf-protection, or you have Luminus vomit a bunch of code on disk and then you have to pick through the project and get rid of the stuff you don't want.

Then you realize that much of the code in the Luminus scaffold is managing state with mount (used to be with Component), and that's just a poor imitation of OTP from the Erlang world.

I dunno, I've been there, done that, and wasn't so fond of it. Phoenix, by contrast, strikes me as the right balance of lightness and pragmatism, with first-class support for managing stateful resources in a sane way (OTP mofos), and all the right defaults so I can be productive from day-zero on a new project.

[EDIT: to clarify, the Clojure way isn't _wrong_, and I do see the merit, but in my experience I prefer how things work out with Elixir and Erlang]

It's not a coincidence, Clojure was a big influence on Elixir... I think actually it's a bit of a funny parallel with Ruby, I know Matz has said the biggest influences on Ruby were Smalltalk, Lisp (or eLisp via Emacs) and Perl, and Elixir has a similar relation to Ruby, Clojure and Erlang (I think Jose has talked about this somewhere also).

I was very interested in Clojure and studied it for awhile. I liked it a lot, but had a difficult time becoming proficient with it. Part of it was the tooling (I tried learning Emacs and Clojure simultaneously when I should've only focused on Clojure), but my biggest hurdles were the syntax and understanding the error stack traces. They just seemed way too opaque. This really slowed down my progress. On the flip side, when I picked up Elixir, I became productive very quickly. Studying Clojure actually helped a lot here because I was familiar with functional programming and immutable data, but Elixir's familiar syntax and easier to understand error messages made it much easier for me to grok. I've since built a few things in Elixir and have been very happy with it.

Working with Elixir professionally for year and the half, having deployed more than one app on production I can honestly say, that it's just awesome. Not a silver bullet, will not solve your problems, but the way it makes you think is great. It's been the most impactful and satisfying learning experience of my short career.

Last time I went to look at elixir it looked nice, is there an accepted user-mangement system for phoenix yet? User auth is a combination of the three things I least want to implement myself:

1. Security. Small non-obvious mistakes are easy to make and very important.

2. High visibility. Risky, and if it goes wrong it's a major thing your customers notice.

3. Dry. It's just not particularly interesting for me, it's certainly solved in other frameworks (e.g. devise). I'm aware this last point is extremely selfish of me, however.

Guardian is the most used. You can use Canary for authorization.

I can attest that using Guardian is probably the best way to go so far with Phoenix. It worked great.

I use Coherence. It tries to be similar to Devise (of Rails fame).

Do you test your controllers? I'm trying to find some good documentation on how to do that but get warnings to use `build_conn` instead of `conn` when using the example here: https://github.com/smpallen99/coherence/wiki/Testing-with-Co...

If you're getting that in a test, my guess is that you're not passing a context argument with `conn` in it to your test function (e.g. `test "foo", %{conn: conn} do`.

There's a deprecated `conn/0` function that you'll accidentally call instead if you forget to do this.

`conn` is the old version, newer versions of Phoenix use `build_conn`. Just use that

I don't generate my own controllers when installing Coherence. I just use the ones that come "out of the box."

Because of the points you mentioned, I've been wondering why I haven't been able to find a framework-independent, open-source user management and authentication system. This seems like the sort of thing that should be solved in a standard way and not reinvented by every framework (or worse, application) that needs user management.

I've come across some paid services (e.g., stormpath, auth0) that seem to do what I'm talking about. It would be really nice if there were a free project along those lines though.

The API gateway approach has a lot of the upsides you mention:

1. http://microservices.io/patterns/apigateway.html 2. https://getkong.org/ (a few auth plugins) 3. https://github.com/auth0/nginx-jwt / https://www.stavros.io/posts/writing-an-nginx-authentication...

I have yet to use this for anything, so I can't vouch for it's quality, but it seems to be exactly what you are looking for.

http://www.keycloak.org/

Website blurb:

Add authentication to applications and secure services with minimum fuss. No need to deal with storing users or authenticating users. It's all available out of the box.

You'll even get advanced features such as User Federation, Identity Brokering and Social Login.

I don't think I understood your question, but this might be helpful for people having issues in similar keyword spaces: https://github.com/iNeedThis/phoenix-starter

I've just recently started learning Elixir and have really been enjoying it.

Subjectively speaking, I really like the terse yet expressive syntax. It's also nice to have a smaller codebase.

There's an awesome package that creates HTML docs out of your comments. It's really useful for creating documentation on the fly. Elixir's official docs are made this way.

I'm about halfway through a course I think is very good for beginner-level programmers (https://www.udemy.com/the-complete-elixir-and-phoenix-bootca...).

Elixir School is also a good resource.

Phoenix shows a lot of promise too, I haven't taken to JS so it would be good not to have to use it as much as possible.

I really rate https://elixirforum.com although for some reason Google never seems to find results on it even when there are lots of relevant examples.

I signed up for the digest there and it's one of the few "bulk" emails I get that I actually read.

thanks ill check it out!

Here is a repost of a comment I made a while ago about why I love Elixir:

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 (for security- you could redirect someone to fake login box on your host after they log in)... 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.

I am a self taught Ruby/Rails developer who has recently started dipping my toes in the world of Elixir and Phoenix.

I am having a lot of fun as I find it to be a refreshing approach to web development.

Elixir's guide is quite exhaustive. You can easily start building a toy app over a weekend.

I have open sourced the source code for my blog/web-shop that I built using Elixir/Phoenix. I am not an Elixir expert and this is not the best written Elixir app, but if anyone wants to look at the code for a simple CMS and shop built with Elixir and Phoenix, here is the link - https://github.com/authentic-pixels/ex-shop.

Here is a link to the live website - https://www.authenticpixels.com/

Read the blog post and then the thread, and was really starting to get excited at the prospect of using elixir. Then i wondered what was the pace of adopting new technologies in elixir, and found this thread about http2 support (which started to gain adoption last year, and increase peroformances a lot)

https://github.com/elixir-lang/plug/issues/258

So, for a language that's primarely based around webserver, i find it really woorying that http2 support wasn't a primary concern, and depends on donation to a third party developper...

I guess it means the language is still young and so is the ecosystem.

This isn't elixir fault per se.

Elixir leverages Cowboy quite a bit and HTTP2 requires substantial rewrite of Cowboy.

This will be completed in the release of Cowboy 2.0

If you want to read why Cowboy needs to be majorly refactored, read the link below

https://ninenines.eu/talks/cowboy-2/#/

Just anecdotal evidence but I've been running Elixir in production for half a year now for an app called Sleeperbot (95% of our backend is written in Elixir)

Our websocket endpoints, our app servers, and other services all run on Elixir, and pretty much without any incidents.

Erlang/OTP is battle-tested and it's really the first time I could comfortably sleep at night without worrying about stuff going down. Personally I think Elixir past the point of just having "potential" and is my default go-to language to solve any problem as long as it makes sense to solve it with Elixir.

Hey I don't personally use sleeperbot, but I play fantasy bball. "Is there a basketball equivalent of sleeperbot?" is a very common question, so I assume you're doing something right.

Just curious, what other languages/frameworks have you tried in backend? Are you running Phoenix?

Next season there will be. It'll actually be a full fantasy platform that hosts season-long leagues as well.

Has anyone used both Elixir and Go enough to give a comparison of the feel/productivity for backend web dev?

(I know it's apples to oranges... but for some tasks, like backend / high concurency microservices etc., both an apple and an orange are perfect fit, so it's worth comparing. I've heard of Ruby or Python people jumping to Go or Elixir, but not of any comparison.)

I'm actually in the process of writing a detailed blog post on that subject. Just trying to make sure I cover all of the bases.

Both are very similar in their underlying approaches. The biggest difference is that you have to write a lot more error handling code for Go.

The other thing is interfaces. With Go if you want to be able to pass multiple different types of structs to a function you have to define an interface that fits with both by showing each have a field named X of type Y. Because of that you end up needing to define a lot of interfaces.

Elixir accomplishes the same thing with pattern matching. You can define a function that shows parts of a nested hash in the argument and in order to call that function the hash you pass has to have those keys. It's much more flexible and less clunky IMO.

The other thing is Go's compiler strictness about making you remove any library from the import that not in use. When doing development or experimenting with a new library it gets really old having compiler yell at you about this because you commented something out. With Elixir, the compiler WARNS you about it. You still get a great big "get rid of all this stuff that isn't used" on compile, but it doesn't interrupt your development workflow.

Details like that, better package management, etc make me significantly more productive with Elixir. Phoenix is excellent and it's view layer is extremely fast and flexible - probably my favorite view layer that I've ever dealt with across many languages. Contrast that with Go templates, which to me felt a lot more like JSP.

I've used Go sparingly so please take this with a grain of salt.

I got productive quickly with Go and loved the simplicity and ease of development. The speed of compilation is amazing, and the programs run at a blazing speed. Then hit the wall and found myself repeating myself again and again. The lack of generics, pattern matching was really a deal breaker for me.

I chose Elixir for another API backend, and I really loved it. Hex, the package manager, Phoenix framework, the rock solid Erlang/BEAM and the Elixir language itself was a breeze from Go. Even though it compiles slower, and sometimes Hex package would fk up package hierarchy, the whole experience was great. The IDE support is bit flaky, and I used ST3.

I would highly recommend Elixir over Golang.

They are worlds apart from each other to compare. But if you can use Elixir for your project, you should, because you are going to be way more productive.

The big reason I won't use Elixir is there are similar and arguably better options on the JVM. The whole Server B column in the article can easily be replaced with JVM instead of Erlang.

For example you could use JRuby and Akka and probably have something comparable to Elixir (I haven't tried it as I prefer Java and Scala). And you could then use any Scala or Java library.

The only big issue I have with the JVM is that it is a memory hog and thus expensive. Consequently the most compelling thing about Elixir is that is on the erlang vm but I still prefer static typed languages. If Elixir were typed I might be more excited about it.

Don't get me wrong I love more options and we even use Erlang in my company but the JVM just has more flexibility.

I have written apps in both Scala Akka and Erlang / Elixir. You can't directly compare JRuby + Akka vs Elixir. The former is just an insane stack. Akka is plain ugly in Java and gets you nowhere near the simplicity of Elixir / Erlang. Elixir isn't emulating Ruby, the syntax is based on Ruby. That's it. I also do not find Akka as pleasant to work with as Erlang / Elixir.

Regarding the types on BEAM, there are types: maps, records, binaries, atoms, numbers, booleans... there's no classes but one does not need classes. Actors replace objects perfectly fine.

I agree that Akka is ugly (my company doesn't even use it) and I totally agree that you don't need classes (and you don't really have to in Scala and Clojure... even in Java you can just uses classes as though they were structs).

I only mention JRuby as many folks switching from Elixir are Ruby shops.

Personally I find the actor model too heavy (programming wise) for local concurrency and rather use some other message passing for distributed programming (zeromq, rabbitmq, kafka, etc). I know people hate damn queues and reactive programming but that is what I know (and I admit it is less efficient and more error prone than builtin green threads (go) or actors).

I realize now Elixir makes it damn easy because it is all in one package it is just a shame that there isn't some ML like language that compiles to Erlang bytecode.

> it is just a shame that there isn't some ML like language that compiles to Erlang bytecode.

There is! https://github.com/alpaca-lang/alpaca

It's very new, though. I wouldn't write production stuff in it just yet.

We're using Elixir for the back-end of our web application, and so far I'm very happy with it.

Probably the biggest issue we have with Elixir right now is libraries, but it's a more subtle problem than "there isn't a library that for this thing I want to do". To the contrary, I've been pleasantly surprised at how many libraries are available and how good they are.

The issue with libraries that I see is that because the language is so young and the core libraries are changing so rapidly (for the better!) a lot of useful third-party libraries have trouble keeping up. So we frequently find that a new feature has been rolled out to a core library that we really want to use, but upgrading it breaks a dependency in a third-party library.

It's sort of to be expected, right? The language has captured enough mindshare that people are building useful libraries left and right, but it hasn't gained quite enough adoption that there are armies of developers who can devote time to keeping those libraries updated to the minute - you don't have 100 developers behind a given library, you have 10 or 2 or 1.

Programming languages, being technologies, are subject to the Lindy effect (https://en.wikipedia.org/wiki/Lindy_effect). This means that the younger a language is, the lower its life expectancy. This is why the neomania in JavaScript framework land is so chaotic. Even if a better framework emerges and takes off in popularity over a few months, it's unlikely to last in the mainstream for another year. When I'm choosing something to study programming-wise, I use this heuristic as part of the decision-making process. For example, studying algorithms and data structures is more robust than studying Vue.js or GraphQL, which are not likely to be around in a few years.

Elixir was just released 5 years ago, and despite some success, has not taken off as much as the absolute top programming languages released around that time. For example, Go, released just 2 years earlier, is by far the most successful of new languages from the last 10 years.

Given my skeptical mindset towards neomania, it might surprise you to hear that I'm a huge proponent of Elixir! Here are my reasons for studying Elixir and using it exclusively for my non-work projects, despite there being countless other recent, appealing languages:

- Although the language is young, it's built on Erlang, which is 30 years old. Even if Elixir fails, there is a lot of knowledge transfer between the two languages (probably 90% of what I learn from using Elixir transfers directly over even if I switch to exclusively Erlang).

- Web applications are a fantastic use case for the Erlang VM (BEAM). Take a look at this article (https://joearms.github.io/2016/03/13/Managing-two-million-we...) by Joe Armstrong, one of the creators of Erlang, written earlier this year.

- Elixir is quite a bit different from other languages I'm familiar with. It's compiled and functional, has powerful pattern matching, uses lightweight processes and the actor model, and comes with OTP, a complete set of tools that I can use for free. This means even if/when the language dies, I've added a lot of new skills to my programming toolbelt.

To anyone that has decided, like I have, that Elixir is worth putting some time into learning, I'd like to recommend the book Elixir in Action (https://www.manning.com/books/elixir-in-action) and the blog of the author of that book, which has infrequent but outstanding posts (http://theerlangelist.com/).

> Programming languages, being technologies, are subject to the Lindy effect (https://en.wikipedia.org/wiki/Lindy_effect). This means that the younger a language is, the lower its life expectancy.

This is a really valuable point. My personal rule of thumb has been that every hardware or software technology takes 5 years to mature: it will useful long before then, but it take years for all the issues to be found and fixed and the ecosystem to fill out, so if you invest before the 5 years, expect less than perfection. Equally, if a technology does not seem to be maturing after 5 years in the field, it's probably not going to happen.

My personal long-term bet is Rust. It is an incredibly well-run project with a superb community, it has use cases that few other languages can fill, and I think that it has potential beyond it's currently defined position as a "systems language" (if you can write business applications in Swift, why not Rust?). Even if I'm wrong, it fills the criteria of being a programming language that is changing how I think about programming, so it will be a valuable experience.

> Erlang has this sort of huge cognitive overload with it's syntax, making it take longer to learn, for no obvious benefits.

Actually the adoption is quite good considering there is no industry giant backing it. There are plenty of companies using it in production and there is a job market for it.

Comparing the adoption with Go/Swift is a bit unfair.

Putting aside how the whole relationship with Ericsson allows to sell it to management.

The thing that I'm finding is that Elixir and Go have a direct correlation in many many areas. The biggest impediment to Elixirs adoption has been Go and specifically Google. The Google name helped tremendously with Go adoption.

What I'm finding is that every justifiable reason for using go outside of portable binaries...is that Elixir is the option I would have preferred or is simply a better fit. So much Go adoption came from concurrency needs of Ruby, Python and PHP Devs at a time when Elixir just wasn't ready yet.

The staying power of Elixir despite not being backed by Google or first to market here gives me great confidence. If nothing else, Elixir is educating a lot of people about what makes Erlang so good...and once you understand Erlang/BEAM you see everything that's missing everywhere else. Without learning it, you've got an ignorance is bliss situation.

Someone read Antifragile...

The biggest problem with Elixir imo are the horrible error messages.

Especially around using macros, but also other lexing errors like missing closing delimiters, ...

Line numbers are often non-existant or wrong, and the terminal output is hard to read.

Devs should take some inspiration from Rust. Wonderful error messages, and mostly accurate line numbers even in expanded macros.

Otherwise, Elixir is definitely interesting though.

Interesting, I've never come across a situation in which the line numbers in the error message were incorrect.

I'm also a huge fan, been using it for 6 months. 0.2s for my entire testsuite that touch the database are amazing.

Elixir is definitely interesting and one to keep an eye on. But I'd guess that for startups to use this, is still very risky especially at this stage. You may likely run into scenarios where you need some library/package and you can't find one for it and that could be a potential deal breaker for some startups.

I'm interested to hear though, can anyone care to comment on their experiences with Elixir's package ecosystem? How much developed is it and/or how much more to go to be suitable for most major projects?

Elixir's package ecosystem is quite good. The advantage Elixir has is that using an Erlang package in your Elixir codebase is very very easy and the same as using any other elixir package.

We are using Elixir for more than a year now at work and in almost all cases where we couldn't find a Elixir lib we found an Erlang one.

I think that the package ecosystem is well developed, and getting better every day. For the most common things, there's already packages out there. You want to talk to a database? Use Ecto. You want to check code quality? Use Credo. You want to respond using JSONAPI? Use ja_serializer. You want to talk over HTTP to something? Well there's two main options out there (HTTPotion and HTTPoison).

If you can't find a package then you could try looking it up at https://github.com/h4cc/awesome-elixir or asking on the elixir slack (https://elixir-slackin.herokuapp.com/) or on the #elixir-lang channel on Freenode.

After all that if you can't find a package that suits your needs then it's very easy to create one. "mix new (your project)" and away you go.

That's what I did with my elastic package (https://github.com/radar/elastic) when I couldn't quite find something that suited my exact needs. There's Elastix and Tirexs out there (those are the ones I know of) but neither really suited what I needed, so I just built my own.

I don't know how it could be a deal breaker if a package didn't exist already. I'd encourage you to build whatever you don't find already existing and contribute back to the community.

Man, there are things I like about Ecto but for anything beyond simple selects the documentation is lacking and the experience is kind of painful.

As an example, I hit the issue recently where a changeset wouldn't accept nil for a relation via put_assoc. That seemed like an very trivial problem to be hitting for a project that's been around so long. And I hit a number of issues that had that sort of feeling.

Another thing was that, if you update a thing with new relation data, you have to force-reload the relationships from the database again. That was pretty surprising and seemed like it should be unnecessary.

I think there's room for an Ecto alternative that tries to be a bit less fancy and gains a lot because of it.

Adding to the list: macros.

I've heard great things about it and currently have both of those books under my Christmas tree. One discussion I have had often recently is the split in the web community that appears to be emerging. Around (Less than in my opinion) half of the community seems to be going the way of full oo while the rest are going fp. Personally I feel fp is the right direction and will quickly become the new hot item

You'll find that Elixir/Erlang is a mix of FP and OO at the end, which is why I find it amazing. While people debate FP vs OO, it takes the good parts of both. You can read more about the OO aspects of Erlang from the author himself: http://tech.noredink.com/post/142689001488/the-most-object-o...

Thanks for the reply! That is a good point. I guess my original intent was strict oo (ex: typescript) that takes away the quazi FP properties js has. Very excited for elixer though

It's great to see another PHP/Js developer enthusiastic about Elixir. Usually it seems PHP devs pick Go as their next stack / interest.

The Ruby-inspired syntax have helped the language to gain traction amongst Rails developers but for somebody like me who only exposure to Ruby is Capistrano it doesn't do much.

I have not used Erlang or Elixir, and wanted to start with Elixir (I want some experience with a functional language, I'm to biased with Java to use Scala as a functional language). However, I read somewhere that Elixir can be successfully used only with Phoenix if you don't know Erlang. As I understood, sooner than later interactions with Erlang libraries is needed, and that requires Erlang knowledge. Can somebody please confirm? That Elixir is basically oriented around Phoenix and Erlang is a requirement?

I'm not sure who told you that, but it's patently false. Phoenix is just another OTP application, you can build a Phoenix app without knowing Erlang at all. It is a practical reality that you will eventually dig into Erlang to some degree, but I wouldn't say it's a requirement by any means. Perhaps what was meant is that you will need to understand OTP, the Erlang standard library (because Elixir avoids wrapping it as much as possible), and some of the semantics of Erlang interop such as the binaries vs charlists, the use of records instead of structs, etc. For just getting started though, much of that can be avoided, and you can tackle it as the need arises.

Thanks. I'm not sure where I read, it was probably some article or comment here on HN. That's what I wanted to hear, it is possible to attend to those issues on-the-fly.

Phoenix is really nice but you don't need it for web applications. The Plug library has everything you need if you want to roll your own.

I think the Erlang question is misleading perhaps, because using erlang functions in elixir doesn't actually involve/require learning erlang... any erlang function is available to call directly from Elixir, generally just namespaced under an atom, like :crypto.block_decrypt(:aes_cbc256, key, iv, cipehrtext) You don't have to "know erlang", just read some docs and make a slightly different syntax function call.

Start with elixir. The syntax is easy enough to learn. Once you get the hang of it learning erlang will be quite simple. You won't be a pro but you'll be able to look at a file and get the basic idea of what it does. Besides syntax they are very similar module-based languages.

I remember reading Phoenix had templating (eg HTML). Is Erlang/Elixir good for this? Or is it something better suited for NIF?

Phoenix uses IO lists for very efficient templating.

Read more here https://www.bignerdranch.com/blog/elixir-and-io-lists-part-1... and in part 2.

Thanks. This helps a lot even though I don't use Elixir or Erlang.

Elixir itself ships with a module called EEx that should feel very familiar if you've used Ruby's ERB. There's also a HAML rendering library (Calliope) among others.

Does Elixir even support step through debugging ? This is a necessity for a production language.

What is the relationship between Elixir and Erlang? I had thought Eixir was a framework?

Elixir is a programming language that compiles to Erlang bytecode and runs on the BEAM with no performance penalty.

How does it compares to Java and C in performance?

That's a loaded question because it's not built for performance, although it's still very fast. It's built for realtime and consistent performance specifically.

The trade off there is prescheduling, where the VM caps execution time of processes in the scheduler guaranteeing that a heavy process isn't allowed to take over the machine VS cooperative scheduling where the code has to periodically check in with the scheduler to relinquish control.

Prescheduling won't be faster in a benchmark, but if you have millions of small requests their response time will remain consistent in the face of bad actors or infinite loops trying to takeover the machine.

For math type benchmarks of the order of 2-10x slower http://benchmarksgame.alioth.debian.org/u64q/erlang.html

For this web framework test Phoenix (Elixir) does almost as well as Play (Java) https://github.com/mroth/phoenix-showdown

The benchmarksgame's site quotes "Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic."

So it depends I guess.

Thanks Tim, this is exactly what I was looking for. It seems to be no big draw to use elixir to web development compared to java and C.

Found the great site exercism.io from this article. Thanks to Adrian for posting about it !

Reply on news.ycombinator.com