A simple question, I started a project , - Api + channels in elixir/phoenix and a ionic mobile app - , I’m not using the killer features of elixir as OTP (I know channels use OTP but I’m not using OTP explicitly). Am I still getting the benefits of elixir speed even though I don’t use OTP? or if I don’t use OTP at the end it’s the same if I write the API in elixir, ruby, python etc?
Elixir is still a compiled, byte code-based language as opposed to an interpreted language. That will buy you some speed benefit over interpreted, more dynamic languages.
Channels use OTP sure, but so does Phoenix and all the applications that it makes use of. You’re going to be taking advantage of some parallelism whether you want to or not
There are soooooo many
It’s incredibly easy to build your apps as a series of components and microservices.
One of the reasons Elixir code is more maintainable, readable and easy to make sense of is because you don’t rely on endless if/else statements. So whereas traditionally (say in an OO language) you could have a method with several different outcomes depending on the number of if/elses (and nested if/elses) which can be a nightmare to traverse, in Elixir you can simply use pattern matching with multiple method definitions so each function really only has a single responsibility. This makes it incredibly easy to refactor or extend your code.
There are loads more too, check out some of these threads:
Immutability is one of the big big things. It makes your code easy to reason about, unlike python/ruby/etc…
Macro’s are awesome as well, though those can make your code more difficult to reason about, so best to minimize them if possible (unless that process makes the code more unreadable, find the balance ^.^).
The ecosystem is fantastic as well, but so are rubys and pythons.
From another perspective, the developer conveniences are great! I’ve been using VS Code and the intellisense I get from Elixir + Code is amazing because it’s a compiled language.
Also, I get a lot of value out of documentation being a first class citizen in Elixir. I’ve been trying to write at least some documentation for every public function that I write in this app I’m working on and the benefits are two fold - 1) the autocomplete/intellisense I get out of Code saves me a ton of time and trying to remember, and 2) onboarding new developers is much much easier because I can use exdoc to build an easy to use and searchable site for my app.
I’ll be the contrarian: nope, OTP is it. No other benefits. Every functional programming and/or immutability benefit is available elsewhere. You can get something similar to OTP in some other places that were heavily influenced by OTP like Akka, but their VM can’t offer the same sorts of guarantees as one built with fault tolerance in mind. That’s the core where supervisors and fault tolerance exist and what fundamentally makes BEAM different than other environments.
Once you decide that, it becomes an issue of aesthetics/practicality/background whether you want to work in erlang, elixir, lisp flavored erlang, erlua, etc.
I have to say I’m extremely dissapointed with the autocomplete for VS Code. It works 6 times out of 10 for some reason. I’m not sure why.
Sometimes it autocompletes, sometimes it does’t. I’m this close to just installing intellij and using their Elixir package to have proper intellisense.
11 posts were split to a new topic: Elixir IDE discussion
You haven’t used anything eclipse based yet
Not only that IntelliJ is/feels faster, it also looks good even if one does not use the default Win XP colortheme…
This was a solid read from a couple of days ago that answers the original question really well IMO.
After reading other articles, I can see that there are other benefits, for example even for running tests, I think the tests are run in parallel using all the cores, so that’s something we get even if we don’t explicitly use OTP. I think start time is also improved and response time as well.
This article helped me understand some of these points, especially Fallacy 1: Performance is only a production concern