Would you still pick Elixir in 2019?

A friend of dwyl asked the following question in our "chat" system:

We feel it's worth capturing the reply in public because it's relevant to anyone considering Elixir.

"Hi guys, sorry for bothering, but I need your help/input with something  I know that you have been working with Elixir now for a while  So I want to ask you guys on your thoughts about it now after doing some real work with it  The pro's, the con's  would you use it for rest api etc"

Let's give the question a bit of context first:

The OP asking the question is a talented/experienced programmer who has worked as a programmer for 10+ years and already knows JavaScript, Java, Scala, Elixir ( a basic app including GitHub OAuth ). They are a "senior engineer" at their current day job and make a good living by both national and international standards. However from speaking to them extensively they don't enjoy their Job.

( this last part might not be relevant so you can ignore it, but just to say they do not work for @dwyl ... despite our best efforts to offer them a job! )

Which Programming Language Should We Use... ?

The question of "Which Programming Language" is one we ask ourselves fairly regularly, and is the reason that lead us to discover and decide on using Elixir in 2016. We periodically survey the "up-and-coming" languages like Kotlin, Julia, Lua, etc. and keep concluding that our choice of Elixir is the one we would make again right now. Elixir is the "full package" from idea to deployment!

Not that you should allow yourself to be "lead" by the crowd , but it's useful know the pulse of the wider developer community, especially when trying to make the case for a new language at "work" or deciding what to learn for yourself.

Why Not Stick with JavaScript/Node.js?

At the time we ( our entire team/company/community ) were deciding what to learn/use next

were all proficient in JavaScript/Node.js and had built many projects using the "Old Stack" .

Our reasoning for "jumping ship" from Node.js to Elixir can be summarised by the following list:

• Node.js Error Handling :cry: ... if you've ever had to debug a production bug in Node.js you will know what I'm talking about. On large Node.js projects finding the source of a bug is an expedition ! And since Node is a single-threaded event loop, if the process crashes for one user, it crashes for all the requests being handled by that process. i.e. one user can crash the server for hundreds/thousands of people! This is a terrible design flaw ( that I used to think was a "feature"... ) it's "OK" on AWS Lambda where every request spawns a new process, but most Node.js is not being run on Lambda!
• JavaScript Fatigue :tired_face: there is a new library/framework vying for attention every week! it's exhausting! As a developer I just want to get on with my work, not have to read another Hackernoon post on how everything from last week is obsolete because XYZ framework "changes everything" ( for no good reason! ). Note: I love learning new things. just not re-learning in the same thing each time there is a "new" way of re-writing a function! JS did not need class . It's a horrible interface!
  see: https://medium.com/@Rewieer/javascript-the-bad-parts-and-how-to-avoid-them-1a7c9bc5a0dd
• Everyone thinks they can write JS code, few take the time to learn how to write maintainable JS.

  • From our extensive experience watching new people use JS/Node we saw people develop "bad habits" fast and completely disregard security in their rush to ship shiny features. The JS/Node ecosystem has grown way too fast for it's own good and is brittle/vulnerable as a result.

    see:

    • "Left Pad" https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos ‍♂️
    • "Event Stream": dominictarr/event-stream#116
• Facebook trying to "own" the JS ecosystem ... :rage:

  • The "State of JS" https://stateofjs.com is created/maintained by people who use Fb's JS "stack".

    They are all heavily biased toward React, GraphQL, etc. and as a result they are further perpetuating the use of these tools.

I don't like to think of @dwyl as having "competitors", but if I did, I would want them to use JS/Node.

Because it's an inferior experience to Elixir in every meaningful way.

Why Elixir?

Our "medium term" plan @dwyl is to build IoT devices to control our home https://github.com/dwyl/home

for this Elixir is perfect there literally is no better platform for IoT than https://nerves-project.org

Along the way we are building a distributed/decentralised learning platform that will heavily feature real-time interaction. Again, Elixir is perfect for this; nothing else comes close!

We have built several "CRUD" and "REST API + Elm Frontend" apps for clients over the past 2 years and I can honestly say that I'm happy to maintain any one of those apps and I think anyone else "inheriting" the codebase will thank us for how the code is written, tested and documented.

Pros

• Elixir is easy and fast to learn. Most people can achieve proficiency in less than a week ( focussed ).
• The language is beautifully designed for readability by one super smart "BDFL" who does "real work"; not just work in academia dreaming up esoteric language constructs. There are no "Norman Doors" in Elixir.
• Elixir Macros are a super slick way of encapsulating and re-using functionality.
  Every good language has Macros.
• Testing code is much nicer in Elixir than anything else . ExUnit is "baked in" and Property-based Testing is easy see: #93 This makes "real life" of a developer much better because writing tests is faster and the QA/PO can have high confidence in the code!
• BEAM is an incredible VM that runs seamlessly on any hardware/infrastructure.
• Error handling when things "break" is second to none. I would want my life support system to be built with Elixir. I intend to control my house , food and water with Elixir!
• There are many awesome projects in the ecosystem: https://github.com/h4cc/awesome-elixir which makes it easy to get "inspiration" and find solutions to common problems.
• People are using Elixir for Blockchain/Smart Contract apps and even Machine Learning.
  see: https://github.com/mana-ethereum/ethereumex and https://github.com/fredwu/simple_bayes
• Elixir is "coming soon" to AWS Lambda : dwyl/learn-aws-lambda#112 when this happens there will no longer be any reason for us to use Node.js I cannot wait !

Our "Real World" Experience

We have been using Elixir ( almost exclusively ) for the past 2 years for all our client and personal work.

I can say categorically that I prefer to write, read and maintain Elixir 10x more than any other language.

I return to Elixir code I wrote 18 months ago and I can immediately understand it and I don't feel the need to re-write any of it because it "just works".

Phoenix has been a joy to use for the projects we have worked on and because it's the de facto standard in the Elixir community, I'm confident that any code we have written is maintainable by anyone else with Phoenix experience. i.e. it's easy to "onboard" people into a Phoenix project because everything is where you expect it to be.

We are very pleased with the development in the Phoenix framework over the past few years

and Phoenix LiveView is going to be absolutely game changing ! see: dwyl/technology-stack#68

When new versions of Phoenix have been released the upgrade process has been painless.

see: dwyl/learn-phoenix-framework#118

The attention to detail in the Phoenix changelog / release notes makes it easy to upgrade.

I have zero regrets in adopting elixir for our client work and my personal projects.

If anything I wish I could go back in time and tell my 2012-self to "drop" Node.js sooner !

I regret trying to use a spoon to dig a swimming pool; pick the "right" tool and let the BEAM do the work!!

"Cons"?

• No "native" type for JSON data. You always have to parse JSON into a Map and there are excellent libraries for doing this. This is "fine" because it's fast, but I would prefer it if JSON was natively supported in Elixir so that I could copy-paste JSON data from JS-land directly into code/tests and just run it.
• Relatively difficult to " recruit " developers with existing experience in Elixir ( compared to Java/JS )
  This is rapidly disappearing as a "reason" to not adopt Elixir. The community is growing fast and there are even people on "Upwork" who list Elixir as experience/preference.
• Management ( at "big" companies ) who don't ( want to ) understand functional programming or the concept of people enjoying their work, will never see the point of Elixir.
• Fewer Jobs you can apply for as a Dev. This is just a fact you have to deal with.
  But if you prefer to work for open minded companies with good tech and learning culture,
  then Elixir is good filter/signal of a place you want to work.

There are hundreds of companies you can apply to work for.

see: elixir-companies and Jobs: http://plataformatec.com.br/elixir-radar/jobs

even McKinsey & Co are using Elixir!! ( I got a DM from someone trying to recruit me...! )

Anywhere that uses Ruby is a strong candidate for Elixir. Expect the adoption of Elixir to accelerate in the next few years. Whenever you read a job for "Ruby-on-Rails" you can basically apply for it and ask them: " do you want to save 90% of your server costs, add real-time features to your app and transform your recruiting? "

Use Case: REST API ... ?

A REST API is something you generally build for other people ( developers/companies ) to "consume". ( unless you are building "microservices" for internal consumption ... useful to clarify! )

The main goals of a REST API are to make it easy to understand and "consume" reliable to run.

If your use case is a simple REST API, I would recommend you just use what you ( already ) know.

If you know JS, use Express. If you know Java use light-rest-4j if you know PHP use Laravel. If already are familiar with Elixir, use maru it's lightweight and robust.

I feel the OP's_focus_ on "REST API" might not give us a full picture of what their end-goal is for the question ... are they re-writing an existing REST API to a new language/framework for better maintainability and performance? or create a brand new REST API from scratch?

In many situations, the choice of programming language is less important than the "deployment" of the resulting application. If work somewhere "traditional" where the "DevOps" people are not ready to support an Elixir App, then the question of "which programming language" is moot.

The biggest question anyone considering Elixir needs to ask is: do other people in my team/company want to try something different? i.e. will "Negative Nancy" shoot it down? and will "DevOps" support it?

If you work somewhere that does not have a kaizen learning culture , fuhgeddaboudit .

If you are lucky enough to work somewhere that is open minded about tech, find a way to show your "boss" or peers that Elixir is an excellent choice for anything "real time" and "high reliability".

Conclusion

These are the languages I would recommend to anyone in the OP's position in order :

1. Elixir - because it's a "friendly" way to leverage all of the real-time power of BEAM. It has excellent tooling, property-based testing, deployment, monitoring and tracing.
2. Rust - a close second to Elixir. Great for systems programming and building cross-platform apps, but expect "breaking changes" as still being actively developed ( whereas Elixir is far more "stable" ).
3. Go - Is the choice if you need to "sell it" to a "Boss" . The fact that it's "sponsored" by Google and has full support on App Engine, GCF, and now AWS Lambda are major plusses. We don't use it because it's more verbose than Elixir, is more difficult to write real-time code and has an imperative programming style, which we find leads to more complexity .
4. Haskell - The obvious choice if "purity" of your functions is a high consideration, but nowhere near as "fast" as Elixir and considerably more difficult to learn. Most companies are "afraid" of Haskell. The ones who have embraced it wouldn't use anything else !
5. Clojure - If you work somewhere with a lot of JVM code, this will be easiest to adopt.
6. Python - if you don't care about the infrastructure/server costs and just want an "easy life" as a developer. e.g. you don't need anything "real time" and just want RESTful "CRUD", use Django on Google Cloud: https://cloud.google.com/python/django
7. Are you still reading this? Start learning Elixir!!

Next ?

If you are reading this wondering what to do/learn next ...

• Elixir Simple REST API example: https://blog.lelonek.me/minimal-elixir-http2-server-64188d0c1f3a
• Phoenix REST API: https://becoming-functional.com/building-a-rest-api-with-phoenix-and-elixir-b12dcec302c5
• Chat: https://github.com/dwyl/phoenix-chat-example
• Encryption: https://github.com/dwyl/phoenix-ecto-encryption-example
• Append-only Immutable data: https://github.com/dwyl/phoenix-ecto-append-only-log-example