[Southy]

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?

[crusso]

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.

[josevalim]

> 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...

[hesarenu]

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.

[Southy]

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.

[anko]

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.

[josevalim]

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. :)

[mattferderer]

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.

[Southy]

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.

[tmat]

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.

[Southy]

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.