Elixir vs. Java, Ruby, and PHP - Seeking case studies or an interview with a community member

There’s a quite recent story about migrating from PHP to Elixir which might interest you: http://engineering.teacherspayteachers.com/2017/06/05/challenges-faced-while-scaling-to-serve-millions-of-views-per-day.html

Hi @restack_oslo

I will explain some things i learnt from Elixir. This is what i know i what i know can be wrong.

To answer your question first i need to remind you Elixir will compile to Erlang VM (AKA BEAM) Bytecode, So we can say it’s same as Erlang in runtime.

Upsides

• First of all Erlang is super robust. I heard there are telecom switches running Erlang non stop for 20+ years. Thats interesting.

• Elixir/Erlang use immutable data structure, means it’s less likely going to suffer from concurrency issues. these issues can happen a lot on Object Oriented languages like Java.

• Elixir/Erlang is easily scalable. A client-server architecture in Elixir (like GenServer) is very helpful to convert a monolith application to a micro-service like application without needs for creating an API interface since Erlang can talk between machines easily using Node module.

• Elixir has a friendly community and maintainers, I really value this.

• In Elixir/Erlang your process (BEAM process) will not get terminated easily. There is no StackOverflow exception. However memory outage can crash whole VM.

• Most Elixir libraries are well documented. The code-style encourages programmers to write good docs about every public function by providing nice Tools like ex_docs

• Deployment of elixir code to server if fun and safe. Specially the Hot Code Upgrade lets you upgrade you application with zero downtime.

• For web development i’ve never seen something like plug. plug is awesome.

• Erlang/Elixir can handle high loads of traffic like a boss.
  Visit here to learn more: 2 Million Websocket Connections in Phoenix
  Whatsapp uses Erlang as their main language. I’ve read in their blog that they handled over 2,300,000 connections to a single box. Whats app 2 million connections

Downsides

• Elixir is a new language and can change a lot in many aspects. So you need to be more active and up-to-date.

• Erlang/Elixir is not a good candidate for applications which rely heavily on calculations. (But you can use a combination of C/C++ or Rust with Elixir if you need calculations. more info here: github.com/hansihe/Rustler)

• There are not lot’s of Erlang/Elixir developers. Currently they are not easy to find. It may cause some expenses to your company.

• Some Erlang native libraries are hard to understand and Erlang documents are a bit wired in my opinion.

Im sorry about my poor english.

Elixir and Erlang are built with distributed systems and concurrency in mind - for scalability and availability (fault tolerance) few languages come close. Do you need more reasons than this? Elixir offers us a ‘modern’ language for the Erlang Virtual Machine - many say that Elixir is the language that the Erlang Virtual Machine deserves (thanks to it’s ‘nicer’ syntax, tools, frameworks etc).

Personally I think something that is often overlooked by managers is that developers who use languages like Elixir often fall in love with them. This promotes a culture of learning and something I believe leads to significantly better developers …they learn as much as they can because they want to, not because they have to (JS/browsers) or because they are told to (Java/enterprise).

People usually excel at what they enjoy - do you want a team who is passionate not just about your startup but about the technology it uses? Or a team who are not all that inspired by the work because it’s with a language they don’t really like? I know what I’d choose

The problem with this approach is that it is about as useful a numeric score on meta-critic - there are just too many nuances to be captured in a matrix to translate to any particular real world scenario.

One thing that sticks out about the Elixir community is that it is quite up front that Elixir isn’t the best solution for everything - and that it really doesn’t matter because Elixir/Erlang typically interoperates with various other technologies quite well - Erlang can interoperate with C/C++ and Java code (JInterface) - more direct interoperation with Python seems to be in the works and ultimately you can build the entire system around something like RabbitMQ (which itself is implemented in Erlang) which supports a large number of other development environments.

Technically the biggest “drawback” is that Elixir development is for the time being largely coupled to PostgreSQL - so access to existing legacy information from persistent storage (e.g. Oracle) can require additional effort.

Java and PHP have the edge for non-technical reasons. Both are being frequently taught in post-secondary institutions - so “resources” are typically in good (and relatively cheap) supply. Getting people to work quickly was a primary design consideration behind Go:

It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical.

The resource situation with respect to Elixir/Erlang is different:

Smaller Community: Erlang developers not as prevalent but “the ones you do find tend to be really good”

The sentiment seems to duplicate observations within the Clojure community.

Hiring managers tell us Clojure is their “secret weapon. It self-selects for smart developers”.

… Clojure lets you do much more with significantly less.

Projects with Elixir/Erlang teams tend to report the same kind of dynamic.

In many ways Ruby/Rails seems to be a cleaner alternative to PHP - as long as the project fits well into the constraints of Rails conventions - i.e. a CRUD web application is sufficient to get the job done (now and in the future).

See also: Elixir from JAVA guy perspective

Ecto by default works with PostgreSQL and MySQL/MariaDB, but you don’t have to use Ecto (and I don’t in a lot of access), so the additional effort is minimal anyway, Ecto is just a library you can leave out after all.

And slower!
But really, I ran tests between ruby and php (and rust and others) recently and PHP blew Ruby away in speed, not even a close factor (still not close to Elixir though).
Ruby is just slow, every time I see it, it is slow…

It depends on the project. I personally can’t make a tech recommendation unless we know what we need to optimize for.

If you need purely computational performance, then Ruby and Elixir would be a poor choice. I’d go with Java or Golang.

If you need cheap developers that can just plop out almost working code then Elixir would be a poor choice. I’d go with Ruby, or dare I say it PHP. I would also schedule a complete rewrite once the startup is profitable or falling apart. If you never get there then the tech stack wasn’t the problem

Other than those two issues, any of these languages will get the job done. My preference these days is elixir. It’s productive and stable enough that I would bet my startup on (or yours). That bet also includes being able to bring in experienced programmers and be able to bring in juniors and have them be productive.

The above posts layout the technical reason quite nicely, however, there is one very important factor that needs to be accounted for.

If you hire elixir developers they will be very excited to work with that stack. In my experience, a little bit of tech excitement goes a long way in an early startup. You have maybe two to three years to capitalize on that and then elixir is going to be boring, old, and the defacto standard.

Cheers,
Benjamin

Screw that, Rust runs circles around both!
Rust has some oddly fantastic web server libraries as well, I’ve been quite impressed.
Plus hey, Rust interacts wonderfully with Erlang/Elixir via Ports and NIF’s both!

Ok so, kinda hard to find a case study, but here are my point of view

Java

++ Easy to find devs
++ Easy to find “known practices”
++ Easy to sell to company
++ JVM is quite good at computational heavy stuff once warmed
– JVM is a really really finicky piece of software to operate
– Needs for overcomplex architecture and code to do anything
– Needs for a lot of “Best practices” to do the work
– Really hard to separate good from average devs.
– OOP, ie flawed by design

PHP

++ Easy to find devs
++ Easy to sell to companies (Facebook use it!)
++ PHP7 is not too bad at speed at all
++ Easy to deploy
– Broken by design
– Not really meant for long lived stuff
– Hard to operate.
– Hard to keep clean and maintainable
– Really hard to separate good from average devs

Ruby

++ Easy to find devs
++ Gem for everything
++ “Easy” to deploy
++ Nice for the devs
++ Can be easy to maintain if nicely done
– Flawed by design (OOP)
– Slow. As hell
– Not really easy to operate
– Really hard to separate good to average devs
– Really not meant for long lived stuff

Elixir

++ Nice for the devs
++ A design that make sense (and do not breaks the laws of physics)
++ Easy to maintain
++ Easy to operate and debug
++ Quite fast
++ Ease of interacting with other languages
++ “Habits of solving the hard problem the right way”
++ Accept the reality of errors and problems.
– Harder to find devs, but tend to be good
– Harder to find “Good Practices”
– A bit harder to deploy
– Meant mainly for longer lived stuff, bad at scripting.
– Hard to sell to other companies (there are case study mind you)
– Not good at computational heavy (but see interactions with others)

There i hope it helps

BTW @OvermindDL1, welcome to the RESF ( Rust Evangelism Strike Force)

I think it mostly depends what problems are you wanted to solve …, and what language has frameworks, libraries you need

• Elixir language for building scalable , distributed, fault tolerant system first in mind. Cons: quite new, maybe not all libraries you are looking for can be found, not for numbers crunching.
• Java Enterprise language, you can build almost everything from sim cards, adnroid apps, big data to micro services. Libraries mostly for everything. Cons: complicated concurrent system, quite old and keeps back compability. Fortunately there are some modern languages that runs on JVM like Kotlin.

The question is too general you have to describe the problem you are aiming to solve. I think it’s hard to go into more detail than @DianaOlympos provided without knowing the specifics.