Live data from Hacker News

Would you still pick Elixir in 2019?

github.com

161–170 of 246 posts

Re: Would you still pick Elixir in 2019?

#161

I've been working with Elixir in a single-developer production system for over a year now. I'm running it in Docker containers on Kubernetes, in the cloud. It has been extremely stable, scaling has been a non-issue. Error reporting has become easier and easier, now that companies like Sentry and AppSignal have integrations for Elixir. Elixir is VERY fault-tolerant. DB connection crashing? Ah well, reconnects immediat…

> Elixir is VERY fault-tolerant. DB connection crashing? Ah well, reconnects immediately, while still serving the static parts of the application. PDF generation wonky? Same thing. I still don't understand this. I don't think I've ever built a web server in any language where this wasn't true unless I specifically wanted hard failure. The amount of fault tolerance would be a per-app design goal rather than something…

You are correct. The difference is in term of idioms and how you design your software.

In most languages, you achieve this behaviour by rescuing/catching exceptions. In Erlang/Elixir, we don't like to that, because exceptions are mechanism to signal that something went wrong and telling the system to continue despite of failures is not a good practice.

Instead, in Erlang/Elixir, you organize your software using separate entities (called processes), which are completely isolated. Therefore, by definition, if something fails, it won't affect other parts of your system. This also leads to other features like supervision trees, which allows you to restart part of your application, exactly because you know all of those entities are isolated.

When you have shared mutable state, it is much harder to have something like built-in supervisors, because you have no guarantee that a crashed entity did not also corrupt the shared state.

In a nutshell, I would say Erlang/Elixir makes you think more about failures and how things go wrong.

I know this sounds a bit handwavy but it is not that trivial to explain those details on text. I have also given talks on this called Idioms for Building Fault-Tolerant and Distributed Applications in case you are interested: https://www.youtube.com/watch?v=B4rOG9Bc65Q

Re: Would you still pick Elixir in 2019?

#162
Our team has had great success with Elixir over the last year and ported core node services to it over the last few months. We are very happy with the results. There are some things we haven't been able to do with it, like intensive data processing (for which Python is still used), but if those libraries existed we would switch our Python services ASAP and be an entirely elixir backend.

Re: Would you still pick Elixir in 2019?

#163

Earlier quoted context omitted.

> If you need multi core and distributed features (which is generally more common than you think) elixir is truly your friend. Is it though? At least in my line of work I don't think I've ever run into this. I feel like I've always been able to distribute just fine with workers/queues. If I even suspected it would I'd look into it more, but generally I find distributing across systems to be a software architecture-le…

Because those features are accessible, you end-up using them a lot more frequently and find new and exciting ways to use them. For example, I am really happy that Elixir and its tooling does pretty much everything using all cores: compiling code, running tests, generating documentation, etc. and all of this has a direct impact on the developer experience. The other part is that you can build more efficient systems by…

Cool, thanks José, that helps indeed. The multi-core DX stuff sounds interesting even on its own, production code aside. I hope to check it out soon!

Re: Would you still pick Elixir in 2019?

#164

Elixir has great things "of his own": * the syntax is well though-of (`with`, destructuring, `|>` are powerful * message passing has great use-cases And then it has problems that are not necessarily "elixir-y", but are there nonetheless: * it's hard to model an application around the Actor model. It's very easy to abuse it. * it's hard to maintain / refactor a large application without help from the compiler before r…

The fact that it's dynamically typed is also often overlooked, while it's at the top of my deal breaker list. The programming world is strongly moving toward statically typed languages, because today, there's pretty much zero reasons to use a dynamically typed language.

I agree and believe that it's harder to maintain a dynamically-typed codebase, but Elixir has a well-thought-out gradual typing solution: typespecs ( https://hexdocs.pm/elixir/typespecs.html#basic-types ). This builds on Erlang's Dialyzer tool and is supported by editor plugins like VSCode's ElixirLS extension. In practice, you do get instant typechecking while you code, if you write down the typespecs properly.

Re: Would you still pick Elixir in 2019?

#165

Earlier quoted context omitted.

I have experience with both. I have recently been working with Elixir. It's okay. I find the lack of static typing to be some thing I celebrate and curse. Elixir is VERY simple and beam is VERY slow at computation. I wouldn't recommend anyone working with scala/akka look at elixir unless you want to understand how BEAM works but I would recommend _everyone_ working with elixir learn different functional programming l…

Also, I have to say that elixir developers are generally not very experienced with it and seem to be generally less desirable than the people who are working with scala. You get rubyists that have some interest in working with elixir because there were some blog posts saying it's the new hotness. Scala seems to attract more comp-sci savvy people. And generally those people will refuse to work with elixir when there a…

> Also, I have to say that elixir developers are generally not very experienced with it and seem to be generally less desirable than the people who are working with scala.

Scala has been around for 14 years and is built on top of a much more used VM compared to Elixir. Given Scala's growth, it is expected that Scala developers are more experienced as they have been around for longer. Scala also had more time to spread to comp-sci fields, especially as it is taught by many universities. All thanks to Scala's merits, of course!

So while I agree that experience is a factor, I wouldn't draw conclusions that those are intrinsic to Elixir or to its users. I also have heard of companies that had no trouble to hire Elixir developers (some have 80 Elixir devs and growing) and some that had many difficulties. As with any other technology, YMMV.

Re: Would you still pick Elixir in 2019?

#166

Isn't Elixir the most efficient thing available?

Elixir is pretty fast, but far from the fastest or efficient. IMO if all you need is CRUD server that operates efficiently then elixir is probably the wrong choice unless you already know it. It does have some nice features within distribution and real-time stuff, but if you don't need that and don't know erlang or elixir I wouldn't use it.

Re: Would you still pick Elixir in 2019?

#167

Earlier quoted context omitted.

I would say it's about developer happiness while coding and that all the decisions made by Jose and the core team tend to have been the correct decision. So taking Phoenix as an example you look at the framework and every time they find a problem i.e. Presence instead of saying that's a difficult problem and moving on they fix said problem in a really scalable way [1]. The same could be said for things like data proc…

Actually Ecto is the most unhappy part of the Elixir ecosystem to me. It's unnecessarily complicated for almost any software project. I'd even take Django's ORM instead of it, but what I want is something close to ActiveRecord. There are some Elixir modules similar to AR, none popular.

It is tragically funny how many people like and how many people dislike Ecto. :) I guess that's "ORM"s in a nutshell? Which is totally fine, of course!

Re: Would you still pick Elixir in 2019?

#168

can people give real world business use cases for where they are using elixir? What industries are you working in? what actually gets done in the real world at the end of the day with the system you're working on? e.g. are more ads served to web users? are you monitoring methane on IOT things strapped to cows in farm fields?

www.lovethework.com run on elixir. Data transfer and transformation from an old system, web frontend (we are refactoring a lot of the current javascript stuff recently), ecommerce, the admin stuff on the back office too.

Mostly good old web stuff.

Re: Would you still pick Elixir in 2019?

#169

Elixir is a niche (that's the truth). Also in the article it is written 'Relatively difficult to "recruit" developers with existing experience in Elixir'. Why would a SW company invest in niche languages where the resources (software developers) are really expensive and really hard to get? Technologically it's all great but economically that's a nightmare.

I don't think it is that black and white. I have heard from some companies adopting Elixir that hiring became easier because the demand for their previous technology was really high and they could differentiate themselves with Elixir.

There are also companies that we really successful in hiring by reaching out to functional communities in general. And of course, there are also companies struggling to hire Elixir developers compared to other techs. YMMV.

Re: Would you still pick Elixir in 2019?

#170

can people give real world business use cases for where they are using elixir? What industries are you working in? what actually gets done in the real world at the end of the day with the system you're working on? e.g. are more ads served to web users? are you monitoring methane on IOT things strapped to cows in farm fields?

- chat / IMs backends

- multimedia streaming

- multiplayer game servers

Generally soft real-time systems

Post reply on HN