Checkout this huge discussion:
opened 03:19AM - 07 Dec 18 UTC
question
discuss
starter
A friend of dwyl asked the following question in our "chat" system:
![questio… n-using-elixir-rest-api](https://user-images.githubusercontent.com/194400/49619100-06012280-f9b3-11e8-96a1-bf929b17bf08.png)
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!
A good place to look for the _trends_ is in the "Most Wanted" list of the StackOverflow Survey:
https://insights.stackoverflow.com/survey/2018
Sadly, for some reason SO decided to _exclude_ Elixir from their list this year! But the last time they "allowed" it as one of the options is came out near the [top](https://insights.stackoverflow.com/survey/2016#most-popular-technologies-other):
![image](https://user-images.githubusercontent.com/194400/49622047-dc9ac380-f9bf-11e8-9a44-270929608738.png)
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"](https://github.com/dwyl/technology-stack#nodejs-stack).
Our _reasoning_ for "jumping ship" from Node.js to Elixir can be summarised by the following list:
+ Node.js Error Handling 😢 ... 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 😫 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": https://github.com/dominictarr/event-stream/issues/116 🙄
+ Facebook trying to ["own"](https://github.com/dwyl/technology-stack/issues/39#issuecomment-275881894) the JS ecosystem ... 😡
+ 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"](https://github.com/josevalim) who does "real work"; not just work in academia dreaming up esoteric language constructs. There are no ["Norman Doors"](https://youtu.be/yY96hTb8WgI) 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: https://github.com/dwyl/learn-elixir/issues/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**: https://github.com/dwyl/learn-aws-lambda/issues/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: https://github.com/dwyl/technology-stack/issues/68
When new versions of Phoenix have been released the upgrade process has been painless.
see: https://github.com/dwyl/learn-phoenix-framework/issues/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"](https://www.upwork.com/o/jobs/browse/skill/elixir) 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](https://github.com/doomspork/elixir-companies/blob/master/src/_data/companies.yml) and Jobs: http://plataformatec.com.br/elixir-radar/jobs
even [McKinsey & Co](https://www.linkedin.com/jobs/view/987302695/) 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_](https://github.com/nelsonic/nelsonic.github.io/issues/445#issuecomment-385388858) 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`](https://github.com/networknt/light-rest-4j) if you know PHP use Laravel. If _already_ are familiar with Elixir, use [maru](https://github.com/elixir-maru/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"](https://en.wikipedia.org/wiki/Pointy-haired_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, we have created several beginner friendly tutorials that take you from zero to fully functional App:
+ TodoMVC Todo List Tutorial: https://github.com/dwyl/phoenix-todo-list-tutorial
+ Real-time Chat App: https://github.com/dwyl/phoenix-chat-example
+ HTML + REST API Tutorial: https://github.com/dwyl/phoenix-content-negotiation-tutorial
+ Encryption: https://github.com/dwyl/phoenix-ecto-encryption-example
+ Append-only Immutable data: https://github.com/dwyl/phoenix-ecto-append-only-log-example
<!--
+ 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
-->
2022 StackOverflow Dev Survey: Elixir
+ Phoenix
In May 2022 over 70,000 developers told us how they learn and level up, which tools they’re using, and what they want.
Elixir
has finally been re-included in the SO survey
and surprise-surprise it’s the 2nd “Most Loved” programming language:
Phoenix
tops the list of “Most Loved” Frameworks
Also: Postgres
is on top for databases!
The people have spoken.
5 Likes
So may good responses here, and yet I still feel compelled to drop my small opinion.
Phoenix as a framework makes it possible for me to be a one-man developer for the first time in a decade.
My last major project was primarily in node. It’s fine, but so many issues, particularly with the fact that all numbers are floats (don’t tell me “typescript”). I’m not nearly as productive in JS as I am in elixir. Elixir’s declarative nature clicks with my brain in a way that no imperative language does.
My next language will be Rust because that seems to be a good place to go for a compiled language. I’m the boss at work where it comes to tech, and all my work projects are being migrated to Elixir.
6 Likes
AstonJ
Split this topic
October 19, 2022, 8:26pm
23
Hey I found out about Burrito yesterday!