Hacker News Reader

Comment by jmcgough | Hacker News Reader

Elixir really isn't just Ruby with better performance. The two look syntactically similar (and have some similar tooling, from rubyists who've moved over to elixir), but that's about where their similarities end.

Ruby really isn't designed for building complex concurrent systems. Erlang/OTP is designed specifically for that.

When I need to build something that recovers from failures in Rails, it means code that is littered with try/catch statements. I recently wrote a basic caching system in Elixir for a project at work. There are plenty of ways for it to fail, and I handle none of those situations. I let it crash, bring it down gracefully, and then bring it back up in a healthy state. You can write truly fault-tolerant programs on top of a very powerful and stable VM.

View on HN

As someone working across JVM, .NET, C++, Android and iOS, I don't have any use case for Elixir.

If I ever would need BEAM, Erlang would be quite ok, given that I was quite comfortable with Prolog in the past and do like the syntax.

Hence why I kind of see it as BEAM for Ruby developers, even if I am way off what is actually happening on the BEAM world.

100% This.

The use cases for OTP are actually quite narrow, despite what Erlang/Elixir evangelists tell you.

Discord is a fantastic use for OTP. Writing a CRUD app with a couple of reactive/interactive pages for comments on videos and few thousand users, OTP is overkill.

If you have an app that needs the scale and safety of OTP, then which language you pick makes no difference.

Phoenix is a really cool project, written by great developers and the community is probably the nicest and most helpful you will ever meet. But how many companies/projects need the performance and redundancy of Phoenix/OTP in their web application at the cost of not being able to hire developers?

Elixir is very easy to learn. I suppose at the end of day you would be spending more time designing your architecture rather then language.

I disagree that Elixir is easy to learn, the syntax ok, it's weird compared to most OO languages, but actually using OTP is a real paradigm shift that requires a totally different way of thinking about issues. I did not find that easy at all.

The other issue is that Elixir and Phoenix have become joined at the hip in the same was as Ruby and Rails, and Phoenix didn't click with me at all, coming from the JVM world I really didn't get on with it.

After reading Programming Elixir, Elixir in Action and Programming Phoenix I decided that it wasn't an easy way to make web applications that don't need OTP, and in fact I couldn't imagine a scenario where any web application I would ever write would need OTP (for the whole thing anyway, I can imagine cases where small parts of a larger system could benefit massively from fail fast architecture)

Edit: I would also argue that designing an OTP based system architecture is harder than just writing a non distributed system and then adding in load balancing or fail over.

I don't think it's easy to learn either. The basics are easy, and the syntax is easy, and writing some code that does what you want in the repl is easy. But then you try to make a real application and you have more questions than answers.

But, you can do OTP without making it distributed. Elixir is awesome in that you have this actor based system (genserver) where the syntax gets out of the way more than in any other language i'm familar with. So the business logic running on these genservers is really easy to understand. And there is nothing stopping you putting them behind message queues or load balancers. Most of the time, that's probably appropriate.

Your web server, database connections, http clients would be the ones leveraging OTP here. In my talks, I usually cover the design of the connection pool and how it guarantees bugs in the pool bring all connections down with it, without leaking resources.

Ideally, developers should be able to use Phoenix for simple applications without caring about the low-level OTP details. That's how we tried to structure the Phoenix book: the classic MVC and then the OTP stuff. But it seems we still have more work to do in this area. :)

The great thing with Elixir in your toolbox is that you're prepared to write the quick mostly-static app or the full multi-server connection-processing behemoth.

I just type "mix phoenix.new <project name>" and I have a relatively light starter framework that's ready to go as far as I need to take it.

Rails had the same "ready to go" feel as Phoenix, but I learned from painful personal experience that you hit the scaling wall way too quickly - but with that project I never realized that scaling would ever be a problem. How was I supposed to know which sized framework/language to use from the beginning.

So sure, the use cases where OTP will really shine for you are potentially narrow. But Elixir is actually quite fun to work with even for small projects and it's fantastic knowing that if a project grows unexpectedly, I don't have to scrap it and write it in something else.

I would argue there are more developers interested in Elixir than there are jobs available. I would also argue that any developer worth paying, is a developer than can get up & running with a new syntax in a short period of time.

Indeed, I work in many languages with many frameworks, and if my CTO decided that we were going to use Elixir then I would happily start using it.

For me personally though, I can't see any advantages of using it over a JVM stack.

what about costs of running the application? You're not taking that into account.. I can run my elixir app far cheaper than you can a ruby app for instance. This means I can charge less than my competitors and offer more to my customers.

Sure I am, for a personal project, of which I have a couple, a $5 per month Digital Ocean droplet can run pretty much anything I will ever write.

Professionally my company uses AWS, and I will concede that you might make a small saving using a few less EC2 instances.

Edit: This is on a JVM (Tomcat) stack by the way, not Ruby.

> The use cases for OTP are actually quite narrow, despite what Erlang/Elixir evangelists tell you.

I like to describe Elixir should suit well anything that runs on top of a TCP socket. A binary protocol, an HTML app, a JSON API or even a distributed system. Embedded systems is coming up as a new area of interest as well.

I wouldn't say those cases are narrow. But I believe you meant the use cases are narrow if you are already using other platforms. Then indeed we have many things to consider beyond the technical aspects.

But I also would like to argue that scale and safety are not the only reasons to try Elixir and OTP. I personally find functional code easier to maintain, especially because of immutability. The performance aspects really shows up during development and testing as well. I wrote a bit about the latter here: http://blog.plataformatec.com.br/2017/07/the-fallacies-of-we...

If you're doing anything at all server side, you have a use case for Elixir.

Already covered by the JVM and .NET on my toolbox.

Sure. So why does any other language need to exist?

Technically, this stuff is all covered by any preceding language in the toolbox. We could all just use C...or Perl?

Why bother to learn the JVM languages when C already had it covered?

Simple...because you can do it better.

Languages get used because they cover specific use cases or libraries.

UNIX -> C

Browser -> JavaScript

Data Science -> Python, R, Julia, Chapel, C++

Windows Development -> .NET languages, C and C++

Android -> Java, Kotlin, C and C++

macOS, iOS, tvOS, watchOS -> Objective-C, Swift, C and C++

Docker, Kubernetes -> Go

Game development -> Assembly, C, C++ and C#

High performance data switches -> Erlang

Of course one is free to use outlier languages and try to bend them into specific use cases, but then one also has to live with less tooling as the ones that are the "platform language" for the specific use case.

Throughout my career I always kept an open mind to try out new programming languages and paradigms, but in what concerns production code I learned the hard way to only use the official platform languages.

Reply on news.ycombinator.com