Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
I'll be starting to work on a new project from next month and I've been reading all but good news about Elixir. I have talked to people in real life, most of the devs had positive things to say about it. Does anyone have any arguments against selecting Elixir? Question coming from RoR developer.
296 comments
My company is moving away from it. We built a few services but after a few years some of the original people that introduced it left the company and it became very difficult to hire for. New hires were either people wanting to learn (so we had to spend a good bunch of resources into teaching + end up with a system built by noobs to the language) or very expensive developers with a lot of experience in erlang and elixir.
We also found many times missing libraries, or found libraries which are incomplete, or unmaintained or just not well documented. Just compare the total amount of libraries in Hex, vs the total amount of libraries in rubygems. Somebody will say "but Elixir libraries are higher quality so we need less, etc,etc" as if there were not good developers in the ruby world and every elixir developer were a rockstar.
Tooling is just terrible. The VSCode plugin is crap, kills the CPU unless you disable features. There is no IDE from jetbrains. There is a plugin but last time I tried it, it was even worse than the VSCode plugin.
Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier. That was our thinking at first. But then you realize on deployments you will lose your cache, or your background jobs, etc. So you have to persist them either in mnesia or in the database. At that point you're just reinventing your crappy undocumented and untested version of delayed_job.
Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS.... you will need more than 1 server anyway, so...
Liveview sounds amazing until you try to use it in the real world. The most minimum latency kills the experience.
In the end, we are back to Rails and much happier. Specially now we are using all the hotwire stuff. Not fancy, and not fashionable though.
We also found many times missing libraries, or found libraries which are incomplete, or unmaintained or just not well documented. Just compare the total amount of libraries in Hex, vs the total amount of libraries in rubygems. Somebody will say "but Elixir libraries are higher quality so we need less, etc,etc" as if there were not good developers in the ruby world and every elixir developer were a rockstar.
Tooling is just terrible. The VSCode plugin is crap, kills the CPU unless you disable features. There is no IDE from jetbrains. There is a plugin but last time I tried it, it was even worse than the VSCode plugin.
Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier. That was our thinking at first. But then you realize on deployments you will lose your cache, or your background jobs, etc. So you have to persist them either in mnesia or in the database. At that point you're just reinventing your crappy undocumented and untested version of delayed_job.
Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS.... you will need more than 1 server anyway, so...
Liveview sounds amazing until you try to use it in the real world. The most minimum latency kills the experience.
In the end, we are back to Rails and much happier. Specially now we are using all the hotwire stuff. Not fancy, and not fashionable though.
> Tooling is just terrible. The VSCode plugin is crap, kills the CPU unless you disable features. There is no IDE from jetbrains. There is a plugin but last time I tried it, it was even worse than the VSCode plugin.
I am using VSCode too and the experience is not as good as with Typescript/Javascript but is not that terrible either. I would compare it with Rust's experience, so far.
> Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier. That was our thinking at first. But then you realize on deployments you will lose your cache, or your background jobs, etc. So you have to persist them either in mnesia or in the database. At that point you're just reinventing your crappy undocumented and untested version of delayed_job.
Of course you need _other_ libraries to achieve some of those things. You do not have a queue built it but there are some very good tools like Oban https://github.com/sorentwo/oban that are basically doing what Sidekiq does, just relying on the main database you are already using. There are also very good libraries for caching that rely on ETS and that simply replaces what you could do with Redis.
> Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS.... you will need more than 1 server anyway, so...
This is partially true. The ability of BEAM to cluster and execute processes inside the cluster, internal communication between actors and so on are not _just_ achievable with k8s, not without a good added complexity.
I am using VSCode too and the experience is not as good as with Typescript/Javascript but is not that terrible either. I would compare it with Rust's experience, so far.
> Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier. That was our thinking at first. But then you realize on deployments you will lose your cache, or your background jobs, etc. So you have to persist them either in mnesia or in the database. At that point you're just reinventing your crappy undocumented and untested version of delayed_job.
Of course you need _other_ libraries to achieve some of those things. You do not have a queue built it but there are some very good tools like Oban https://github.com/sorentwo/oban that are basically doing what Sidekiq does, just relying on the main database you are already using. There are also very good libraries for caching that rely on ETS and that simply replaces what you could do with Redis.
> Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS.... you will need more than 1 server anyway, so...
This is partially true. The ability of BEAM to cluster and execute processes inside the cluster, internal communication between actors and so on are not _just_ achievable with k8s, not without a good added complexity.
> Specially now we are using all the hotwire stuff.
Maybe I'm missing something, but doesn't this have precisely the same latency characteristics as live view?
I do agree that some of the "you don't need redis" and similar are overblown (particularly claims about tasks replacing background jobs), but I think there is truth to these claims in the following sense: Particularly in Rails, Redis gets used not just as a tool, but also to manage shortcomings in the language / runtime. Eg: Hotwire. Ruby doesn't have a good way to concurrently manage stateful connections, so it has to fallback to Redis. Ruby doesn't have a good way to manage inter-process or inter-node communication, so once again Redis steps in to fill that gap.
There's nothing wrong with using Redis, it's a fantastic tool. Using it as a state holder for an event loop through ends up feeling extremely convoluted after you've written a few GenServers (Phoenix channels / liveview).
Maybe I'm missing something, but doesn't this have precisely the same latency characteristics as live view?
I do agree that some of the "you don't need redis" and similar are overblown (particularly claims about tasks replacing background jobs), but I think there is truth to these claims in the following sense: Particularly in Rails, Redis gets used not just as a tool, but also to manage shortcomings in the language / runtime. Eg: Hotwire. Ruby doesn't have a good way to concurrently manage stateful connections, so it has to fallback to Redis. Ruby doesn't have a good way to manage inter-process or inter-node communication, so once again Redis steps in to fill that gap.
There's nothing wrong with using Redis, it's a fantastic tool. Using it as a state holder for an event loop through ends up feeling extremely convoluted after you've written a few GenServers (Phoenix channels / liveview).
Liveview (as well as stimulus-reflex) promote minimal JavaScript by trying to push most interactions to the server, and let the server decide what should change in the frontend. So for example, to show a modal, you send an event that signals the user wants to show a modal, so the backend sends back the html for the modal. You click to close the modal, this sends an event to the backend, the backend sends you the diff or the instructions to remove the modal from the dom.
In the hotwire world, the encouraged approach would be to already have the html in the dom, and use a stimulus controller to show or hide it [1]. And you only issue backend calls when you really need to reach to the backend anyway (like submitting a form, or refreshing some actual content). You don't call the backend just to signal a button was clicked so that the backend removes html if you can already do that in the frontend. Hotwire is not about avoiding JavaScript, hotwire is avoid organizing it well and reducing the amount you need.
Of course you can do things wrong on both approaches, but it is what one approach promotes vs the other.
As an example of why this is a problem, see this [2] example. I'm in Europe on a fiber connection, and clicking in one of the calendar days, and closing the modal feels just so terrible....
[1] https://tighten.co/blog/stimulus-101-building-a-modal/ [2] http://expo.stimulusreflex.com/demos/calendar/2021-05-01
In the hotwire world, the encouraged approach would be to already have the html in the dom, and use a stimulus controller to show or hide it [1]. And you only issue backend calls when you really need to reach to the backend anyway (like submitting a form, or refreshing some actual content). You don't call the backend just to signal a button was clicked so that the backend removes html if you can already do that in the frontend. Hotwire is not about avoiding JavaScript, hotwire is avoid organizing it well and reducing the amount you need.
Of course you can do things wrong on both approaches, but it is what one approach promotes vs the other.
As an example of why this is a problem, see this [2] example. I'm in Europe on a fiber connection, and clicking in one of the calendar days, and closing the modal feels just so terrible....
[1] https://tighten.co/blog/stimulus-101-building-a-modal/ [2] http://expo.stimulusreflex.com/demos/calendar/2021-05-01
Yup. And as illustrated by OP's example links, avoid Stimulus Reflex (NOT stimulus.js) for production too. Apart from the stated reasons, the fact that websocket connections aren't scoped by User by default is a really, REALLY sharp edge!
As far as security is concerned, it's the application's responsibility to properly scope websocket connections... if and when that's appropriate. This is true of any websocket connection, not just those used by StimulusReflex or even ActionCable.
As noted by the parent, latency is certainly a consideration when using such tools, but there are a myriad of libs and techniques that can be leveraged to help you build great user experiences with StimulusReflex and LiveView. You just need to consider your options and architect accordingly.
Note also that the expo demos for StimulusReflex are incredibly old (a few major versions behind at this point) and were created in haste to help people grok concepts via example. They were never intended to be a canonical guide of how to best architect such apps at scale. We're considering taking the expo site offline in favor of more specific and better architected demos.
As noted by the parent, latency is certainly a consideration when using such tools, but there are a myriad of libs and techniques that can be leveraged to help you build great user experiences with StimulusReflex and LiveView. You just need to consider your options and architect accordingly.
Note also that the expo demos for StimulusReflex are incredibly old (a few major versions behind at this point) and were created in haste to help people grok concepts via example. They were never intended to be a canonical guide of how to best architect such apps at scale. We're considering taking the expo site offline in favor of more specific and better architected demos.
This is also true of REST requests. They're not scoped to the user by default. In fact, Rails doesn't even have the concept of a user by default.
The argument against using actioncable because it doesn't scope to users by default is roughly akin to arguing against rails in production because rails doesn't even know what a user is by default.
The argument against using actioncable because it doesn't scope to users by default is roughly akin to arguing against rails in production because rails doesn't even know what a user is by default.
Im a little puzzled by this.
This is essentially like saying "Dont use Rails, the controllers arent scoped to the user by default"
There are plenty of valid reasons to use websockets not scoped to a user. Also how is SR supposed to know your user scheme?
What if you have a multi-tenant app and websockets should be scoped to an account and not a user? Im honestly confused by this statement.
This is essentially like saying "Dont use Rails, the controllers arent scoped to the user by default"
There are plenty of valid reasons to use websockets not scoped to a user. Also how is SR supposed to know your user scheme?
What if you have a multi-tenant app and websockets should be scoped to an account and not a user? Im honestly confused by this statement.
Wouldn't you just override the defaults if you need to scope at the account level?
There are plenty of valid reasons to not scope it to a user. Having the default scoped to the most common case makes sense.
There are plenty of valid reasons to not scope it to a user. Having the default scoped to the most common case makes sense.
> In the hotwire world, the encouraged approach would be to already have the html in the dom, and use a stimulus controller to show or hide it
You could also use a turbo-frame here: the modal might contain data that could be expensive to pre-render in the first pass. For example, you have a list of things and you want a modal to show additional details for each thing rather than require navigation to a detail view. Those additional details might need more SQL queries that you don't necessarily want to include in your initial list render, so it makes sense to have that pulled from a separate request.
Closing the modal though should not require another round-trip to the server, that can be done with Javascript.
You could also use a turbo-frame here: the modal might contain data that could be expensive to pre-render in the first pass. For example, you have a list of things and you want a modal to show additional details for each thing rather than require navigation to a detail view. Those additional details might need more SQL queries that you don't necessarily want to include in your initial list render, so it makes sense to have that pulled from a separate request.
Closing the modal though should not require another round-trip to the server, that can be done with Javascript.
Nothing about StimulusReflex pushes you away from this approach. This all comes down to the developer.
StimulusReflex is built on top of Stimulus. The point of SR isnt necessarily to write less javascript, its an easier way to sync client and server state and have a single source of truth.
Use SR where SR makes sense, but just because you have a hammer doesnt mean everything is a nail.
StimulusReflex is built on top of Stimulus. The point of SR isnt necessarily to write less javascript, its an easier way to sync client and server state and have a single source of truth.
Use SR where SR makes sense, but just because you have a hammer doesnt mean everything is a nail.
The trick is to use liveview for data that needs to come from the server anyway. I'd guess that the OP did use it for everything, like popups etc and did not do the same with hotwire.
So what's the recommended approach for doing it without liveview in the liveview world? jquery? just document.addEventListener?
That's what hotwire gives you: an opinionated approach and a golden path to do things in a manageable way.
That's what hotwire gives you: an opinionated approach and a golden path to do things in a manageable way.
You can use alpine.js. There is even a way to integrate it with LV: https://dockyard.com/blog/2020/12/21/optimizing-user-experie...
<button
@mouseenter.once="
fetch('/dropdown-partial.html')
.then(response => response.text())
.then(html => { $refs.dropdown.innerHTML = html })
"
@click="open = true"
>Show Dropdown</button>
Seriously? This has to be a joke.
Seriously? This has to be a joke.
I was stumped when I saw it just now. What the heck...I guess the next thing, an amazing breakthrough, is going to be Alpine.scss style="background-color:$red-secondary;font-weight:bold"
I don't use alpine, but isn't that the blessed way of doing it in React/Vue/etc? I thought they were the ones introducing both @handlers on elements and JSX styling
Maybe, except in React you have a huge community, formatters, linters, editors, testing tools/libraries and an overall architecture for doing things. Alpine seems worse than just using jQuery. I'd prefer to use something like Unpoly before using this monstrosity.
Then don't use it, no one is forcing you man. Just because it is not for you doesn't mean its bad or that other people can't have use for it.
You don't really need to use alpine either if you use Phoenix with Liveview, you can probably get away with just using vanilla js if all you really need is some small functionality of modals popping up etc.
You don't really need to use alpine either if you use Phoenix with Liveview, you can probably get away with just using vanilla js if all you really need is some small functionality of modals popping up etc.
why would you load the dropdown HTML separately, just render it along in the template with x-show="open" and have the @click="open=true"?
This is an example from their docs. That's why.
There's the so-called "PETAL" stack these days: Phoenix, Elixir, Tailwind.css, Alpine.js, LiveView. In that scenario, you use Alpine.js for the frontend-only stuff.
> Maybe I'm missing something, but doesn't this have precisely the same latency characteristics as live view?
There's an open GitHub issue on LV which mentions when using live_redirect you're paying a very large penalty in page load speeds due to extra latency being introduced by LV: https://github.com/phoenixframework/phoenix_live_view/issues...
Before this issue existed my non-scientific impression was the same. There was something that felt off when using sites that primarily used LV for navigation and loading content. It always felt like I was clicking, waiting a noticeable amount of time and then the content would appear -- even with a decent ping time (< 100ms).
I never experienced that type of delay when using Turbolinks and now Hotwire Turbo with comparable ping times to a server.
There's an open GitHub issue on LV which mentions when using live_redirect you're paying a very large penalty in page load speeds due to extra latency being introduced by LV: https://github.com/phoenixframework/phoenix_live_view/issues...
Before this issue existed my non-scientific impression was the same. There was something that felt off when using sites that primarily used LV for navigation and loading content. It always felt like I was clicking, waiting a noticeable amount of time and then the content would appear -- even with a decent ping time (< 100ms).
I never experienced that type of delay when using Turbolinks and now Hotwire Turbo with comparable ping times to a server.
Interesting analysis. Do you have any quick examples of site's that use LV? I'm curious.
Not at the moment, but I remember someone posting an example LV page on Twitter a few months ago for pagination and I distinctly remember how delayed the page felt and I pinged 80ms to the server. Basically I've seen scattered examples when they were posted over the years on various social sites.
I'm having a hard time finding a current example demo LV app that demonstrates page transitions using LV or to be honest any sites heavily using LV in general.
But it should be reproduceable in a demo app that uses live_redirect to transition between pages. The issue has repeatable steps and it's been confirmed as a bug by the maintainers of LV, except it looks like it's going to be tricky to solve it.
I'm having a hard time finding a current example demo LV app that demonstrates page transitions using LV or to be honest any sites heavily using LV in general.
But it should be reproduceable in a demo app that uses live_redirect to transition between pages. The issue has repeatable steps and it's been confirmed as a bug by the maintainers of LV, except it looks like it's going to be tricky to solve it.
Those advantages are really overblown and not worth the hit in missing libraries or missing hires.
Totally agree. I've been in this industry since 2001 and never, ever had a performance problem which couldn't be solved with just thinking what your code is actually doing. The bottleneck has been always the database, or the network, etc. The only problem I've had with threaded languages is running out of threads/processes due to making external API network requests, etc, but you learn to not block threads by using jobs, etc. And worst case, more hardware has been always cheaper than more developers due to less productive languages (hello Go! :wink: :wink:).
You are not Google.
You are not Google.
Performance is one thing. I think another major benefit people cite for using Elixir/functional programming in general is the productivity aspect. Of course you may argue that this is easily outweighed by hiring pains as a company grows. Just wanted to mention that from a pure language/developer perspective, I'd much prefer to work with Elixir than something like Java or even Go.
I fully agree with you, but the demographics in HN is special -- you may be talking to people who work at Google-scale :P
Anyway I believe you really need a very special case to make Elixir shine. Obviously you can build whatever you want with it, and it's really nice, but if you are doing consulting you are going on for a hard sell. And startups will sooner or later feel the crunch of more expensive and/or difficult hiring.
Anyway I believe you really need a very special case to make Elixir shine. Obviously you can build whatever you want with it, and it's really nice, but if you are doing consulting you are going on for a hard sell. And startups will sooner or later feel the crunch of more expensive and/or difficult hiring.
Yep, the benefits most esoteric languages offer are superficial compared to the benefits a mainstream language ecosystem offers.
> Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS.... you will need more than 1 server anyway, so...
For what is worth, that's one of the reasons why Elixir exists in the first place. I find the Erlang VM a fantastic platform and there is no reason to restrict it to high availability/distributed scenarios. Elixir developers should be productive and write performant and maintainable applications, even if at the end of the day they are just pushing to Heroku. Especially if you are coming from another dynamic language, such as JS/Ruby/Python.
As I like to say, in the "worst" case scenario, you can use Elixir as you would any other language, and that's completely fine!
If you want/need to go deeper, the abstractions are there to do so, and that's the difference compared to K8s: it is happening one layer inside. The high-level principles of redundancy and availability exist at the library level, so you can look at your connection pool, message queue, http clients, and find the same ideas there. Another area where K8s directly complements Erlang is in helping establish clusters. Overall, they are rather working together rather than stepping on each other toes. I wrote more about this here: https://dashbit.co/blog/kubernetes-and-the-erlang-vm-orchest...
For what is worth, that's one of the reasons why Elixir exists in the first place. I find the Erlang VM a fantastic platform and there is no reason to restrict it to high availability/distributed scenarios. Elixir developers should be productive and write performant and maintainable applications, even if at the end of the day they are just pushing to Heroku. Especially if you are coming from another dynamic language, such as JS/Ruby/Python.
As I like to say, in the "worst" case scenario, you can use Elixir as you would any other language, and that's completely fine!
If you want/need to go deeper, the abstractions are there to do so, and that's the difference compared to K8s: it is happening one layer inside. The high-level principles of redundancy and availability exist at the library level, so you can look at your connection pool, message queue, http clients, and find the same ideas there. Another area where K8s directly complements Erlang is in helping establish clusters. Overall, they are rather working together rather than stepping on each other toes. I wrote more about this here: https://dashbit.co/blog/kubernetes-and-the-erlang-vm-orchest...
I am bummed out to see that this is the top comment. I don't doubt your experiences but I hope that other people do not latch on to this and use it as a strong argument against using Elixir. All of these complaints are skin deep and kinda petty, to be honest.
> Tooling is just terrible. The VSCode plugin is crap, kills the CPU unless you disable features. There is no IDE from jetbrains.
This is a bizarre criticism of Elxir the language. There are a lot of developers out there who prefer a more lightweight editor and do not want the bells, whistles and crutches of a heavy duty environment. I would never complain about a language just because an IDE does not exist for it.
Tooling in Elixir is really some of the best I have ever used as far as the consistency had with mix, hex, hexdocs, etc...
> Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier.
You can still use all the same battle tested tools with Elixir... but it is true that there are lots of situations where those things are genuinely not needed thanks to some of the things that come out of the box on BEAM.
> Tooling is just terrible. The VSCode plugin is crap, kills the CPU unless you disable features. There is no IDE from jetbrains.
This is a bizarre criticism of Elxir the language. There are a lot of developers out there who prefer a more lightweight editor and do not want the bells, whistles and crutches of a heavy duty environment. I would never complain about a language just because an IDE does not exist for it.
Tooling in Elixir is really some of the best I have ever used as far as the consistency had with mix, hex, hexdocs, etc...
> Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier.
You can still use all the same battle tested tools with Elixir... but it is true that there are lots of situations where those things are genuinely not needed thanks to some of the things that come out of the box on BEAM.
> This is a bizarre criticism of Elxir the language. There are a lot of developers out there who prefer a more lightweight editor and do not want the bells, whistles and crutches of a heavy duty environment.
Right, but...there are also developers out there who do want those things.
It feels very dismissive to dismiss a complaint like that as "petty" just because there's a set of people who don't have the same needs. I feel like it's a very useful piece of information about the language that doesn't feel at all petty to me.
If you don't want the IDE-like tooling, then you can read the comment and think: "ah, they want more tooling than I do, so this critique doesn't apply to my use-case". If you do want that style tooling, then you might read the comment and think: "Ah, that's good to know. That applies to me, and I'll definitely take it into consideration".
Someone having priorities that are different from you doesn't seem "petty" to me. It just seems...like different priorities.
Right, but...there are also developers out there who do want those things.
It feels very dismissive to dismiss a complaint like that as "petty" just because there's a set of people who don't have the same needs. I feel like it's a very useful piece of information about the language that doesn't feel at all petty to me.
If you don't want the IDE-like tooling, then you can read the comment and think: "ah, they want more tooling than I do, so this critique doesn't apply to my use-case". If you do want that style tooling, then you might read the comment and think: "Ah, that's good to know. That applies to me, and I'll definitely take it into consideration".
Someone having priorities that are different from you doesn't seem "petty" to me. It just seems...like different priorities.
Exactly. One of the MOST valid criticisms of a language is the way (or lack of ways) in which it can be used.
Don't focus on tooling, focus on their complaints about not having enough senior engineers familiar with the language.
We're in a similar boat. I don't know the full history of how we came to use Elixir, but I would wager that early on in the company, someone really loved it and evangelized it. But now, we don't have that many senior people who know it well. I can count the ones I talk to regularly on one hand, and once I run out of fingers, I'm probably sixth place runner up, which makes me very uncomfortable.
That's why I wouldn't suggest Elixir. Unless you're incredibly sure you won't have significant churn for the lifetime of your business, or have money to burn specifically hiring Elixir folks, I wouldn't recommend it.
We're in a similar boat. I don't know the full history of how we came to use Elixir, but I would wager that early on in the company, someone really loved it and evangelized it. But now, we don't have that many senior people who know it well. I can count the ones I talk to regularly on one hand, and once I run out of fingers, I'm probably sixth place runner up, which makes me very uncomfortable.
That's why I wouldn't suggest Elixir. Unless you're incredibly sure you won't have significant churn for the lifetime of your business, or have money to burn specifically hiring Elixir folks, I wouldn't recommend it.
This is not the fault of Elixir. It’s the fault of trigger happy CTO’s who chase shiny new objects without thinking about the long term, big picture. I’ve made plenty of unsexy decisions when my heart was pulling me in a different direction - because it’s the right thing to do based on the team you have or the direction you’re headed.
Adopting Elixir, like Clojure or Haskell or any of the more esoteric languages is a commitment. Don’t do it if the benefits aren’t there or you aren’t willing to make the investment.
Adopting Elixir, like Clojure or Haskell or any of the more esoteric languages is a commitment. Don’t do it if the benefits aren’t there or you aren’t willing to make the investment.
> This is not the fault of Elixir.
That's very true. But it's still something to consider, especially for OP who's choosing a new language for a new project.
That's very true. But it's still something to consider, especially for OP who's choosing a new language for a new project.
What do you think has been the difficulty for people at your company learning it?
I encounter a lot of devs, especially experienced devs who pick it up very rapidly compared to what I've ever seen with JavaScript, ObjC, Rust or other most other languages I've spent time with.
I encounter a lot of devs, especially experienced devs who pick it up very rapidly compared to what I've ever seen with JavaScript, ObjC, Rust or other most other languages I've spent time with.
For simple things like "add field to GraphQL schema, hook it up to a resolver, and read some data from the database" - doesn't take too long.
The language itself is very different from the C-like imperative languages most everyone knows, so there's a bit of a ramp-up from that, but for basics, people can be released into the codebase within a month.
But when things go wrong, or when you need to do something more complicated, things get difficult. It's much more difficult to google around for solutions. When Dialyzer is spitting out strange errors, hunting down their causes and solutions is challenging without someone who understands it around.
I feel like 99% of Typescript/Ruby problems have been encountered and enshrined in Stack Overflow and the like, but Elixir doesn't have that sort of volume.
It's a fun language, and worth learning, and I played around with it in a side project, but quickly started running into conceptual roadblocks when it came to (no surpise) the GenServer stuff, and how to actually spin up a stable service that does things in some given way. I probably could have stuck with it, but at that point it felt more like toil than joy, so I decided I'd rather do something else with my time. I'd be fine with going to work for another company working with Elixir, provided that there were people there who can swoop in from above and help me solve my problems.
The language itself is very different from the C-like imperative languages most everyone knows, so there's a bit of a ramp-up from that, but for basics, people can be released into the codebase within a month.
But when things go wrong, or when you need to do something more complicated, things get difficult. It's much more difficult to google around for solutions. When Dialyzer is spitting out strange errors, hunting down their causes and solutions is challenging without someone who understands it around.
I feel like 99% of Typescript/Ruby problems have been encountered and enshrined in Stack Overflow and the like, but Elixir doesn't have that sort of volume.
It's a fun language, and worth learning, and I played around with it in a side project, but quickly started running into conceptual roadblocks when it came to (no surpise) the GenServer stuff, and how to actually spin up a stable service that does things in some given way. I probably could have stuck with it, but at that point it felt more like toil than joy, so I decided I'd rather do something else with my time. I'd be fine with going to work for another company working with Elixir, provided that there were people there who can swoop in from above and help me solve my problems.
what area/work does your company do? advertising?
> I would never complain about a language just because an IDE does not exist for it.
I think their complaint is valid, especially in light of their finding it difficult to find experienced coders who are in their salary range.
New coders can lean heavily on a good IDE to help: code completion, breakpoints, step wise debugging, one click links to the docs, easy code navigation, and more. Senior coders can and should use the editor of choice, but a great IDE makes a world of difference for a junior or even intermediate coder.
I think their complaint is valid, especially in light of their finding it difficult to find experienced coders who are in their salary range.
New coders can lean heavily on a good IDE to help: code completion, breakpoints, step wise debugging, one click links to the docs, easy code navigation, and more. Senior coders can and should use the editor of choice, but a great IDE makes a world of difference for a junior or even intermediate coder.
I haven't used elixir but used erlang for a while, with emacs. It did have a learning curve, but I don't think an IDE would have helped.
I worked on an elixir project at a ruby shop for about a year. We had complex distributed system, and were replacing core ruby services with elixir. Ultimately the project was a failure, and was re-re-written in Ruby, and the Elixir devs were let go.
We faced similar issues to you, bad tooling, weak libraries, and very few knowledgeable devs.
Finding people to hack on elixir was extremely difficult, and likely the driving force that killed the project. Having an inexperienced team who had no experience with many of the language features elixir offered created a very difficult to work in code base.
This killed productivity, so management threw resources at it. Code quality dropped further when we were no longer just a group of noobs interesting in hacking on elixir, and became a group of noobs begrudgingly hacking on elixir.
I feel pretty scared from the experience, and wouldn't be interested in using elixir professionally again. Which is a shame, it can be a nice language to write, and some of its tooling like hex is quite nice.
We faced similar issues to you, bad tooling, weak libraries, and very few knowledgeable devs.
Finding people to hack on elixir was extremely difficult, and likely the driving force that killed the project. Having an inexperienced team who had no experience with many of the language features elixir offered created a very difficult to work in code base.
This killed productivity, so management threw resources at it. Code quality dropped further when we were no longer just a group of noobs interesting in hacking on elixir, and became a group of noobs begrudgingly hacking on elixir.
I feel pretty scared from the experience, and wouldn't be interested in using elixir professionally again. Which is a shame, it can be a nice language to write, and some of its tooling like hex is quite nice.
I think new languages wont be able to break in the top 10 without a mega corp pushing them. The market is too saturated and there is a language for everything under the sun. Elixir is just facing too much competition for web stuff and doesnt enjoy Google pushing it.
I don't think it's necessary for a language to be in the top 10 to be considered a success. If the people who use it, wouldn't use anything else, then that is the success.
As long as you're aware that hiring and maintaining will be significantly harder then yes you're right. But that also means there's no reason to choose esoteric tech X for yet another CRUD app; you would pick Erlang/Elixir when it actually makes sense and only then.
> We also found many times missing libraries, or found libraries which are incomplete, or unmaintained or just not well documented
Can you give some examples here. This may have been true in the past, but isn't true anymore. I can give an example where ruby is lacking: Performant HTTP libraries, Elixir and Erlang are so good in this space, look at `finch`, `httpoison` etc,. there is first class support for HTTP2 and connection pooling / persistent connections which is very hard to find in ruby.
> Tooling is just terrible. The VSCode plugin is crap, kills the CPU unless you disable features. There is no IDE from jetbrains. There is a plugin but last time I tried it, it was even worse than the VSCode plugin.
Which plugin are you referring to? Is it using dialyzer? Using dialyzer gives you so much static analysis for free as opposed to the default ruby vscode plugin. I have never heard of complaints about tooling. On the other hand, I know lots of developers who love the tooling, mix is great, iex gives you documentation with just `h String`. Plus with language server support, you have really good IDE support in vscode and vim. Look at the number of stars on the `ElixirLS` plugin here: https://marketplace.visualstudio.com/search?term=elixir&targ...
> Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier. That was our thinking at first. But then you realize on deployments you will lose your cache, or your background jobs, etc.
Yes, you'll lose data in your cache. Caches are supposed to be ephemeral, not everyone needs their caches to be persisted. However, if your use case requires persistence, you have a lot more options than just sticking it in redis. Plus, `oban` is a high quality background processor with persistence, without the need for adding redis to your stack.
For applications where performance matters, Elixir and Erlang give you lots of tools to build a truly performant app, However, if you don't need those tools, you might be better off building it in something more familiar.
Can you give some examples here. This may have been true in the past, but isn't true anymore. I can give an example where ruby is lacking: Performant HTTP libraries, Elixir and Erlang are so good in this space, look at `finch`, `httpoison` etc,. there is first class support for HTTP2 and connection pooling / persistent connections which is very hard to find in ruby.
> Tooling is just terrible. The VSCode plugin is crap, kills the CPU unless you disable features. There is no IDE from jetbrains. There is a plugin but last time I tried it, it was even worse than the VSCode plugin.
Which plugin are you referring to? Is it using dialyzer? Using dialyzer gives you so much static analysis for free as opposed to the default ruby vscode plugin. I have never heard of complaints about tooling. On the other hand, I know lots of developers who love the tooling, mix is great, iex gives you documentation with just `h String`. Plus with language server support, you have really good IDE support in vscode and vim. Look at the number of stars on the `ElixirLS` plugin here: https://marketplace.visualstudio.com/search?term=elixir&targ...
> Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier. That was our thinking at first. But then you realize on deployments you will lose your cache, or your background jobs, etc.
Yes, you'll lose data in your cache. Caches are supposed to be ephemeral, not everyone needs their caches to be persisted. However, if your use case requires persistence, you have a lot more options than just sticking it in redis. Plus, `oban` is a high quality background processor with persistence, without the need for adding redis to your stack.
For applications where performance matters, Elixir and Erlang give you lots of tools to build a truly performant app, However, if you don't need those tools, you might be better off building it in something more familiar.
> Using dialyzer gives you so much static analysis for free as opposed to the default ruby vscode plugin. I have never heard of complaints about tooling.
ctrl-f for "dialyzer" in this thread, and you will :)
ctrl-f for "dialyzer" in this thread, and you will :)
Or peek into my four-year old codebase, and try to give a usefull meaning to the error 'function has no local return' that pops up in dozens of functions which, honest to FSM, have a local return. (The message usually, but not systematically, mean that the function is calling a function that is calling a function that is ..[skip].. calling a function which spec is not exactly respecting the `@spec` comment - because how could it, there is no static type checker ;) ?)
I love Elixir, but even I have to say that the tooling story in IDEs is awful. Using VSCode, ElixirLS is the best extension I've found so far, but even the experience with it makes me want to ditch Elixir entirely more often than not (and no, the number of stars on VSCode marketplace means nothing).
The extension will often just lock up, either giving you no autosuggestions/errors, or refusing to remove errors that you've already resolved, and the only way to fix it reliably is to delete the .elixir_ls/ folder and/or completely close and restart VSCode, both of which require rebuilding the entire dialyzer which is a constant battery killer on laptops. This is such a frequent issue that some days I find myself having to quit/reopen VSCode at least once an hour, and despite spending absurd amounts of time trying to find a long term fix, I've never found one.
Not to mention the issue that has been open for 8+ months where ElixirLS is built using an older version of Elixir, and if you are using a recent version of Elixir for your project (anything newer than 1.9), some of the core functionality of ElixirLS just breaks (autocomplete and hover tips). That issue alone makes me want to ditch ElixirLS (and likely Elixir) entirely.
The extension will often just lock up, either giving you no autosuggestions/errors, or refusing to remove errors that you've already resolved, and the only way to fix it reliably is to delete the .elixir_ls/ folder and/or completely close and restart VSCode, both of which require rebuilding the entire dialyzer which is a constant battery killer on laptops. This is such a frequent issue that some days I find myself having to quit/reopen VSCode at least once an hour, and despite spending absurd amounts of time trying to find a long term fix, I've never found one.
Not to mention the issue that has been open for 8+ months where ElixirLS is built using an older version of Elixir, and if you are using a recent version of Elixir for your project (anything newer than 1.9), some of the core functionality of ElixirLS just breaks (autocomplete and hover tips). That issue alone makes me want to ditch ElixirLS (and likely Elixir) entirely.
The Ruby community is 4x bigger than Elixir and I am being generous to Elixir, and even Ruby is considered smallish.
It astounds me how much I hear about the “VSCode extension uses all my CPU” thing.
Yes, the extension uses a ton of CPU for 15 minutes the first time you set it up. It’s building a giant database for type information to give you type checking and hints.
It does this ONE TIME when you first set it up. It explains this. It’s really not a big deal. I’ve found the extension to be great, I’m not really sure what you are referring to there.
Yes, the extension uses a ton of CPU for 15 minutes the first time you set it up. It’s building a giant database for type information to give you type checking and hints.
It does this ONE TIME when you first set it up. It explains this. It’s really not a big deal. I’ve found the extension to be great, I’m not really sure what you are referring to there.
It isn't just "ONE TIME" for me. The extension freezes up often and completely stops giving autosuggestions or warnings, and the only way to fix it is to delete the .elixir_ls file and rebuild the database. When I say "often", I mean there are some days where I have to do that at least once an hour, and 5-15 minutes of high CPU usage every hour is just way too much to be acceptable.
I love Elixir and the ElixirLS extension is the best I've found so far, but that's not saying much. The extension has enough issues with it to make it very frustrating to work with, and even enough to make the entire Elixir experience not worth it in many cases.
I love Elixir and the ElixirLS extension is the best I've found so far, but that's not saying much. The extension has enough issues with it to make it very frustrating to work with, and even enough to make the entire Elixir experience not worth it in many cases.
Is it possible to share more details about your particular setup? I believe you, but this doesn't sound right. I've used the plugin on all three major operating systems in a wide variety of projects and configurations, and have never had this happen to me. Curious to learn more about what could be the culprit for you.
I have had the same issue as the parent poster. I'm on Windows 10. Everything was fine when I was on Elixir 1.9.2, but the moment I upgraded to 1.11.2, the ElixirLS extension just started to break frequently, or getting stuck while building. I ended up disabling it until I have time to troubleshoot further.
I strongly disagree with your generalisation regarding the tooling: Mix and Hex are without any doubt some of the most pleasant tools I have ever used. (I personally don't care about IDEs so can't comment on the lsp implementation or idea plugins)
In addition to that, I struggled to find a well maintained library similarly to Devise. Also, many people won’t agree to me, but Ecto is also a kind of pain. I think Phoenix would have been in a better position if there were libraries like ActiveRecord and Devise.
Probably there's no one in the Elixir community with enough know how to build a Devise-alike lib, it's what it is.
Here a good blog post on this exact topic
https://dashbit.co/blog/a-new-authentication-solution-for-ph...
https://dashbit.co/blog/a-new-authentication-solution-for-ph...
Jose Valim, the creator and primary author of Elixir, actually wrote Devise.
Is this a joke based on the fact that the same person created Elixir as Devise?
Uh, I shouldn't have to point this out but Elixir was created by the people behind devise...
I've been able to drop in pow with ease and have everything I would have gotten from devise.
That said, the community is moving towards phx_gen_auth which jose himself wrote and will come out of the box with 1.6
That said, the community is moving towards phx_gen_auth which jose himself wrote and will come out of the box with 1.6
I struggled with Ecto. It seemed too complex. I missed find_by_sql and the scopes of ActiveRecord. But once I went past the initial learning curve Ecto is a seriously well designed library. I have not written a single sql query by hand. Now I feel find_by_sql is an anti-pattern as I was mixing sql with ORM.
Once your database becomes sufficiently complex you start writing a lot more sql.
ActiveRecord's way of chaining scopes to combine multiple scopes is brittle. You can't customize the conditions. Ecto solves this by giving you composability. You can build on top of your earlier commands. If you combine this with pattern matching in the functions or Enum.reduce you have an extremely powerful and a flexible query engine.
Ecto also relies on the strengths of underlying database engine rather than treating it as a black box. If you are dealing with 100s of tables Rails way of polymorphic design doesn't give you referential integrity. I like Ecto's recommendations: https://hexdocs.pm/ecto/polymorphic-associations-with-many-t...
Once your database becomes sufficiently complex you start writing a lot more sql.
ActiveRecord's way of chaining scopes to combine multiple scopes is brittle. You can't customize the conditions. Ecto solves this by giving you composability. You can build on top of your earlier commands. If you combine this with pattern matching in the functions or Enum.reduce you have an extremely powerful and a flexible query engine.
Ecto also relies on the strengths of underlying database engine rather than treating it as a black box. If you are dealing with 100s of tables Rails way of polymorphic design doesn't give you referential integrity. I like Ecto's recommendations: https://hexdocs.pm/ecto/polymorphic-associations-with-many-t...
"Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier. That was our thinking at first. But then you realize on deployments you will lose your cache, or your background jobs, etc. So you have to persist them either in mnesia or in the database. At that point you're just reinventing your crappy undocumented and untested version of delayed_job... Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS.... you will need more than 1 server anyway, so..."
I used Erlang for 5-6 years in a production environment in a deployment that wasn't the world's biggest, but did seriously need clustering because we needed more than one machine to handle the load, not just redundancy. This comment leads to my core observation about the entire ecosystem for anyone considering using anything in the Erlang ecosystem.
Erlang started in the late 1990s. Joe Armstrong was brilliant, and I would imagine was also surrounded by some other very smart people whose names I do not know. Despite what I'm about to say, let nothing I say be construed as disrespect for either the language or the people making it.
Let me set some context here. C++ ruled the day, and still looked to inevitably replace all C. Python, Perl, and the entire dynamic scripting language category had just been invented. Java was in the news, but not on your computer yet. Haskell... pre-monadic IO... had just been standardized somewhere in here. Threading was possible but was every bit the nightmare it has been presented as, and you had to be careful spawning more than single-digit threads because of the resource consumption. Open source was just beginning to be A Thing... that is, it had existed in its embryonic form for decades, of course, but it was just beginning to cohere into the Linux world we know now. Machines were still measured in the hundreds of megahertz and the single-digit megabytes of RAM.
Erlang was a far more radical departure from anything else in this era than it is today. There was a lot of academic work on this stuff, and there was a lot of very specialized high-end work on multiprocessing, but it wasn't being done by "mere mortals" and it wasn't very simple. Erlang's designers looked out into the world, and what they saw was a huge jungle, where what maps we had had huge regions that just said "Here There Be Dragons". And they started in, hacking and slashing and slicing their way through, guided by a few intuitions and a whole lot of engineering firepower.
And they largely succeeded in creating a settlement in the wilderness. They grew and managed to pave over the hack & slash paths into roads, built a community, built a pretty incredible VM, built an ecosystem around them. Let this accomplishment not be underestimated; this is a land that had eaten many others in that era.
However, sitting here in 2021, this is no longer a wilderness. Much of the area has been razed, highways driven through it, McDonald's by every exit, and millions of people living here in various bustling metropolises.
And I think what we've found is that where Erlang plopped itself down is OK... but not more than that.
As a consequence of its isolation, Erlang bundles a lot of things into itself that just didn't exist back in the day. It bundles in messaging passing and a network-aware message bus, almost literally decades before anyone else even thought of a "message bus" as a distinct product segment. (i.e., they existed, you could find academic discussion and some early passes at it, but it wasn't really a distinct category yet.) It has a threading environment. It has these "supervision trees" idea which are cool. It has immutability at a time where Haskell was even crazier than it is now. It has a mechanisms for bundling and distributing applications. It has this entire alternate-reality ecosystem in it. But...
... in 2021, none of these are best-of-breed anymore. Many of them are deeply quirky. Immutability is cool, but we only needed to not be able to pass mutable references on the message bus, not be fully immutable within an Erlang process. I believe Elixir fixes this one. A modern message bus going between processes gives you this whether you like it or not because it also can't carry mutable references between OS processes and systems. Having a message bus integrate into the language is a big mistake, because it makes it hard to hook up anything but Erlang nodes to Erlang. (I say "hard" and not "impossible" because I know it can be done, but it's hard.) A modern message bus like Kafka or the dozen other choices doesn't impose an implementation language on you, nor does it impose that implementation language being the only one. Process restarting is a necessity for production-grade systems, but we've settled to a large degree on OS-level handling for restarts, and within a system, there are easier ways to accomplish the goal than bring in the entire Erlang supervision setup. Mnesia, a clustered DB was a neat idea, but in 2021 is so poorly featured and unreliable it doesn't even qualify as one anymore; nobody in their right mind would bring up an Erlang cluster just to back some other language's code to Mnesia as a database. Pattern matching is cool, but not cool enough to justify all the other issues that come with it, and proper use of other language functionality is often good enough anyhow. (I don't tend to miss it; I tend to properly use some form of polymorphism instead. Trivial pattern matching is replaced by this, and to be honest, non-trivial pattern matching is probably a code smell if not an antipattern; if you're reaching three levels down into a data structure, you know too much about that data structure!) Modern Erlang performance is meh; it used to have the clear advantage when dealing with lots of sockets but now there's a lot of things that can comforably exceed it. Its type system is an annoyance even by dynamically-typed standards, if you like static types than just stay away. (They will cite Dialyzer, but it isn't anything remotely resembling a replacement.) And if I reviewed the docs I could find a few more of these, plus I find there's a lot of cases where Erlang has solutions to problems only Erlang has in the first place, e.g., "gen_server" is neat, but the entire gen_server set up, with its initialization phase and its three proscribed ways to call it and the need for an explicit "gen_server" module type are largely the creation of Erlang in the first place... in other languages you generally get the functionality packed up differently but it's all there without having to exactly match what Erlang does.
So, in 2021, the problem is that going into the Erlang ecosystem tends to lock you into a whole package of things that vary from "not best of breed but mostly OK" to "significantly inferior to the modern alternatives". All it really has is very nice integration of its not-best-of-breed stuff, but even that kinda becomes a trap after a while, like when you realize you need a real database after all, then maybe you have to integrate with another message bus so you can integrate with non-Erlang code, and, you know, a couple more cycles around that loop and you'll really regret having chosen Erlang.
One thing that I think it has going for it, and why it's probably still got a cult following today, is that if you're a relatively new developer, or not experienced in network programming, it is a heck of a trip when you get into it, because the tutorial will introduce you to half-a-dozen ideas you've never seen before. Cross-server message buses? Amazing! A network database with an easy API? Amazing! Spawn a million processes on a commodity box? Amazing! I think this explains a lot of the appreciation it gets today. But no longer are any of those things unique. It's just that the normal developer lifecycle will tend to encounter those, one at a time, over the course of years, instead of having them all thrown at you in one amazing, mind-blowing language introduction.
But in 2021, you can do not just "better" than Erlang for all of them, you can do much better. Except that whatever you put together will be something you had to put together, and it won't be quite as nicely integrated. But it will allow for multiple languages, it'll allow you to better integrate with the direction modern ops is going, it'll scale better both internal to your language and in terms of performance, and you'll be better able to hire for it.
The Erlang ecosystem was brilliant and far ahead of its time. I honor it as an incredible pioneer and recommend, even after everything I said, that anybody thinking of writing some incredible new language spend some time in the Erlang ecosystem to see some of what is possible with that sort of integration. But I can't in good conscience recommend it, in either its Erlang flavor or its Elixir flavor (or its Lisp flavor or anything else) to a modern developer. Everything Erlang does is much better done now by other things, minus the language/ecosystem lockin. This is not because Erlang lost, it is because it to a large degree won. It blazed a trail, and we all now agree, it was a trail very worth blazing. But the next waves of settlers & builders ultimately have created something better.
I used Erlang for 5-6 years in a production environment in a deployment that wasn't the world's biggest, but did seriously need clustering because we needed more than one machine to handle the load, not just redundancy. This comment leads to my core observation about the entire ecosystem for anyone considering using anything in the Erlang ecosystem.
Erlang started in the late 1990s. Joe Armstrong was brilliant, and I would imagine was also surrounded by some other very smart people whose names I do not know. Despite what I'm about to say, let nothing I say be construed as disrespect for either the language or the people making it.
Let me set some context here. C++ ruled the day, and still looked to inevitably replace all C. Python, Perl, and the entire dynamic scripting language category had just been invented. Java was in the news, but not on your computer yet. Haskell... pre-monadic IO... had just been standardized somewhere in here. Threading was possible but was every bit the nightmare it has been presented as, and you had to be careful spawning more than single-digit threads because of the resource consumption. Open source was just beginning to be A Thing... that is, it had existed in its embryonic form for decades, of course, but it was just beginning to cohere into the Linux world we know now. Machines were still measured in the hundreds of megahertz and the single-digit megabytes of RAM.
Erlang was a far more radical departure from anything else in this era than it is today. There was a lot of academic work on this stuff, and there was a lot of very specialized high-end work on multiprocessing, but it wasn't being done by "mere mortals" and it wasn't very simple. Erlang's designers looked out into the world, and what they saw was a huge jungle, where what maps we had had huge regions that just said "Here There Be Dragons". And they started in, hacking and slashing and slicing their way through, guided by a few intuitions and a whole lot of engineering firepower.
And they largely succeeded in creating a settlement in the wilderness. They grew and managed to pave over the hack & slash paths into roads, built a community, built a pretty incredible VM, built an ecosystem around them. Let this accomplishment not be underestimated; this is a land that had eaten many others in that era.
However, sitting here in 2021, this is no longer a wilderness. Much of the area has been razed, highways driven through it, McDonald's by every exit, and millions of people living here in various bustling metropolises.
And I think what we've found is that where Erlang plopped itself down is OK... but not more than that.
As a consequence of its isolation, Erlang bundles a lot of things into itself that just didn't exist back in the day. It bundles in messaging passing and a network-aware message bus, almost literally decades before anyone else even thought of a "message bus" as a distinct product segment. (i.e., they existed, you could find academic discussion and some early passes at it, but it wasn't really a distinct category yet.) It has a threading environment. It has these "supervision trees" idea which are cool. It has immutability at a time where Haskell was even crazier than it is now. It has a mechanisms for bundling and distributing applications. It has this entire alternate-reality ecosystem in it. But...
... in 2021, none of these are best-of-breed anymore. Many of them are deeply quirky. Immutability is cool, but we only needed to not be able to pass mutable references on the message bus, not be fully immutable within an Erlang process. I believe Elixir fixes this one. A modern message bus going between processes gives you this whether you like it or not because it also can't carry mutable references between OS processes and systems. Having a message bus integrate into the language is a big mistake, because it makes it hard to hook up anything but Erlang nodes to Erlang. (I say "hard" and not "impossible" because I know it can be done, but it's hard.) A modern message bus like Kafka or the dozen other choices doesn't impose an implementation language on you, nor does it impose that implementation language being the only one. Process restarting is a necessity for production-grade systems, but we've settled to a large degree on OS-level handling for restarts, and within a system, there are easier ways to accomplish the goal than bring in the entire Erlang supervision setup. Mnesia, a clustered DB was a neat idea, but in 2021 is so poorly featured and unreliable it doesn't even qualify as one anymore; nobody in their right mind would bring up an Erlang cluster just to back some other language's code to Mnesia as a database. Pattern matching is cool, but not cool enough to justify all the other issues that come with it, and proper use of other language functionality is often good enough anyhow. (I don't tend to miss it; I tend to properly use some form of polymorphism instead. Trivial pattern matching is replaced by this, and to be honest, non-trivial pattern matching is probably a code smell if not an antipattern; if you're reaching three levels down into a data structure, you know too much about that data structure!) Modern Erlang performance is meh; it used to have the clear advantage when dealing with lots of sockets but now there's a lot of things that can comforably exceed it. Its type system is an annoyance even by dynamically-typed standards, if you like static types than just stay away. (They will cite Dialyzer, but it isn't anything remotely resembling a replacement.) And if I reviewed the docs I could find a few more of these, plus I find there's a lot of cases where Erlang has solutions to problems only Erlang has in the first place, e.g., "gen_server" is neat, but the entire gen_server set up, with its initialization phase and its three proscribed ways to call it and the need for an explicit "gen_server" module type are largely the creation of Erlang in the first place... in other languages you generally get the functionality packed up differently but it's all there without having to exactly match what Erlang does.
So, in 2021, the problem is that going into the Erlang ecosystem tends to lock you into a whole package of things that vary from "not best of breed but mostly OK" to "significantly inferior to the modern alternatives". All it really has is very nice integration of its not-best-of-breed stuff, but even that kinda becomes a trap after a while, like when you realize you need a real database after all, then maybe you have to integrate with another message bus so you can integrate with non-Erlang code, and, you know, a couple more cycles around that loop and you'll really regret having chosen Erlang.
One thing that I think it has going for it, and why it's probably still got a cult following today, is that if you're a relatively new developer, or not experienced in network programming, it is a heck of a trip when you get into it, because the tutorial will introduce you to half-a-dozen ideas you've never seen before. Cross-server message buses? Amazing! A network database with an easy API? Amazing! Spawn a million processes on a commodity box? Amazing! I think this explains a lot of the appreciation it gets today. But no longer are any of those things unique. It's just that the normal developer lifecycle will tend to encounter those, one at a time, over the course of years, instead of having them all thrown at you in one amazing, mind-blowing language introduction.
But in 2021, you can do not just "better" than Erlang for all of them, you can do much better. Except that whatever you put together will be something you had to put together, and it won't be quite as nicely integrated. But it will allow for multiple languages, it'll allow you to better integrate with the direction modern ops is going, it'll scale better both internal to your language and in terms of performance, and you'll be better able to hire for it.
The Erlang ecosystem was brilliant and far ahead of its time. I honor it as an incredible pioneer and recommend, even after everything I said, that anybody thinking of writing some incredible new language spend some time in the Erlang ecosystem to see some of what is possible with that sort of integration. But I can't in good conscience recommend it, in either its Erlang flavor or its Elixir flavor (or its Lisp flavor or anything else) to a modern developer. Everything Erlang does is much better done now by other things, minus the language/ecosystem lockin. This is not because Erlang lost, it is because it to a large degree won. It blazed a trail, and we all now agree, it was a trail very worth blazing. But the next waves of settlers & builders ultimately have created something better.
> But in 2021, you can do not just "better" than Erlang for all of them, you can do much better.
Really appreciate the effort that you've put into this post but it's 99% saying you can do better but without examples of stacks that would be better. For those who don't have your knowledge could you provide some examples?
Really appreciate the effort that you've put into this post but it's 99% saying you can do better but without examples of stacks that would be better. For those who don't have your knowledge could you provide some examples?
The core insight of Erlang is that having lots of little processes communicating over a message bus is a great way to design code. It also proves by demonstration a statement that many programmers, especially in the past decades, would have found hard to believe, that you can structure code as a whole bunch of relatively small self-contained services. Many programmers, perhaps even today, would not believe how far you can get with such a model, thinking that fairly massive monoliths are still really the only way to scale up.
Rather than specific examples, let me provide terms to google, as these are now such rich spaces that even a list of examples would be impoverish. Google "message bus"; there's half-a-dozen solid production options you can deploy yourself, and all the major clouds have at least one option, often more. Pervasively use a message bus in your architecture and you can't hardly help but end up programming in a very Erlang-esque fashion.
"Database"; no longer is an SQL database over a socket your only option. Some databases even combine a bit of message bus functionality, like Redis, or Postgres.
Restarting and reliability: Process-level restarting of much smaller processes has become popular with things like Kubernetes, Docker, and even just plain ol' Systemd. (This is one place that I will assert that systemd is better than the init.d-based system, which had a solid story on how to start processes but a very ad-hoc one on restarting failed processes.) Internally, consult your favorite language for monitors or restarts within a process; I've got one for Go called suture. Getting an idiomatic restart into a language depends on tons of details and I don't have a good sense of the options across dozens of languages. Note this only really matters if your language and program is handling a lot of things at once in a single process, which is not always the case.
That's most of what would matter, I think. Most of the rest of Erlang like "pattern matching", well, do whatever they do in your language. Which may be pattern matching.
Rather than specific examples, let me provide terms to google, as these are now such rich spaces that even a list of examples would be impoverish. Google "message bus"; there's half-a-dozen solid production options you can deploy yourself, and all the major clouds have at least one option, often more. Pervasively use a message bus in your architecture and you can't hardly help but end up programming in a very Erlang-esque fashion.
"Database"; no longer is an SQL database over a socket your only option. Some databases even combine a bit of message bus functionality, like Redis, or Postgres.
Restarting and reliability: Process-level restarting of much smaller processes has become popular with things like Kubernetes, Docker, and even just plain ol' Systemd. (This is one place that I will assert that systemd is better than the init.d-based system, which had a solid story on how to start processes but a very ad-hoc one on restarting failed processes.) Internally, consult your favorite language for monitors or restarts within a process; I've got one for Go called suture. Getting an idiomatic restart into a language depends on tons of details and I don't have a good sense of the options across dozens of languages. Note this only really matters if your language and program is handling a lot of things at once in a single process, which is not always the case.
That's most of what would matter, I think. Most of the rest of Erlang like "pattern matching", well, do whatever they do in your language. Which may be pattern matching.
This comment sold Elixir for me more than anything. On a small team, each of those are massive headaches. Using Elixir I can have all of that with a unified vocabulary, documentation, deployment, syntax, repository, etc. Sure, each might be slightly worse that the best thing on offer today, but I don’t have to glue them together.
And you can swap a built-in feature for an external component later, if the need arises.
Sure, you can achieve what Elixir does by combining a bunch of different components replicating its features, all with their different execution schemes, configuration syntax, deployment constraints. That's the whole point of Elixir, it gives you an integrated environment to do these things with consistent vocabulary, documentation and deployment strategies.
But Erlang provides something that Kubernetes/Docker/Systemd isolation does not: fine granularity / per request isolated processes. Is the difference between a code bug killing a single call in a VoIP system vs killing an entire OS process with hundreds of them.
Do you mean actors? I kinda hate how they’re always referred to as processes.
https://github.com/actix/actix https://github.com/akka/akka
https://github.com/actix/actix https://github.com/akka/akka
The actor terminology isn't used in any official sources since Erlang processes are not quite "actors" in the actor model sense. They were inspired by OS processes.
http://erlang.org/pipermail/erlang-questions/2014-June/07979...
http://erlang.org/pipermail/erlang-questions/2014-June/07979...
Thanks - that's very helpful.
I'm confused by the extent to which you believe the things that Erlang/OTP and the BEAM do have been entirely replicated by other ecosystems. I think you're quite right that distributed systems engineering and threaded programming as a whole has moved in the direction of Erlang on a lot of fronts, but I don't really see the parallels (no pun intended) at the language level. Most popular languages still depend on cooperatively scheduled threading models (even async/await depends on the dev inserting yield points), while the BEAM's does not.
"I'm confused by the extent to which you believe the things that Erlang and OTP and the BEAM do have been entirely replicated by other ecosystems."
One of the reasons I make a bit of an accusation that the people bedazzled by Erlang/Elixir may be not very experienced is that a common take away from the community I have repeatedly noticed is the belief that if another language doesn't have exactly what Erlang has, warts and all, it doesn't have what Erlang has. Thus, I see in many other languages various attempts to port the exact thing Erlang has out into that other language, when in fact the other language already has solutions to that problem, even if they aren't exactly how Erlang solves it. [1]
While I personally exceedingly strongly agree that the Erlang-like threaded approach is vastly superior to manually explaining the asynchronous-ness of your code to the compiler, it still remains the case that "async/await" largely solves the problem of handling millions of threads at a time in those languages that support it, and even if that particular element of it is inferior to Erlang, it will be compensated for by the wide variety of other things that are superior. Just because it isn't exactly like Erlang doesn't mean it's not decent solution. Moreover, my exceedingly strong agreement is also, like, my opinion, man, and there are plenty of people who disagree with me and consider async/await superior, and they would account this as simply being better than Erlang/Elixir.
In the 1990s and the 200Xs, Erlang had solutions to problems that no other language had solutions for, or where Erlang's solutions where clearly head and shoulders above. In 2020s, Erlang no longer has anything that it uniquely has the solution for, even if the exact Erlang solutions don't exist elsewhere.
[1]: I wrote about this recently at https://news.ycombinator.com/item?id=26833616
One of the reasons I make a bit of an accusation that the people bedazzled by Erlang/Elixir may be not very experienced is that a common take away from the community I have repeatedly noticed is the belief that if another language doesn't have exactly what Erlang has, warts and all, it doesn't have what Erlang has. Thus, I see in many other languages various attempts to port the exact thing Erlang has out into that other language, when in fact the other language already has solutions to that problem, even if they aren't exactly how Erlang solves it. [1]
While I personally exceedingly strongly agree that the Erlang-like threaded approach is vastly superior to manually explaining the asynchronous-ness of your code to the compiler, it still remains the case that "async/await" largely solves the problem of handling millions of threads at a time in those languages that support it, and even if that particular element of it is inferior to Erlang, it will be compensated for by the wide variety of other things that are superior. Just because it isn't exactly like Erlang doesn't mean it's not decent solution. Moreover, my exceedingly strong agreement is also, like, my opinion, man, and there are plenty of people who disagree with me and consider async/await superior, and they would account this as simply being better than Erlang/Elixir.
In the 1990s and the 200Xs, Erlang had solutions to problems that no other language had solutions for, or where Erlang's solutions where clearly head and shoulders above. In 2020s, Erlang no longer has anything that it uniquely has the solution for, even if the exact Erlang solutions don't exist elsewhere.
[1]: I wrote about this recently at https://news.ycombinator.com/item?id=26833616
[deleted]
>One of the reasons I make a bit of an accusation that the people bedazzled by Erlang/Elixir may be not very experienced is that a common take away from the community I have repeatedly noticed is the belief that if another language doesn't have exactly what Erlang has, warts and all, it doesn't have what Erlang has.
On one level yes, they have constructs that you can use to accomplish some of the same goals as the tools Erlang provides, but some people (me) like the specific programming model that Erlang provides for dealing with these problems. The concurrency characteristics of the systems I hack on every day would be much harder to model without GenServers. It's not particularly surprising that Erlang is not the only way to solve a problem in software engineering, there is no silver bullet.
I've written much more C# than I have Elixir in my time as a developer and the fact remains that I prefer functional programming and I like using OTP. I don't see what the "wide variety of other things that are superior" are in languages that aren't Erlang. The ecosystem is stronger and the tooling is better, but those are not intrinsic to the design of the language. Tooling kind of is, with static languages, I suppose. Lack of static types are the one thing that bother me a lot about Elixir.
On one level yes, they have constructs that you can use to accomplish some of the same goals as the tools Erlang provides, but some people (me) like the specific programming model that Erlang provides for dealing with these problems. The concurrency characteristics of the systems I hack on every day would be much harder to model without GenServers. It's not particularly surprising that Erlang is not the only way to solve a problem in software engineering, there is no silver bullet.
I've written much more C# than I have Elixir in my time as a developer and the fact remains that I prefer functional programming and I like using OTP. I don't see what the "wide variety of other things that are superior" are in languages that aren't Erlang. The ecosystem is stronger and the tooling is better, but those are not intrinsic to the design of the language. Tooling kind of is, with static languages, I suppose. Lack of static types are the one thing that bother me a lot about Elixir.
"The concurrency characteristics of the systems I hack on every day would be much harder to model without GenServers. It's not particularly surprising that Erlang is not the only way to solve a problem in software engineering, there is no silver bullet."
Erlang was at one point the only way to get this sort of structure, though.
Now it isn't. Multiple languages like Go have lightweight coroutine-y type things; if the isolation isn't perfect, you can fix it with programming discipline. There's also Pony, and Rust which has its own thing which is in its own way far stronger than what Erlang offers. Async/await languages are very amenable to setting up lots of little process-like things, to the point that arguably it's the only sane way to structure your programs in such languages. There is a real change in Erlang being almost the only thing on offer, to merely being one choice of a whole bunch and no longer being impressive enough to justify the lockin. (Not that Erlang uniquely has lock in; all languages have lock simply by virtue of the fact that once code is written in X you can't just change it to Y one day. But it's not worth the lock in anymore.)
Erlang was at one point the only way to get this sort of structure, though.
Now it isn't. Multiple languages like Go have lightweight coroutine-y type things; if the isolation isn't perfect, you can fix it with programming discipline. There's also Pony, and Rust which has its own thing which is in its own way far stronger than what Erlang offers. Async/await languages are very amenable to setting up lots of little process-like things, to the point that arguably it's the only sane way to structure your programs in such languages. There is a real change in Erlang being almost the only thing on offer, to merely being one choice of a whole bunch and no longer being impressive enough to justify the lockin. (Not that Erlang uniquely has lock in; all languages have lock simply by virtue of the fact that once code is written in X you can't just change it to Y one day. But it's not worth the lock in anymore.)
>Erlang was at one point the only way to get this sort of structure, though.
It still is though! Isolated processes with asynchronous, dynamic message passing requires really heavy libraries in most other languages. Rust is completely different, I can't fathom why you'd compare them in this way.
It still is though! Isolated processes with asynchronous, dynamic message passing requires really heavy libraries in most other languages. Rust is completely different, I can't fathom why you'd compare them in this way.
Because as I've said, I'm not comparing solutions, I'm comparing problems. Rust solves the isolation problem in a completely different way. Go also solves the isolation problem by enforcing it at a language community and best practice level, rather than rigidly enforcing it in the language. Now, I personally wish it had something more like Erlang or Pony, but, at the same time... it's doing fine without it and completely satisfying my Erlang use cases in real code, better than Erlang did. Not perfectly, but fine. (I rather prefer channels as a default to Erlang's message passing, which in both my opinion and experience has the "unbounded buffer" problem in that messages can build up in a queue forever.)
Message buses solve the message passing requirement. You can get a whole range of solutions from "just sling vaguely JSON stuff around" to "here's a whole strongly typed protocol", with a whole array of options on persistence, clustering, language support, etc., a whole array of options around how synchronous they are and what guarantees they provide, rather than Erlang's one exact solution,
You're kind of demonstrating my exact point here... it isn't that the exact Erlang solution shows up in other languages, the point is that the problem space that Erlang covers is now covered in plenty of other languages, in all sorts of ways, many of them better for some task than Erlang's one point in the space that was selected very, very early in the exploration process. This was not the case 20 years ago. It is now. And I don't particularly think Erlang's coverings of the problem space are the best. People not already deep into Erlang aren't evaluating whether or not some solution is exactly like Erlang, they're evaluating whether the solution is a good solution on its own terms, and once you remove the "must be exactly like Erlang" clause there are a lot of better choices for every element of Erlang, except arguably, the integration of all of them together.
Message buses solve the message passing requirement. You can get a whole range of solutions from "just sling vaguely JSON stuff around" to "here's a whole strongly typed protocol", with a whole array of options on persistence, clustering, language support, etc., a whole array of options around how synchronous they are and what guarantees they provide, rather than Erlang's one exact solution,
You're kind of demonstrating my exact point here... it isn't that the exact Erlang solution shows up in other languages, the point is that the problem space that Erlang covers is now covered in plenty of other languages, in all sorts of ways, many of them better for some task than Erlang's one point in the space that was selected very, very early in the exploration process. This was not the case 20 years ago. It is now. And I don't particularly think Erlang's coverings of the problem space are the best. People not already deep into Erlang aren't evaluating whether or not some solution is exactly like Erlang, they're evaluating whether the solution is a good solution on its own terms, and once you remove the "must be exactly like Erlang" clause there are a lot of better choices for every element of Erlang, except arguably, the integration of all of them together.
I understand your argument, I guess what I'm trying to say is that I don't think these arguments are unique to Erlang, you could make these arguments about the use of any language to solve almost any problem, outside of kernel programming. I choose tools based on how they fit with how I want to solve problems.
> you can fix it with programming discipline
You can write distributed coroutines in assembly with enough programming discipline. What is interesting in a language is not what it lets you do, it's what it prevents you from doing.
You can write distributed coroutines in assembly with enough programming discipline. What is interesting in a language is not what it lets you do, it's what it prevents you from doing.
> Immutability is cool, but we only needed to not be able to pass mutable references on the message bus, not be fully immutable within an Erlang process. I believe Elixir fixes this one.
In fact Elixir does nothing for this. It is true that in Erlang, you cannot rebind a variable and must use a different variable name for every assignment. In Elixir you can rebind the same variable, but the data is just as immutable as in Erlang, and the rebind is only visible in the current scope, which trips up new programmers not used to it.
In fact Elixir does nothing for this. It is true that in Erlang, you cannot rebind a variable and must use a different variable name for every assignment. In Elixir you can rebind the same variable, but the data is just as immutable as in Erlang, and the rebind is only visible in the current scope, which trips up new programmers not used to it.
Erlang started in the late 80s and saw production use roughly 95
I think that it would be helpful if you provided examples about those things, good and bad. As it is it's mostly "erlang's" bad - perhaps if you offer the counterparts to what would be a better pick we could have a discussion - and then perhaps see how far the tree of dependencies goes on each side? And also what you would loose by picking up those solutions?
Just taking on some random stuff:
> Trivial pattern matching is replaced by this, and to be honest, non-trivial pattern matching is probably a code smell if not an antipattern; if you're reaching three levels down into a data structure
If the data structure is being accessed in a module to deal with it specifically then that is part of the knowledge of the module. And you can't escape that with or without pattern matching, since you'll have to codify those things in code anyway, be it long chains of ifs, switches, or whatever, you'll always have to write the code with the same level of knowledge about the data structure to express the same conditions?
> Modern Erlang performance is meh;
This I'm not sure. I've seen libs written in elixir beat libs written in C++ and they had to start a VM to be run. Obviously there will be plenty of stuff that a low level language can do more efficiently and faster I don't think anyone disagrees with that - but I think sometimes people sell erlang and elixir's speed short.
> but the entire gen_server set up, with its initialization phase and its three proscribed ways to call it and the need for an explicit "gen_server" module type are largely the creation of Erlang in the first place
I haven't seen any language with the concept of an independent program, that has a synchronous interface (mailbox), but can be modelled entirely asynchronously, and can't block whatever running loop. (and I read your other reply and thread). There's also a reason why some things have a particular way of being set up inside the beam, and that's mostly related to the guarantees it provides and with the fact that processes are transparent across nodes. If you take out the impossible to block scheduling and network transparency you'll be of course able to spin up something similar to a GenServer without the same "ritual" - but it no longer has anything to do with the former perhaps except its API?
> A modern message bus like Kafka or the dozen other choices doesn't impose an implementation language on you, nor does it impose that implementation language being the only one.
Given that you can have any socket, tcp or not, and easily handle it, this doesn't seem to be a fair point. On kafka or any other message bus the implementation language will be that of the sources and sinks communicating with kafka? Or you just write kafka and the other programs wake up as insects in a bed?
> Mnesia, a clustered DB was a neat idea, but in 2021 is so poorly featured and unreliable it doesn't even qualify as one anymore; nobody in their right mind would bring up an Erlang cluster just to back some other language's code to Mnesia as a database
I haven't used mnesia at scale and indeed heard people complaining about it, more than once so there's probably some issues there - having said that, in terms of similar db's (KV based and not SQL,etc) even db's like MongoDB and such need expensive and usually paid managing solutions right? And can still loose data unless you really cover your redundancy?
> But in 2021, you can do not just "better" than Erlang for all of them, you can do much better.
Could you tell us succinctly how? As a, usually, solo developer I would be really interested in knowing, and I'm not asking sarcastically.
I also don't understand how it's difficult to integrate Erlang with other things, it basically has a standard lib very accommodating of sockets and inter process communication through STDIN/OUT, with effective monitoring on top.
Just taking on some random stuff:
> Trivial pattern matching is replaced by this, and to be honest, non-trivial pattern matching is probably a code smell if not an antipattern; if you're reaching three levels down into a data structure
If the data structure is being accessed in a module to deal with it specifically then that is part of the knowledge of the module. And you can't escape that with or without pattern matching, since you'll have to codify those things in code anyway, be it long chains of ifs, switches, or whatever, you'll always have to write the code with the same level of knowledge about the data structure to express the same conditions?
> Modern Erlang performance is meh;
This I'm not sure. I've seen libs written in elixir beat libs written in C++ and they had to start a VM to be run. Obviously there will be plenty of stuff that a low level language can do more efficiently and faster I don't think anyone disagrees with that - but I think sometimes people sell erlang and elixir's speed short.
> but the entire gen_server set up, with its initialization phase and its three proscribed ways to call it and the need for an explicit "gen_server" module type are largely the creation of Erlang in the first place
I haven't seen any language with the concept of an independent program, that has a synchronous interface (mailbox), but can be modelled entirely asynchronously, and can't block whatever running loop. (and I read your other reply and thread). There's also a reason why some things have a particular way of being set up inside the beam, and that's mostly related to the guarantees it provides and with the fact that processes are transparent across nodes. If you take out the impossible to block scheduling and network transparency you'll be of course able to spin up something similar to a GenServer without the same "ritual" - but it no longer has anything to do with the former perhaps except its API?
> A modern message bus like Kafka or the dozen other choices doesn't impose an implementation language on you, nor does it impose that implementation language being the only one.
Given that you can have any socket, tcp or not, and easily handle it, this doesn't seem to be a fair point. On kafka or any other message bus the implementation language will be that of the sources and sinks communicating with kafka? Or you just write kafka and the other programs wake up as insects in a bed?
> Mnesia, a clustered DB was a neat idea, but in 2021 is so poorly featured and unreliable it doesn't even qualify as one anymore; nobody in their right mind would bring up an Erlang cluster just to back some other language's code to Mnesia as a database
I haven't used mnesia at scale and indeed heard people complaining about it, more than once so there's probably some issues there - having said that, in terms of similar db's (KV based and not SQL,etc) even db's like MongoDB and such need expensive and usually paid managing solutions right? And can still loose data unless you really cover your redundancy?
> But in 2021, you can do not just "better" than Erlang for all of them, you can do much better.
Could you tell us succinctly how? As a, usually, solo developer I would be really interested in knowing, and I'm not asking sarcastically.
I also don't understand how it's difficult to integrate Erlang with other things, it basically has a standard lib very accommodating of sockets and inter process communication through STDIN/OUT, with effective monitoring on top.
"If the data structure is being accessed in a module to deal with it specifically then that is part of the knowledge of the module. And you can't escape that with or without pattern matching, since you'll have to codify those things in code anyway, be it long chains of ifs, switches, or whatever, you'll always have to write the code with the same level of knowledge about the data structure to express the same conditions?"
There are other options. In object oriented design, using the loose definition of "anything with 'methods'" (thus, including Go and Javascript even if they don't have "inheritance"), if you want to know something, you ask directly, using a method for that case. It is the difference between "account.getBill(lastMonth)", where you load the logic into the account object to fetch bills from different times, and pattern matching where you write into the code taking the bill deep assumptions about how the account is structured, such that when refactoring the account you have to go change all its consumers. Note I am only criticizing deep pattern matching here; pattern matching in general I like, even if I can live without, but in Erlang terms, if your patterns look like
"I've seen libs written in elixir beat libs written in C++ and they had to start a VM to be run. "
There's almost always some microbenchmark a slow language can beat a fast language in, but that doesn't make it a fast language. You might want to dig into that "elixir lib that beats C++", because either the C++ was really bad or the elixir lib is actually written mostly in C(++).
"I haven't seen any language with the concept of an independent program, that has a synchronous interface (mailbox), but can be modelled entirely asynchronously, and can't block whatever running loop."
Yeah, but when you're talking about a 30-40 year programming language, that's not a necessarily a compliment. Nobody else has seen fit to exactly copy it, because we've found better things to cover the problem space than that.
"Given that you can have any socket, tcp or not, and easily handle it"
There is a lot more to being a message bus than just having a TCP socket.
"I also don't understand how it's difficult to integrate Erlang with other things, it basically has a standard lib very accommodating of sockets and inter process communication through STDIN/OUT, with effective monitoring on top."
That is not "easy to integrate with", that's table stakes. What I'm referring to being hard to integrate with is how you tend to be stuck in the ecosystem. It has monitoring, sure... but in 2021 it's a very quirky monitoring that doesn't integrate with any of the rest of what has developed. You can, in theory, connect to an Erlang cluster without Erlang, but in practice the requirements of being "an Erlang cluster" are so specific, with its own quirky term format that isn't quite JSON or quite anything else, is so difficult as to not be worthwhile. Once you've taken the time to speak to a non-Erlang message bus, use a non-Erlang database, wrap your Erlang code in K8S or some non-Erlang manager, use Erlang to hit HTTP APIs, speak to non-Erlang monitoring systems... why are we using Erlang again?
There are other options. In object oriented design, using the loose definition of "anything with 'methods'" (thus, including Go and Javascript even if they don't have "inheritance"), if you want to know something, you ask directly, using a method for that case. It is the difference between "account.getBill(lastMonth)", where you load the logic into the account object to fetch bills from different times, and pattern matching where you write into the code taking the bill deep assumptions about how the account is structured, such that when refactoring the account you have to go change all its consumers. Note I am only criticizing deep pattern matching here; pattern matching in general I like, even if I can live without, but in Erlang terms, if your patterns look like
[thing, [_, _, {something, X, [Y, _, Z]}]]
"I've seen libs written in elixir beat libs written in C++ and they had to start a VM to be run. "
There's almost always some microbenchmark a slow language can beat a fast language in, but that doesn't make it a fast language. You might want to dig into that "elixir lib that beats C++", because either the C++ was really bad or the elixir lib is actually written mostly in C(++).
"I haven't seen any language with the concept of an independent program, that has a synchronous interface (mailbox), but can be modelled entirely asynchronously, and can't block whatever running loop."
Yeah, but when you're talking about a 30-40 year programming language, that's not a necessarily a compliment. Nobody else has seen fit to exactly copy it, because we've found better things to cover the problem space than that.
"Given that you can have any socket, tcp or not, and easily handle it"
There is a lot more to being a message bus than just having a TCP socket.
"I also don't understand how it's difficult to integrate Erlang with other things, it basically has a standard lib very accommodating of sockets and inter process communication through STDIN/OUT, with effective monitoring on top."
That is not "easy to integrate with", that's table stakes. What I'm referring to being hard to integrate with is how you tend to be stuck in the ecosystem. It has monitoring, sure... but in 2021 it's a very quirky monitoring that doesn't integrate with any of the rest of what has developed. You can, in theory, connect to an Erlang cluster without Erlang, but in practice the requirements of being "an Erlang cluster" are so specific, with its own quirky term format that isn't quite JSON or quite anything else, is so difficult as to not be worthwhile. Once you've taken the time to speak to a non-Erlang message bus, use a non-Erlang database, wrap your Erlang code in K8S or some non-Erlang manager, use Erlang to hit HTTP APIs, speak to non-Erlang monitoring systems... why are we using Erlang again?
I still don't understand the point about the deep pattern matching. In OOP you'll have an object that encapsulates all that knowledge, and in functional programming you'll have a module that encapsulates all that knowledge, clients of both the object in OOP and clients of the data structure in FP will need to have the same knowledge to deal with it - once you need to serialise the information. I just don't find the argument compelling, in my reading it would be akin to saying, it's a code smell a class has all this implicit knowledge of the object it's modelling (assuming the deep pattern matching in the module dealing with transforming it).
> There's almost always some microbenchmark a slow language can beat a fast language in, but that doesn't make it a fast language. You might want to dig into that "elixir lib that beats C++", because either the C++ was really bad or the elixir lib is actually written mostly in C(++).
Usually it's microbenchmarking that doesn't flatter elixir/erlang - and stampede problems where you can get away with just brute forcing - eg. parsing directly to output a bunch of files where the output is a file(s) - but there, if you want then to build usable metadata through all of it things change fast - writing a correct program in any of the fast languages that has the same ergos for keeping usable information throughout and is at the same time easily changeable, can interleave information in parallel with pretty amazing monitoring, and doesn't require years of training, is quite a different thing.
I know it doesn't use C++ because I wrote it and I know how much more it does as well, though I'm not here to convince you.
> Yeah, but when you're talking about a 30-40 year programming language, that's not a necessarily a compliment. Nobody else has seen fit to exactly copy it, because we've found better things to cover the problem space than that.
Well, sure, I just think it should not be written as "cover" the problem space, is more "making holes" in the problem space.
> There is a lot more to being a message bus than just having a TCP socket.
Given that your argument was:
> A modern message bus like Kafka or the dozen other choices doesn't impose an implementation language on you, nor does it impose that implementation language being the only one
I'm not sure there's any more esperanto than tcp/sockets, which comparing to any other language are a joy to write, use, monitor, and deal with.
> You can, in theory, connect to an Erlang cluster without Erlang, but in practice the requirements of being "an Erlang cluster" are so specific
This sincerely... How do you connect to other clusters in other languages (if they're even able to set up meshes)? You don't. How do you solve it? With clustering solutions. How is it that a runtime that can be put inside those same clustering solutions, by the same process, but has a zillion more functionality can be worse than those other solutions regarding that?
> Once you've taken the time to speak to a non-Erlang message bus, use a non-Erlang database, wrap your Erlang code in K8S or some non-Erlang manager, use Erlang to hit HTTP APIs, speak to non-Erlang monitoring systems... why are we using Erlang again?
Yeah, because they all speak something else than http/tcp and we know erlang is not really made for handling sockets and can't do http.post().
> There's almost always some microbenchmark a slow language can beat a fast language in, but that doesn't make it a fast language. You might want to dig into that "elixir lib that beats C++", because either the C++ was really bad or the elixir lib is actually written mostly in C(++).
Usually it's microbenchmarking that doesn't flatter elixir/erlang - and stampede problems where you can get away with just brute forcing - eg. parsing directly to output a bunch of files where the output is a file(s) - but there, if you want then to build usable metadata through all of it things change fast - writing a correct program in any of the fast languages that has the same ergos for keeping usable information throughout and is at the same time easily changeable, can interleave information in parallel with pretty amazing monitoring, and doesn't require years of training, is quite a different thing.
I know it doesn't use C++ because I wrote it and I know how much more it does as well, though I'm not here to convince you.
> Yeah, but when you're talking about a 30-40 year programming language, that's not a necessarily a compliment. Nobody else has seen fit to exactly copy it, because we've found better things to cover the problem space than that.
Well, sure, I just think it should not be written as "cover" the problem space, is more "making holes" in the problem space.
> There is a lot more to being a message bus than just having a TCP socket.
Given that your argument was:
> A modern message bus like Kafka or the dozen other choices doesn't impose an implementation language on you, nor does it impose that implementation language being the only one
I'm not sure there's any more esperanto than tcp/sockets, which comparing to any other language are a joy to write, use, monitor, and deal with.
> You can, in theory, connect to an Erlang cluster without Erlang, but in practice the requirements of being "an Erlang cluster" are so specific
This sincerely... How do you connect to other clusters in other languages (if they're even able to set up meshes)? You don't. How do you solve it? With clustering solutions. How is it that a runtime that can be put inside those same clustering solutions, by the same process, but has a zillion more functionality can be worse than those other solutions regarding that?
> Once you've taken the time to speak to a non-Erlang message bus, use a non-Erlang database, wrap your Erlang code in K8S or some non-Erlang manager, use Erlang to hit HTTP APIs, speak to non-Erlang monitoring systems... why are we using Erlang again?
Yeah, because they all speak something else than http/tcp and we know erlang is not really made for handling sockets and can't do http.post().
Can't upvote this enough
> Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS.... you will need more than 1 server anyway, so...
Yeah, last time I tried to get a hang in Erlang I felt it was trying to solve stuff that is already being solved by my infrastructure in a language agnostic way.
Yeah, last time I tried to get a hang in Erlang I felt it was trying to solve stuff that is already being solved by my infrastructure in a language agnostic way.
I'd say it's rather the other way around. Your infrastructure now solves what Erlang did 25 years ago.
Not to argue your point, though.
Not to argue your point, though.
they are not the same kind of concurrency model though
"There is no IDE from jetbrains"
Is that now a thing that is important? I've only just started using an IDE from them - and I don't see how it's miles better than say vscode?
This whole thing sounds very much "ruby good, elixir bad"
This whole thing sounds very much "ruby good, elixir bad"
> Tooling is just terrible. The VSCode plugin is crap, kills the CPU unless you disable features. There is no IDE from jetbrains. There is a plugin but last time I tried it, it was even worse than the VSCode plugin.
That's my main blocker, proper JetBrains IDE support just makes everything so much easier. I need a debugger.
I tried the plug-in, and kudos to the author but it did not work for me. In the end they're only one person so of course they could not test every single configuration
-
I wonder why JetBrains has not put their weight behind it.
That's my main blocker, proper JetBrains IDE support just makes everything so much easier. I need a debugger.
I tried the plug-in, and kudos to the author but it did not work for me. In the end they're only one person so of course they could not test every single configuration
-
I wonder why JetBrains has not put their weight behind it.
Rails is very productive but it has problems of its own. Many companies move away from Rails once they reach certain growth milestones.
Erlang (and by extension Elixir) is a concurrent language. You use it when you have non-trivial concurrency challenges. When tackling the right problems, the language shines.
Implementing a simple CRUD application with Elixir is overkill, because you can make your servers stateless and delegate most of the concurrency problems to the database.
Erlang (and by extension Elixir) is a concurrent language. You use it when you have non-trivial concurrency challenges. When tackling the right problems, the language shines.
Implementing a simple CRUD application with Elixir is overkill, because you can make your servers stateless and delegate most of the concurrency problems to the database.
In my personal experience (the last bunch of companies I've been at) that milestone you mention is more like what is the current fashion and what the new hires want to work on because of the latest blog post they've read.
At my previous job we had *ALL* of them. Each service or project you opened you could guess the date it was started because of how it was built. Rails -> Node -> Elixir -> Go -> Next.js and the frontend backbone -> ember -> react (redux -> mobx -> rxjs -> [some other random state lib] -> just context! -> recoil) -> typescript and probably by now they're already using whatever the new trend is by this morning. It is insane.
None of the companies needed any of the performance provided by this tools, in fact, they all struggle with developer productivity more than any other metric, and every time they switch to the new shiny toy, productivity takes another huge cut. But hey, people get paid anyway at the end of the month, so let's keep playing.
At my previous job we had *ALL* of them. Each service or project you opened you could guess the date it was started because of how it was built. Rails -> Node -> Elixir -> Go -> Next.js and the frontend backbone -> ember -> react (redux -> mobx -> rxjs -> [some other random state lib] -> just context! -> recoil) -> typescript and probably by now they're already using whatever the new trend is by this morning. It is insane.
None of the companies needed any of the performance provided by this tools, in fact, they all struggle with developer productivity more than any other metric, and every time they switch to the new shiny toy, productivity takes another huge cut. But hey, people get paid anyway at the end of the month, so let's keep playing.
The CTO should be fired, what the hell.
In fact maybe we should start naming the companies (not the CTOs I will respect their privacy) so we can know where NOT to work.
Next.js is node-based.
I really don't see any reason to move from Rails other than a new CTO trying to shake things up with a tech he's more familiar with.
If Shopify/Github/Gitlab/ can build it on Rails so can you. If the monolith is too big you can break it down with engines or to separate apps.
Now I like Rails but I would say the same about PHP/Node or most popular stacks. Rewrites to another language are almost always unnecessary.
For many years Github ran on a fork of Ruby and a fork of Rails. Recently they upgraded to Ruby 2.7 and that's what they use now.
https://github.blog/2020-08-25-upgrading-github-to-ruby-2-7/
https://github.blog/2020-08-25-upgrading-github-to-ruby-2-7/
It says right in your link "Many years ago, we ran GitHub on a fork of Ruby (and Rails!) and while that hasn’t been the case for some time".
So that was a long time ago, what is your point?
Just on the hiring point. There are three companies to my knowledge using Elixir in Toronto. I applied at two and the responses were 1. Not enough professional experience using the language. 2. Very low salary expectations on their end. Pretty bad for Toronto but especially poor for hiring in what is essentially a niche language.
Rails is awesome nothing comes close to being as fun and productive. Tried php and django, not bad but not Rails.
Can't agree more with this. I've used both, Rails since a few years ago and Django for about 8 years or so, and while I still like Django I think rails is far, far superior in every aspect. The only thing I like more from django is the migrations system (not even the ORM, just the migrations) and maybe the admin as a tool to browse the database. Other than that, Rails all day.
Yes the Django admin was cool, the Rails core team didnt want to bring something similar to Rails for reasons I dont quite remember..maybe its a shame
Have you tried Laravel?
Asking because I'm just curious about the comparison between the two
Asking because I'm just curious about the comparison between the two
A bit, its ok. Im just a sucker for the combination between ruby and rails. php wont do it for me, but its a solid language.
ah, well, another ruby or python enthusiast trying to avoid other models of concurrency at all costs
oh boy. where to begin
> We built a few services
So you never really committed to it in the first place. Also, this complicates the deployment problem.
> after a few years some of the original people that introduced it left the company
Probably left for a company that actually committed to Elixir. :P
> and it became very difficult to hire for
In a world where everyone is remote and where 10 Elixir people apply to every job, this product must have been pretty unappealing
> New hires were either people wanting to learn (so we had to spend a good bunch of resources into teaching + end up with a system built by noobs to the language) or very expensive developers with a lot of experience in erlang and elixir.
"We didn't want to pay employees their worth and instead bitched about what we couldn't get without hiring those employees"
(Why couldn't you hire an assortment? One experienced guy and a couple noobs?)
> We also found many times missing libraries, or found libraries which are incomplete, or unmaintained or just not well documented
Alright, fine. Sometimes you have to "roll your own" in this space, still.
> Tooling is just terrible. The VSCode plugin is crap
You should not use the word "tooling" here because VSCode is not an IDE, Elixir should not require an IDE, and moreover, Elixir should not be judged because "there is no good IDE for Elixir". "Tooling" should refer to the support libs and tools that ship with the language, all of which are excellent.
> At that point you're just reinventing your crappy undocumented and untested version of delayed_job.
Spotted the guy who never heard of Oban https://github.com/sorentwo/oban Benefit of the doubt: Perhaps it didn't exist yet.
> Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS
This is entirely missing the point. If a bug or runtime error crashes your Ruby interpreter, you better have another one ready to go from a pool (because Rails stacks can take a while to load), and then you better not exhaust that pool! If such an error crashes Elixir, it just restarts the process, which only takes a millisecond because forking an immutable language's state is trivial compared to a mutable language's state.
> Liveview
I actually haven't played with it much yet so can't comment
> In the end, we are back to Rails and much happier
"We can underpay cheap devs again"
You also repurchased entire classes of bugs that are impossible in Elixir such as: mutation bugs, monkeypatch bugs, and concurrency bugs (just forget running your test suites in parallel). Also, these are literally the hardest types of bugs to fix (nondeterministic behavior), and will likely cost you more in the long run than any differential salary you balked at (I have spent entire months debugging something in the Ruby space, you'll remember my comment once this bites you in the *** one day).
> We built a few services
So you never really committed to it in the first place. Also, this complicates the deployment problem.
> after a few years some of the original people that introduced it left the company
Probably left for a company that actually committed to Elixir. :P
> and it became very difficult to hire for
In a world where everyone is remote and where 10 Elixir people apply to every job, this product must have been pretty unappealing
> New hires were either people wanting to learn (so we had to spend a good bunch of resources into teaching + end up with a system built by noobs to the language) or very expensive developers with a lot of experience in erlang and elixir.
"We didn't want to pay employees their worth and instead bitched about what we couldn't get without hiring those employees"
(Why couldn't you hire an assortment? One experienced guy and a couple noobs?)
> We also found many times missing libraries, or found libraries which are incomplete, or unmaintained or just not well documented
Alright, fine. Sometimes you have to "roll your own" in this space, still.
> Tooling is just terrible. The VSCode plugin is crap
You should not use the word "tooling" here because VSCode is not an IDE, Elixir should not require an IDE, and moreover, Elixir should not be judged because "there is no good IDE for Elixir". "Tooling" should refer to the support libs and tools that ship with the language, all of which are excellent.
> At that point you're just reinventing your crappy undocumented and untested version of delayed_job.
Spotted the guy who never heard of Oban https://github.com/sorentwo/oban Benefit of the doubt: Perhaps it didn't exist yet.
> Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS
This is entirely missing the point. If a bug or runtime error crashes your Ruby interpreter, you better have another one ready to go from a pool (because Rails stacks can take a while to load), and then you better not exhaust that pool! If such an error crashes Elixir, it just restarts the process, which only takes a millisecond because forking an immutable language's state is trivial compared to a mutable language's state.
> Liveview
I actually haven't played with it much yet so can't comment
> In the end, we are back to Rails and much happier
"We can underpay cheap devs again"
You also repurchased entire classes of bugs that are impossible in Elixir such as: mutation bugs, monkeypatch bugs, and concurrency bugs (just forget running your test suites in parallel). Also, these are literally the hardest types of bugs to fix (nondeterministic behavior), and will likely cost you more in the long run than any differential salary you balked at (I have spent entire months debugging something in the Ruby space, you'll remember my comment once this bites you in the *** one day).
> In a world where everyone is remote and where 10 Elixir people apply to every job, this product must have been pretty unappealing
That's really inaccurate, not everyone is remote and looks like post COVID most companies will be hybrid office/remote. So hiring is still a problem, and getting hired is a problem for people who don't want to be 100% remote.
> "We can underpay cheap devs again"
I don't think Rails devs are particularly cheap though I'm not sure if that's what you meant.
> mutation bugs, monkeypatch bugs, and concurrency bugs (just forget running your test suites in parallel)
Rails comes with parallel testing since Rails 6. As for concurrency - I know that Gitlab moved to Puma (a threaded webserver) and tons of huge companies use Sidekiq which is threaded as well. I'm not saying there are never any problems but it seems to work well for many many companies.
That's really inaccurate, not everyone is remote and looks like post COVID most companies will be hybrid office/remote. So hiring is still a problem, and getting hired is a problem for people who don't want to be 100% remote.
> "We can underpay cheap devs again"
I don't think Rails devs are particularly cheap though I'm not sure if that's what you meant.
> mutation bugs, monkeypatch bugs, and concurrency bugs (just forget running your test suites in parallel)
Rails comes with parallel testing since Rails 6. As for concurrency - I know that Gitlab moved to Puma (a threaded webserver) and tons of huge companies use Sidekiq which is threaded as well. I'm not saying there are never any problems but it seems to work well for many many companies.
I’m sitting in Africa and I can whisper “Elixir job” out my bathroom window and have 10 people interested in it. Maybe it used to be difficult.
Can you name a few of the libraries you didn't find?
Erlang and Elixir ecosystem has a bunch of unmaintained throw-away projects.
I wrote a bunch of Erlang and Elixir tooling before I realized the most useful projects were thrown over the wall FOSS codebases.
If it's stupid and it works, it's not stupid. Fashionable is for runway models.
I wrote a bunch of Erlang and Elixir tooling before I realized the most useful projects were thrown over the wall FOSS codebases.
If it's stupid and it works, it's not stupid. Fashionable is for runway models.
I'm at a relatively early stage VC-backed startup and from day 1 it's been written in Elixir. It was a fantastic choice, for many reasons, with some being:
- Elixir is good for just getting stuff done. I came from a previous startup that used Go and Elm.
- The community isn't as small as people make it out to be, or, it's quality over quantity. ;)
- There's a lot of good modules out there, and if you need to write your own, it's easy and there's well-defined patterns. E.g. I recently improved our internal Zendesk client and it was a breeze.
- https://dashbit.co/ for paid support/advice is amazing.
- The console for experimentation, debugging, inspection, etc. is fantastic.
- The let it crash, and other Elixir/Erlang philosophies, have been very helpful.
- There's a solid amount of batteries-included, but not in an overbearing/restrictive way.
- It's such a pleasant day-to-day dev experience.
I didn't know Elixir before joining this startup. For myself, and workmates who also didn't have prior experience, it's been a breeze to get up to speed in.
- Elixir is good for just getting stuff done. I came from a previous startup that used Go and Elm.
- The community isn't as small as people make it out to be, or, it's quality over quantity. ;)
- There's a lot of good modules out there, and if you need to write your own, it's easy and there's well-defined patterns. E.g. I recently improved our internal Zendesk client and it was a breeze.
- https://dashbit.co/ for paid support/advice is amazing.
- The console for experimentation, debugging, inspection, etc. is fantastic.
- The let it crash, and other Elixir/Erlang philosophies, have been very helpful.
- There's a solid amount of batteries-included, but not in an overbearing/restrictive way.
- It's such a pleasant day-to-day dev experience.
I didn't know Elixir before joining this startup. For myself, and workmates who also didn't have prior experience, it's been a breeze to get up to speed in.
I see that you're hiring. Are the positions remote as well or strictly London?
Admittedly it's more or less London-based at the moment, unfortunately! Which timezone are you in?
Currently, with summertime, it would be GMT+2. Not far from UK, CZ :)
I'd say reach out, with the likely caveat that the response may be non-remote for now (I personally fully support remote work). We could hopefully reach out in the future too?
We're hiring in CZ :)
It's not argument "against" selecting it (it's a free world, and mileage vary), but a couple of scar-earned advice:
- Be careful about libraries. If you know that your system has to interact with X, don't assume that there is a running, idiomatic, maintained libary for X on `hex.pm`. Do a bit of due diligence. We had experience ranging from `meeh` (oauth2, graphql, http) to `pretty bad` (mqtt, swagger.)
But as other say, if you're doing vanilla Phoenix/Plug/Ecto with exactly the right kind of DB, you'll should be ok.
- Give a little though about how you'll be deploying and operating. `releases` and `configuration` haved changed in pretty big ways in the past (https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...), the ecosystem is constantly in flux (`config.exs` vs `Application.get_env` vs ENV_VAR vs..) . Plus, the erlang virtual machine (BEAM) has knobs that are not always easy to play with. And if you hide it behind, say, docker containers, you'll have other troubles. Don't expect an `heroku do-some-magic` experience.
- Unless you're familiar with the Actor Model already, and your application is very simple, expect a learning curve made of:
- Be careful about libraries. If you know that your system has to interact with X, don't assume that there is a running, idiomatic, maintained libary for X on `hex.pm`. Do a bit of due diligence. We had experience ranging from `meeh` (oauth2, graphql, http) to `pretty bad` (mqtt, swagger.)
But as other say, if you're doing vanilla Phoenix/Plug/Ecto with exactly the right kind of DB, you'll should be ok.
- Give a little though about how you'll be deploying and operating. `releases` and `configuration` haved changed in pretty big ways in the past (https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...), the ecosystem is constantly in flux (`config.exs` vs `Application.get_env` vs ENV_VAR vs..) . Plus, the erlang virtual machine (BEAM) has knobs that are not always easy to play with. And if you hide it behind, say, docker containers, you'll have other troubles. Don't expect an `heroku do-some-magic` experience.
- Unless you're familiar with the Actor Model already, and your application is very simple, expect a learning curve made of:
1. A period where you're afraid of GenServer and fail to do anything because you don't want to create a supervision tree
2. A period where you think you've understood GenServers and you create GenServers like crazy
3. A sobering period where you don't understand anything about your application
4. A couple of refactorings where you move the pendulum until you reach something that's acceptable
If you're aching for typespecs in Elixir being useful, but are dissapointed with Dialyzer, I recommend checking out my library Hammox: https://github.com/msz/hammox. It's an improved version of Mox, the de-facto mocking library for Elixir, which you can use to automatically assert in tests that your mock calls, or any function calls, fit your typespecs.
I personally found that with rigorous enough usage, I don't even miss having actual static typing anymore ;)
I personally found that with rigorous enough usage, I don't even miss having actual static typing anymore ;)
This is great! Thanks for sharing.
What you said about releases is somewhat true, but I’d like to clarify.
It has absolutely changed a decent amount over the last few years. Because it used to suck. It’s not really in flux, more like being improved because everyone knew it sucked. It’s in a much better state now and I’m very happy with it where I wasn’t before.
Also, I would say that “in flux” isn’t a proper characterization because it was always backwards compatible. Nothing broke, they just improved the experience through better methods.
It has absolutely changed a decent amount over the last few years. Because it used to suck. It’s not really in flux, more like being improved because everyone knew it sucked. It’s in a much better state now and I’m very happy with it where I wasn’t before.
Also, I would say that “in flux” isn’t a proper characterization because it was always backwards compatible. Nothing broke, they just improved the experience through better methods.
Fair enough. I just haven't fully recovered from the PTSD of "deploying something that reads environment variables at startup" four years ago.
Absolutely feel that. The `runtime.exs` config that they added a while ago has been an absolute godsend and really fixed 90% of my complaints with deployment. It unified all config for deployments and development and made it all runtime!
Interesting, some of the libraries you mention such as graphql and http, I feel there aren't better libs that exist than absinthe and ranch/cowboy.
Which graphql library do you prefer over absinthe in other ecosystems?
Which graphql library do you prefer over absinthe in other ecosystems?
From what we understood (back when we shopped for a lib, which was a long time ago), absinthe advertised itself a lib to write graphql servers ; we were looking for a graphql client,so we ended up using a smaller lib.
(And it's entirely possible that we simply picked the wrong lib ! Which is, still, kinda my point. Every elixir lib is "young" by virtue of the language being "young", so you can't use "age" as a heuristic for being the "right" lib. Happens for all"young" ecosystem,so not particular to ex.)
(And it's entirely possible that we simply picked the wrong lib ! Which is, still, kinda my point. Every elixir lib is "young" by virtue of the language being "young", so you can't use "age" as a heuristic for being the "right" lib. Happens for all"young" ecosystem,so not particular to ex.)
> absinthe advertised itself a lib to write graphql servers ; we were looking for a graphql client
> And it's entirely possible that we simply picked the wrong lib !
This is 100% a failure of a decision-making process, not the language ecosystem. Picking the wrong library could be avoided by the smallest amount of diligence, it's pretty language agnostic.
> And it's entirely possible that we simply picked the wrong lib !
This is 100% a failure of a decision-making process, not the language ecosystem. Picking the wrong library could be avoided by the smallest amount of diligence, it's pretty language agnostic.
Nice points indeed!
I would also say that the "library" one is basically valid for every language. In general is always a good thing to spend some time analyzing the possibilities before importing an external lib into your application.
I would also say that the "library" one is basically valid for every language. In general is always a good thing to spend some time analyzing the possibilities before importing an external lib into your application.
I literally have a Simpsons-Mendoza meme printed out on my desk, except instead of "MENDOZAAAAAA", McBain is screaming "DIALYZEEEEER".
What a god-awful piece of software.
What a god-awful piece of software.
I’m very satisfied with Elixir. I, a longtime Ruby on Rails developer, learned Elixir on the job at CityBase and have been thrilled with it every day.
The first thing that tripped me up with Elixir is the difference between single quoted and double quoted strings. They’re different data types!
Most of the work I’ve done has been writing JSON or GraphQL apis that react apps consume. We’re about to start using Phoenix LiveView.
I like using Phoenix + Ecto. It’s lightweight and very fast. I learned Ruby through my work with Rails, and I did not have the same experience with Phoenix. And that’s for the better.
Deployment-wise, we moved from Edeliver to Kubernetes and it’s worked great.
I need to figure out the right editor experience for NeoVim, I haven’t gotten an LSP to work just right. Sometimes Dialyzer is a pain in the ass. Also, I’ve had some issues installing erlang via ASDF lately and sometimes I’ve had to use homebrew symlinks to skip that problem.
I recommend that OP give Elixir a shot and see what you think. There’s also very nice community on the Elixir language slack server.
The first thing that tripped me up with Elixir is the difference between single quoted and double quoted strings. They’re different data types!
Most of the work I’ve done has been writing JSON or GraphQL apis that react apps consume. We’re about to start using Phoenix LiveView.
I like using Phoenix + Ecto. It’s lightweight and very fast. I learned Ruby through my work with Rails, and I did not have the same experience with Phoenix. And that’s for the better.
Deployment-wise, we moved from Edeliver to Kubernetes and it’s worked great.
I need to figure out the right editor experience for NeoVim, I haven’t gotten an LSP to work just right. Sometimes Dialyzer is a pain in the ass. Also, I’ve had some issues installing erlang via ASDF lately and sometimes I’ve had to use homebrew symlinks to skip that problem.
I recommend that OP give Elixir a shot and see what you think. There’s also very nice community on the Elixir language slack server.
I'm about six years in with Elixir, five years in production at Appcues. I have no regrets at all -- Elixir and the BEAM have been fantastic. It is convenient to write very scalable and stable systems that operate in soft real-time, which is what I do for a living, so I have warm feelings.
Previously I wrote Scala for a few years, then RoR for a few years before that, following about a decade of Perl. I recommend you try Elixir.
Anyone complaining about a talent pool is focusing too hard on prior Elixir experience. We hire backend engineers and teach them Elixir. This has worked out great so far, especially now that we're a fully remote business and are no longer as constrained by geography.
Previously I wrote Scala for a few years, then RoR for a few years before that, following about a decade of Perl. I recommend you try Elixir.
Anyone complaining about a talent pool is focusing too hard on prior Elixir experience. We hire backend engineers and teach them Elixir. This has worked out great so far, especially now that we're a fully remote business and are no longer as constrained by geography.
We chose elixir in 2016 for our product and never regretted it.
Apart from application bugs we’ve caused, it just keeps chugging along and working beautifully. It’s never once been the bottleneck in our stack.
Finding people has not been tough at our scale, and they’ve been good quality.
We are just scratching the surface with OTP. And between that and the data processing tools, we know we can handle pretty much any scale.
Deployment is nearly as crude as it was 5 years ago though. We use distillery and edeliver. We are moving to docker containers soon.
We use Exq for background jobs and have processed 75 million in a year without a sweat (most of that in the last two months). We handle 55 million requests per month on t3.mediums. We are looking to switch from Exq to Oban but I’m nervous about whether Oban’s Postgres based architecture will handle it. It’ll probably be totally fine.
Apart from application bugs we’ve caused, it just keeps chugging along and working beautifully. It’s never once been the bottleneck in our stack.
Finding people has not been tough at our scale, and they’ve been good quality.
We are just scratching the surface with OTP. And between that and the data processing tools, we know we can handle pretty much any scale.
Deployment is nearly as crude as it was 5 years ago though. We use distillery and edeliver. We are moving to docker containers soon.
We use Exq for background jobs and have processed 75 million in a year without a sweat (most of that in the last two months). We handle 55 million requests per month on t3.mediums. We are looking to switch from Exq to Oban but I’m nervous about whether Oban’s Postgres based architecture will handle it. It’ll probably be totally fine.
55 / 2.62 (millions of seconds in a month) ~= 20reqs / second
That's not very impressive, you could achieve that easily on something deemed "slow" like Django or RoR
But I guess your load is not constant. How many reqs/sec can it handle in the peak time?
That's not very impressive, you could achieve that easily on something deemed "slow" like Django or RoR
But I guess your load is not constant. How many reqs/sec can it handle in the peak time?
Yes it's not constant. We have a handful of bursts (tens of thousands of SMS conversations happening at 9am every day that complete in about an hour, for each SMS we send out, we get back 3 status callback webhooks from Twilio). And we've had a couple "mass" message sends where it did take a few hours to send 1.6 million messages. But again, that was due to our twilio limits and not elixir. We had to throttle our jobs when Twilio started saying their queue for our number was full.
I just checked (because we now process most jobs in the background), we have gone as high as about 500 jobs per second in exq on that same machine (and each job typically runs anywhere from 5 to 15 SQL queries). The bottleneck is actually the size of our RDS instance. Not complaining about postgres, just saying elixir hasn't been the bottleneck for that amount. Every hour we process CSV files with 30,000 records, etc.
We only started caching things about a month ago. I have been very lazy about that since it just didn't make any difference until recently.
Again, the point I'm trying to make is that using elixir has been positively and utterly boring in the best way possible. No drama whatsoever. We've spent the overwhelming majority of any of the time related to this looking at postgres. Not even complaining about Postgres either, it's more a conversation of what's the right RDS size and IO for our traffic.
This stack has caused us very little drama.
I just checked (because we now process most jobs in the background), we have gone as high as about 500 jobs per second in exq on that same machine (and each job typically runs anywhere from 5 to 15 SQL queries). The bottleneck is actually the size of our RDS instance. Not complaining about postgres, just saying elixir hasn't been the bottleneck for that amount. Every hour we process CSV files with 30,000 records, etc.
We only started caching things about a month ago. I have been very lazy about that since it just didn't make any difference until recently.
Again, the point I'm trying to make is that using elixir has been positively and utterly boring in the best way possible. No drama whatsoever. We've spent the overwhelming majority of any of the time related to this looking at postgres. Not even complaining about Postgres either, it's more a conversation of what's the right RDS size and IO for our traffic.
This stack has caused us very little drama.
> 55 / 2.62 (millions of seconds in a month) ~= 20reqs / second
I'm pretty sure Java 1.0 running on an Amiga could handle that...
I'm pretty sure Java 1.0 running on an Amiga could handle that...
[deleted]
I bet even 8051 + 10 Mb ISA 10BASE2.
to be fair t3.medium is very small for a production deployment ($30/month on-demand) so I read this as having cycles to spare
Running 75 million jobs a year would be totally fine. Depending on the configuration and load Oban easily runs thousands of jobs a second, and 75 million breaks down to less than 3 a second.
I’d argue it’s worth the switch, but I’m highly biased!
I’d argue it’s worth the switch, but I’m highly biased!
[deleted]
Thank you! I've been meaning to ask Oban people about this. Sadly, while Exq has been rock solid for us the last few years, Oban seems to have a ton of active development and features we wholeheartedly want to adopt. Just haven't had the time to run tests :)
Our workload is highly bursty. We queue about 20k jobs in the morning, which themselves queue another 100k-150k jobs. Then hourly we queue additional ones. I'm concerned about the Postgres overhead of inserting thousands of rows for jobs, each with potentially their own transaction.
With Oban, we can actually get rid of Redis in our stack (currently using it for Exq)
Our workload is highly bursty. We queue about 20k jobs in the morning, which themselves queue another 100k-150k jobs. Then hourly we queue additional ones. I'm concerned about the Postgres overhead of inserting thousands of rows for jobs, each with potentially their own transaction.
With Oban, we can actually get rid of Redis in our stack (currently using it for Exq)
I love Elixir. But…
Five years ago I spent time learning Elixir on the side thinking I was investing in an upcoming technology that would pay off for me financially. I eventually built some services in Elixir at work and really enjoyed it. They performed well but the language didn’t catch on with the rest of the team.
However, five years later the mainstream languages (Ruby, Go) are still paying more. I still get recruiter messages for Elixir jobs offering less than market value but I haven’t used the language in over a year.
Five years ago I spent time learning Elixir on the side thinking I was investing in an upcoming technology that would pay off for me financially. I eventually built some services in Elixir at work and really enjoyed it. They performed well but the language didn’t catch on with the rest of the team.
However, five years later the mainstream languages (Ruby, Go) are still paying more. I still get recruiter messages for Elixir jobs offering less than market value but I haven’t used the language in over a year.
Looking for increased pay based on programming language used is going to lead to disappointment more often than not.
The best thing that anyone can do to increase their compensation is be aligned with a business, or part of a business where they’re a profit center vs a cost center. The language itself is more about a persons preference and the things that you value as far as day to day working experience.
I thought of this as working at a tech company on a core tech product for a technical manager in a tech role. But working as a developer for a profit center is more concise.
Interesting, I've had the opposite experience. I get paid a ridiculous amount for Elixir work because finding experienced Elixir devs is so difficult. Most of the job offers I get for it I avoid because I think "there's no way this company is going to last longer than a year paying that much for developers".
As an SRE who has had to baby sit production elixir apps I'd highly recommend first having a talk to your operations guys. I've never had a more challenging system to debug and keep running.
It's only a matter of time until you hit something as confusing as https://elixirforum.com/t/dbconnection-connectionerror-pid-x...
It's only a matter of time until you hit something as confusing as https://elixirforum.com/t/dbconnection-connectionerror-pid-x...
Yeah, I concur. If you’re a ops infrastructure let’s people deploy whatever ever they want in a container, and you can make the devs debug the elixir specific code, then you should be ok. If t try us devs force having to understand Erlang releases, GenServer timeouts, and Ecto based macro errors onto the ops group, everyone is gonna have a bad time.
Haha I'm not sure if we know each other since I know the issue you describe in this link. Regardless, I think this is a somewhat weird example since the it should not be DevOps' duty to look at and try to understand an error that stems from Ecto. And our company did face this issue, but this was largely related to the DB optimization and the Postgres instance instead of anything language-specific. If you have bad DB schemas and optimizations you're gonna face the same issue no matter in Java or Go. Saying that you've "never had a more challenging system to debug and keep running" sounds really dramatic as our Elixir apps have been running fine 99% of the time and barely even triggered any on-call incidents.
> I've never had a more challenging system to debug and keep running.
Heh, the core system I put in place at work 3 years ago and is updated daily has never gone down once. Isn't that the point of the BEAM and supervision trees?
It's different, requires to learn a new skillset, but I wouldn't call it "challenging to keep running."
Heh, the core system I put in place at work 3 years ago and is updated daily has never gone down once. Isn't that the point of the BEAM and supervision trees?
It's different, requires to learn a new skillset, but I wouldn't call it "challenging to keep running."
Very satisfied with Elixir! I think it just fits my way of thinking. I love the terse, but explicit code, the VM, OTP, pattern matching, working with immutable data, integrated tooling, documentation support. The community is great, too.
The popular packages are top-notch, but as others have said - there might be issues finding what you need. My personal experience seems to be the opposite though - when going from Elixir to Ruby, it turned out that some of the gems were really, really far from perfect.
In terms of deployment, my take is that the community has finally figured it out. Elixir is a compiled language, so there is a build-time configuration and runtime configuration and I think it's best to keep the two separate, which is now well supported by the new runtime config (Elixir >= 1.11). Mix releases + runtime.exs + Docker works for me perfectly.
If you're coming from RoR, you'll be able to pick up Phoenix really quickly. It draws a pretty clear line between your web layer and your business/app layer though. Writing controllers and views should be similar, but I'd suggest spending some time on Ecto - it's quite different from ActiveRecord (in a good way, IMO).
One thing I'm missing in Elixir is optional static typing akin of TypeScript, but that's not coming anywhere soon. Other than that, no regrets.
I got introduced to Elixir in 2015 and was trying to work with it full-time since then. I was able to get a full-time Elixir job and I'm really happy about that. If you're looking for opportunities, I'd suggest attending ElixirConf or ElixirConf EU - last year I got 5 interesting job opportunities from ElixirConf EU alone (it was a virtual event, so the ticket was cheap).
The popular packages are top-notch, but as others have said - there might be issues finding what you need. My personal experience seems to be the opposite though - when going from Elixir to Ruby, it turned out that some of the gems were really, really far from perfect.
In terms of deployment, my take is that the community has finally figured it out. Elixir is a compiled language, so there is a build-time configuration and runtime configuration and I think it's best to keep the two separate, which is now well supported by the new runtime config (Elixir >= 1.11). Mix releases + runtime.exs + Docker works for me perfectly.
If you're coming from RoR, you'll be able to pick up Phoenix really quickly. It draws a pretty clear line between your web layer and your business/app layer though. Writing controllers and views should be similar, but I'd suggest spending some time on Ecto - it's quite different from ActiveRecord (in a good way, IMO).
One thing I'm missing in Elixir is optional static typing akin of TypeScript, but that's not coming anywhere soon. Other than that, no regrets.
I got introduced to Elixir in 2015 and was trying to work with it full-time since then. I was able to get a full-time Elixir job and I'm really happy about that. If you're looking for opportunities, I'd suggest attending ElixirConf or ElixirConf EU - last year I got 5 interesting job opportunities from ElixirConf EU alone (it was a virtual event, so the ticket was cheap).
"Installation - Caramel Manual" https://caramel.run/manual/getting-started/installation.html
Hey Stefan, nice to see you here :)
We adopted it 4 years ago and love it.
As for training people, I taught my non-technical co-founder Elixir for some backend scripts he needed to write. He found it much simpler to pick up then Javascript or Ruby and his code was idiomatic rather quickly.
As for the IDE support in VSCode, I've found ElixirLS[1] great. I do have to restart it sometimes (delete the .elixir_ls folder), but that's a small cost to pay for a pretty great experience.
After spending years in RoR in multiple code bases, I find Elixir code bases to be easier to debug and libraries easier to grok. Without the mutable state of OOP, I don't find myself asking, "Where is this state coming from and when/how was it set?" Of course, macros can be hard to follow, but I still find an Elixir library more straight forward than a Ruby one.
We've also experience the great performance and reliability shared by others on this
We haven't had difficulty finding the right libraries even though the ecosystem isn't as mature as Ruby or Javascript.
[1] https://marketplace.visualstudio.com/items?itemName=JakeBeck...
As for training people, I taught my non-technical co-founder Elixir for some backend scripts he needed to write. He found it much simpler to pick up then Javascript or Ruby and his code was idiomatic rather quickly.
As for the IDE support in VSCode, I've found ElixirLS[1] great. I do have to restart it sometimes (delete the .elixir_ls folder), but that's a small cost to pay for a pretty great experience.
After spending years in RoR in multiple code bases, I find Elixir code bases to be easier to debug and libraries easier to grok. Without the mutable state of OOP, I don't find myself asking, "Where is this state coming from and when/how was it set?" Of course, macros can be hard to follow, but I still find an Elixir library more straight forward than a Ruby one.
We've also experience the great performance and reliability shared by others on this
We haven't had difficulty finding the right libraries even though the ecosystem isn't as mature as Ruby or Javascript.
[1] https://marketplace.visualstudio.com/items?itemName=JakeBeck...
Another vote for ElixirLS, I haven’t had much issue with it.
for me it works okay-ish.
I still have to occasionally grab my laptop to keep its fans from taking it airborne, it still crashes occasionally, requiring nuking .elixir_ls (and holding onto the laptop again), and while it hasn't happened recently, I've had situations where I'd get weird errors for code that should be fine, also requiring me to delete .elixir_ls to get rid of the warnings.
That said, I don't really mind, but then I perhaps don't care as much about IDE-ish features. I've also been doing more and more work inside LiveBooks, and those don't even have vim keybinding!
I still have to occasionally grab my laptop to keep its fans from taking it airborne, it still crashes occasionally, requiring nuking .elixir_ls (and holding onto the laptop again), and while it hasn't happened recently, I've had situations where I'd get weird errors for code that should be fine, also requiring me to delete .elixir_ls to get rid of the warnings.
That said, I don't really mind, but then I perhaps don't care as much about IDE-ish features. I've also been doing more and more work inside LiveBooks, and those don't even have vim keybinding!
It’s honestly been one of the smartest choices we’ve made. We’ve been running it for four or five years now. It powers high throughput systems and those systems are classified as critical (if they go down, most of the product goes down.) Not a single regret.
New hires new to Elixir have spun up on it very quickly, in my opinion what a team needs is one or two people experienced in Elixir to give some initial guidance but you don’t need a staff of experienced Elixir engineers to do great work. I have not found it a hard language to teach.
Personally I’ve found the library ecosystem very strong, and writing our own libraries has not been hard. It’s important to note that interop with Erlang is quite good, so you have access to decades of library development from the Erlang ecosystem in addition to libraries written in Elixir.
The basic elements you’re given out of the box for handling fault tolerance and concurrency are graceful and intuitive. The performance has also deeply impressed us.
On a personal level, it’s also the most enjoyable language I’ve worked in and I’ve had very good experiences with the community. I find the tooling very good, including the VSCode extension (I have contributed a few features) but the default dialyzer setting definitely does hog the CPU on first build. I disabled it since we don’t get much out of it.
I’ve built and run software in production in a lot of different languages over the last 15 years. Nothing has compared to Elixir, not even close.
YMMV, I’m not here to refute the experiences of others, I’m just here to say for us it’s been an incredible experience. Absolute joy to use.
New hires new to Elixir have spun up on it very quickly, in my opinion what a team needs is one or two people experienced in Elixir to give some initial guidance but you don’t need a staff of experienced Elixir engineers to do great work. I have not found it a hard language to teach.
Personally I’ve found the library ecosystem very strong, and writing our own libraries has not been hard. It’s important to note that interop with Erlang is quite good, so you have access to decades of library development from the Erlang ecosystem in addition to libraries written in Elixir.
The basic elements you’re given out of the box for handling fault tolerance and concurrency are graceful and intuitive. The performance has also deeply impressed us.
On a personal level, it’s also the most enjoyable language I’ve worked in and I’ve had very good experiences with the community. I find the tooling very good, including the VSCode extension (I have contributed a few features) but the default dialyzer setting definitely does hog the CPU on first build. I disabled it since we don’t get much out of it.
I’ve built and run software in production in a lot of different languages over the last 15 years. Nothing has compared to Elixir, not even close.
YMMV, I’m not here to refute the experiences of others, I’m just here to say for us it’s been an incredible experience. Absolute joy to use.
4 years of writing elixir professionally and I have yet to enjoy a language as productive as elixir.
Everything from ecto, and branching logic by pattern matching function signatures to the easy composition and cohesive community around the amazing tooling (mix/hex) and testing. Plenty more I love for productivity
But because of OTP and it's capacity to scale and distribute computation I thoroughly stay loving how deep the topic is and how there's always more to learn.
Everything from ecto, and branching logic by pattern matching function signatures to the easy composition and cohesive community around the amazing tooling (mix/hex) and testing. Plenty more I love for productivity
But because of OTP and it's capacity to scale and distribute computation I thoroughly stay loving how deep the topic is and how there's always more to learn.
If you invest time learning Erlang everything around Elixir will make sense and it will be a pleasant experience not only to "write" but to test, debug and maintain as well. I would go through this slightly dated but gentle introduction before learning Elixir: https://learnyousomeerlang.com/content
Thinking in processes and knowing/using the GenServer abstraction is the core of Elixir programming.
So, one negative is that difficult to use without Erlang knowledge. Also some good libraries are Erlang only for compatibility/historical reasons.
Thinking in processes and knowing/using the GenServer abstraction is the core of Elixir programming.
So, one negative is that difficult to use without Erlang knowledge. Also some good libraries are Erlang only for compatibility/historical reasons.
this. I had piloted a project in Elixir a few years ago. It wasn't until I really learned Erlang that it became a pleasant experience. In the end it was replaced by another team in another language.
> If you invest time learning Erlang everything around Elixir will make sense
But this seems like a big issue to me. It probably makes the learning curve high if u basically need to learn 2 languages.
But this seems like a big issue to me. It probably makes the learning curve high if u basically need to learn 2 languages.
Outstanding work from the Elixir team. Very good community in the forum.
It’s winter of elixir land. The hype cycle has died. If I have to start a project I will think twice unless it really needs distributed system.
My personal opinion - talent pool, plugins and ecosystem is kind of stagnated. First talent pool is really limited and not readily available. Very few companies use elixir in production. More hobbyists in the community than people who actually use it.
Hex has a lot of plugins which are not updated from long. For many there won’t be a plug-in. You have to write it from scratch.
In Phoenix, they are reinventing magic with LiveView.
Few guys who do elixir consulting gain most from the ecosystem.
As a developer if I have to invest my time learning a new language, I would choose rust or Go.
As a company if I have to start a project, I will check whether I have a requirement of distributed systems.
PS: I have used elixir for past 5 years in production.
It’s winter of elixir land. The hype cycle has died. If I have to start a project I will think twice unless it really needs distributed system.
My personal opinion - talent pool, plugins and ecosystem is kind of stagnated. First talent pool is really limited and not readily available. Very few companies use elixir in production. More hobbyists in the community than people who actually use it.
Hex has a lot of plugins which are not updated from long. For many there won’t be a plug-in. You have to write it from scratch.
In Phoenix, they are reinventing magic with LiveView.
Few guys who do elixir consulting gain most from the ecosystem.
As a developer if I have to invest my time learning a new language, I would choose rust or Go.
As a company if I have to start a project, I will check whether I have a requirement of distributed systems.
PS: I have used elixir for past 5 years in production.
I would also prefer having a typed language over the fail fast in production approach.
Especially if your code does not saturate a single CPU core.
Especially if your code does not saturate a single CPU core.
I'm currently learning Elixir and I'm loving it. I'm in that got 30% of my app written in it place.
I may or may not regret using it in the big picture (libraries, esoteric ness, performance, a 5th language/platform in our soup of tech we use to solve our problem, etc, and who knows) eventually; it's too early for me to tell.
But I wont regret learning Elixir. There's a certain zen in the "ah so you're a programmer, eh? But can you do it without any references/pointers or for loops, huh?" This from a guy who spent 20 solid years as an "objects all the way down" smalltalker, and does a lot of multi paradigm hybrid Python/Kotlin/Swift these days with a bunch of C as well.
What I really noticed last week when I did a day of Python after a week of Elixir is how much time I spend in other languages writing branch logic code. Code where you decide what direction your code should go next. Should it do this or that now. Or if it should optionally do that. I'm writing an order of magnitude less of that code (it moves to a more orthogonal place in multi function matching) in Elixir. It's stretching me and I'm learning new ways of seeing things that ultimately make me a better programmer; the slack channel has been really nice.
I tried Haskell to try and get the taste for pure functional a year ago; it did not go anywhere near as well as this.
I may or may not regret using it in the big picture (libraries, esoteric ness, performance, a 5th language/platform in our soup of tech we use to solve our problem, etc, and who knows) eventually; it's too early for me to tell.
But I wont regret learning Elixir. There's a certain zen in the "ah so you're a programmer, eh? But can you do it without any references/pointers or for loops, huh?" This from a guy who spent 20 solid years as an "objects all the way down" smalltalker, and does a lot of multi paradigm hybrid Python/Kotlin/Swift these days with a bunch of C as well.
What I really noticed last week when I did a day of Python after a week of Elixir is how much time I spend in other languages writing branch logic code. Code where you decide what direction your code should go next. Should it do this or that now. Or if it should optionally do that. I'm writing an order of magnitude less of that code (it moves to a more orthogonal place in multi function matching) in Elixir. It's stretching me and I'm learning new ways of seeing things that ultimately make me a better programmer; the slack channel has been really nice.
I tried Haskell to try and get the taste for pure functional a year ago; it did not go anywhere near as well as this.
1.5 years in and Phoenix Liveview is perfect for internal webapps. Have personally seen development take half as much time with half as much people compared to traditional stacks. You don't need super rich interactions nor offline mode for internal apps, plus they might be harder to prio against customer-facing feature work. Elixir and LiveView are really powerful tools to have in your toolbelt. Even if you can't use Elixir, look at Hotwire or Livewire for a similar programming model. You won't get zero-setup fault tolerant components (nested LiveViews can crash and not take the entire page with it, and retry side effects automatically), but you'll still cut out the JS side of the development.
And we haven't even spoken about an app-aware repl that lets you manipulate/inspect your running app (even in prod). There are so many game-changing layers in this stack. It's hard to beat once you've explored it.
Very happy customer here.
And we haven't even spoken about an app-aware repl that lets you manipulate/inspect your running app (even in prod). There are so many game-changing layers in this stack. It's hard to beat once you've explored it.
Very happy customer here.
I've had an niche event ticketing Elixir/Phoenix app in production for 4 years and have had next to zero problems. It gets very bursty traffic (100s of simultaneous users when an event opens for ticket purchases with load quickly tapering off in a negative exponential distribution) and the load average barely changes with insanely fast responses on a $10 VM.
I think the only downside for me is having to squint sideways to figure out how to convert a complex SQL query into Ecto. I've been writing SQL for almost 30 years and I find myself dropping into using Ecto's `fragment` too often. I've been meaning to pickup "Programming Ecto" to educate myself more (https://pragprog.com/titles/wmecto/programming-ecto/).
I've done my share of RoR apps too and the nice thing about Elixir is there is very little magic and what magic there is (mostly via macros and code auto added via a `use` statement) can be seen and changed directly in your code instead of being hidden in some gem somewhere.
I think the only downside for me is having to squint sideways to figure out how to convert a complex SQL query into Ecto. I've been writing SQL for almost 30 years and I find myself dropping into using Ecto's `fragment` too often. I've been meaning to pickup "Programming Ecto" to educate myself more (https://pragprog.com/titles/wmecto/programming-ecto/).
I've done my share of RoR apps too and the nice thing about Elixir is there is very little magic and what magic there is (mostly via macros and code auto added via a `use` statement) can be seen and changed directly in your code instead of being hidden in some gem somewhere.
I write very few fragments and many more raw queries. No ORM is worth the trouble of going too deep into the rabbit hole of learning for the nth time how to write SQL in X.
It is tempting to just drop down to raw queries but then when I read about things like composable Ecto queries (https://medium.com/flatiron-labs/how-to-compose-queries-in-e...) it makes me want to stay at the higher abstraction level.
The final example in that post:
The final example in that post:
EctoCars.Car
|> EctoCars.Car.with_color("blue")
|> EctoCars.Car.with_transmission("automatic")
|> EctoCars.Car.with_engine_horse_power(200)
|> EctoCars.Repo.all()
SELECT c0."id", c0."color", c0."vin_number", c0."specification_id"
FROM "cars" AS c0
LEFT OUTER JOIN "specifications" AS s1 ON c0."specification_id" = s1."id"
LEFT OUTER JOIN "transmissions" AS t2 ON s1."transmission_id" = t2."id"
LEFT OUTER JOIN "engines" AS e3 ON s1."engine_id" = e3."id"
WHERE (c0."color" = $1) AND (t2."type" = $2) AND (e3."horse_power" > $3)Yes, we use that pattern in the Elixir project I'm working on. But that's a simple query despite all the JOINs. It's just a waste of time to convert complex queries into Ecto. Maybe the reason is that I build them in the database using it as a REPL. Then I have working SQL and a lot of hard work to turn them into Elixir. Or Ruby, or Python or whatever. I played that game for far too long. I give up immediately now, write raw SQL and move on to the next productive task.
I think the parent commenter is not saying to write your one time use query in elixir using wrapper modules with Ecto, but tried to show that queries generated by Ecto are pretty clean and understandable in compare to other popular DataMappers/ORMs
That sounds like a fun but challenging project: Convert sql to idomatic ecto. Mostly as a way to help people learn ecto better. Probably a long-tail-y issue, but maybe one where a 70% solution is useful?
I've been programming in elixir for 5 years now.
Currently on my 3rd year as CTO of a startup. I chose elixir for the greenfield project because we wanted realtime sync for all devices and the smaller projects I worked on before in elixir went off without a hitch. I also found its concurrenly handling and performance far superior to node and I was producting far less bugs due to its functional nature.
3 years in and I'm very satisfied. There are a few epics we took on that would have been much more expensive to do in go or node. For example, we made a partnership with a credit card device terminal. Their interface required one persistent webocket connection per restaurant. IN another language, I would have had to coordinate with my devops guy to have a dynamic system to allocate a process for each of our accounts and route that to our devices. The intended use case were on premise POSes so our cloud based solution wasn't somethign they had planned on supporting.
Anyways, I was able to configure horde and a dynamic registry to boot up a process for each active account and automatically resserect on crash. Since pubsub is built in, It was easy to pass along data from it to all the devices over the channels interface. Best part is it was all doable within the code base running without any changes to out deployment.
Overall, I've been happy with elixir. the only bg downside is its gotten a bit boring. Things just work which leaves me spending time on rust in my free time when I want a challenge.
Currently on my 3rd year as CTO of a startup. I chose elixir for the greenfield project because we wanted realtime sync for all devices and the smaller projects I worked on before in elixir went off without a hitch. I also found its concurrenly handling and performance far superior to node and I was producting far less bugs due to its functional nature.
3 years in and I'm very satisfied. There are a few epics we took on that would have been much more expensive to do in go or node. For example, we made a partnership with a credit card device terminal. Their interface required one persistent webocket connection per restaurant. IN another language, I would have had to coordinate with my devops guy to have a dynamic system to allocate a process for each of our accounts and route that to our devices. The intended use case were on premise POSes so our cloud based solution wasn't somethign they had planned on supporting.
Anyways, I was able to configure horde and a dynamic registry to boot up a process for each active account and automatically resserect on crash. Since pubsub is built in, It was easy to pass along data from it to all the devices over the channels interface. Best part is it was all doable within the code base running without any changes to out deployment.
Overall, I've been happy with elixir. the only bg downside is its gotten a bit boring. Things just work which leaves me spending time on rust in my free time when I want a challenge.
I'm very bullish on Elixir as a language, but I temper that with the reality that I don't think it will become a mainstream language (in the next few years, at least).
I picked up Elixir probably 4-5 years ago when a co-worker kept recommending it and wanted to explore it more. We finally got the approval to do a microservice in it that was well-suited for it. Over time it became one of the two "blessed languages" alongside Ruby, and was probably adopted by 40% of teams. Our monolith was still Ruby, so a lot of teams had to use Ruby.
I found that people could pick up the language fairly quickly, but it would take a few stumbles on OTP before things started to click there. People generally seemed to like learning it, though. Maybe they were just being polite.
For me, Elixir has been the most fun I've had programming since I started. It allows me to more consciously design my systems because I don't really feel limited by it—this is why I'm bullish on the language. I enjoyed programming in Ruby, but felt limited to doing things a certain way.
There's also still a ton of opportunity in the community (which is excellent as it is, imo). For example, I wrote a book with Pragmatic that I don't think I would've been able to write in the Ruby world. If you're the type of person who likes exploring, figuring things out, and documenting afterwards, then you could make a nice name for yourself in the community.
Hiring is still a bit rough. If you're trying to scale to 50+ engineers then you're going to need someone skilled in training to bring the team up. Throwing them into the deep end won't work. I think smaller teams should generally not have as big of a problem? I'm curious to see how my former employer will maintain Elixir—grow or shrink adoption—over the next 2 years.
I picked up Elixir probably 4-5 years ago when a co-worker kept recommending it and wanted to explore it more. We finally got the approval to do a microservice in it that was well-suited for it. Over time it became one of the two "blessed languages" alongside Ruby, and was probably adopted by 40% of teams. Our monolith was still Ruby, so a lot of teams had to use Ruby.
I found that people could pick up the language fairly quickly, but it would take a few stumbles on OTP before things started to click there. People generally seemed to like learning it, though. Maybe they were just being polite.
For me, Elixir has been the most fun I've had programming since I started. It allows me to more consciously design my systems because I don't really feel limited by it—this is why I'm bullish on the language. I enjoyed programming in Ruby, but felt limited to doing things a certain way.
There's also still a ton of opportunity in the community (which is excellent as it is, imo). For example, I wrote a book with Pragmatic that I don't think I would've been able to write in the Ruby world. If you're the type of person who likes exploring, figuring things out, and documenting afterwards, then you could make a nice name for yourself in the community.
Hiring is still a bit rough. If you're trying to scale to 50+ engineers then you're going to need someone skilled in training to bring the team up. Throwing them into the deep end won't work. I think smaller teams should generally not have as big of a problem? I'm curious to see how my former employer will maintain Elixir—grow or shrink adoption—over the next 2 years.
Shrink probably, sorry its not growing and it never became popular...
Sorry, have you worked with the former employer I'm mentioning? I'm talking about a specific use case that has specific needs and challenges. Blanket comments like yours aren't really helpful or necessary.
I've been using Elixir/Erlang for more than 6 years and absolutely love it. The community is a lovely place to be, tooling is great. Concurrency is awesome. Erlang is battle tested. If you are building applications that have anything to do with networks, you'll be able to build some seriously performant apps without having to reach for other tools and I love the community's focus on performance.
Unfortunately I can't comment on production Elixir use (yet), but as a proffessional Ruby engineer of 6 years and an Elixir hobbiest of 3, I think that Elixir's biggest drawback is its deceptively high learning curve.
The learning curve is "deceptive" because the Elixir syntax is very easy to pick up for someone familiar with Ruby and, once you get over the functional "gotchas", you can feel productive very quickly. Especially-so given how much you get out-of-the box with a standard "mix new" project.
The learning curve is "high" because in order to actually write Elixir in a way that scales well in prod, you'll need to get comfortable with Open Telecom Platform principles like GenServer and Supervisors, which will likely feel very foreign at first.
For any Rubyist working in Elixir, if you encounter a situation where your Ruby brain wants to start browsing Hex for a library, you should probably answer these two questions first:
1. Can we do this easily with GenServers? 2. Is there an Erlang standard library module that already does this?
Conversely, if you jump in expecting to rely on Hex the same way you rely on Rubygems, you're in for a bad time.
Ultimately, I think you really need someone (ideally two someones) who is comfortable with the Actor Model and OTP in order to use Elixir successfully at a business.
But if you can build that solid OTP foundation for your project, there's a decent chance you're in for a good time.
The real-word business cases provide some encouraging examples of that: https://elixir-lang.org/cases.html
The learning curve is "deceptive" because the Elixir syntax is very easy to pick up for someone familiar with Ruby and, once you get over the functional "gotchas", you can feel productive very quickly. Especially-so given how much you get out-of-the box with a standard "mix new" project.
The learning curve is "high" because in order to actually write Elixir in a way that scales well in prod, you'll need to get comfortable with Open Telecom Platform principles like GenServer and Supervisors, which will likely feel very foreign at first.
For any Rubyist working in Elixir, if you encounter a situation where your Ruby brain wants to start browsing Hex for a library, you should probably answer these two questions first:
1. Can we do this easily with GenServers? 2. Is there an Erlang standard library module that already does this?
Conversely, if you jump in expecting to rely on Hex the same way you rely on Rubygems, you're in for a bad time.
Ultimately, I think you really need someone (ideally two someones) who is comfortable with the Actor Model and OTP in order to use Elixir successfully at a business.
But if you can build that solid OTP foundation for your project, there's a decent chance you're in for a good time.
The real-word business cases provide some encouraging examples of that: https://elixir-lang.org/cases.html
I have been using it for my (modestly sized) first serious public project (https://github.com/domovikapp/domovik-server/), and I have been quite satisfied with it.
For the pluses:
- the development experience is stellar (live code reload, REPL interacting directly with the running server, excellent debugger, dependencies management & build system are good and can be extended in the language itself);
For the pluses:
- the development experience is stellar (live code reload, REPL interacting directly with the running server, excellent debugger, dependencies management & build system are good and can be extended in the language itself);
- the integrated documentation generator is of high quality;
- the performances are satisfactory (you'll get more out of a $10/m VPS with Elixir/Phoenix than with RoR);
- deployment is surprisingly easy with the releases system;
- the language itself is quite pleasing;
- the standard library is very well designed and architectured, and everything just fall in place together;
- Ecto shows brilliantly how to combine high-level, ORM-like operations and low-level, close-to-the-SQL ones;
- Phoenix itself is a very well though out framework.
- the ecosystem is still quite young and has some sharp edges and/or missing docs;
- the OTP is magic for heavily parallel workloads, but it is also quite foreign and there will be some work to grasp its inner workings;
- there are some quirks in the language coming from the Erlang runtime;
- I would love to have a static type system, although I see how it would conflict with the tenets of the OTP.
We’ve skipped so many additional things like Redis, Memcached, Sidekiq and tons of libraries because it’s so easy to write a module to replace stuff.
Switched from ruby to elixir 4 years ago and the only time we touch ruby is to maintain some old system.
It’s so darned easy to add functionality to an exiting app that you have to be careful of bloat.
And the functional paradigm is like second nature now. It’s hard to go back to a non functional language.
Switched from ruby to elixir 4 years ago and the only time we touch ruby is to maintain some old system.
It’s so darned easy to add functionality to an exiting app that you have to be careful of bloat.
And the functional paradigm is like second nature now. It’s hard to go back to a non functional language.
How do you deal with deployments and not losing things you could otherwise persist in Redis or Memcached? Of is your application stateless in that way?
It’s stateless in that way. We’ve redesigned things in such a way that there is more idempotency in the code that does not depends on an external holder of state that is not the primary database.
It’s hard to explain, but the end result is that we don’t reach for Redis as much as we used to.
It’s hard to explain, but the end result is that we don’t reach for Redis as much as we used to.
[deleted]
If you are a RoR dev, Elixir will feel like a breeze. As someone who does Haskell in their day job, I miss static, powerful type-systems.
That being said, the ecosystem is wonderful. Plug, Phoenix and Ecto are exceptional libraries!!
That being said, the ecosystem is wonderful. Plug, Phoenix and Ecto are exceptional libraries!!
Interesting to see someone work in Haskell professionally. Jobs in Haskell don't seem be plenty atleast in my area. Could I know what do you work on, and what was the process of obtaining a job there?
Do day jobs in Haskell actually exist? Are you working in academia?
There are a bunch but they call the Haskell "Scala" for some reason.
That's make me wonder: what's the "right" pronunciation for Haskell in English? Does it rhyme with Scala?
Depending on accent, I've heard "Haskell" rhyme with either "skull" or "fell".
There are some in finance
Lots of these newfangled blockchain businesses use Haskell. I'd wager probably most non-academic Haskell programmers work on blockchain stuff.
In 2016, we started to use Elixir as our default backend stack (from Ruby on Rails) for new projects and never looked back! We have since shipped a dozen projects using Phoenix, Ecto, Plug and Absinthe.
A couple of guys at my company did their first startup using Elixir years ago, but they weren’t devs so they had to contract a company to do it. They regret it now because no one at our company can work on it, and they have to rely on the contractors who charge a lot. Sure someone could learn it, but we’ve got more important things to do. As much as everyone on HN loves it, you’re going to have to work hard to get others involved. It really isn’t worth it unless you want to own it for the rest of its life.
Why did non devs choose the language of a product ? Sounds like a strange decision. Or it was the contractor's choice with its dev team waiting for years the opportunity to try Elixir.
I think they read about it on HN
> They regret it now because no one at our company can work on it
> Sure someone could learn it, but we’ve got more important things to do
If they can't give you 2 or 3 days to learn a language then they don't regret it that much I guess.
> Sure someone could learn it, but we’ve got more important things to do
If they can't give you 2 or 3 days to learn a language then they don't regret it that much I guess.
I'd say your unlikely to pick up the entirety of OTP in a few days, but agree that it should'nt be too daunting to train in it.
You usually don't need to understand the entirety of OTP to work on an elixir code base. For some Phoenix projects you don't even need to know what OTP is to get things done.
We started to use Elixir around mid 2016, we were mostly using rails/sidekiq stack at that point and started to face scaling issues with sidekiq. Moved small parts to Elixir first and then later started to use it for most of the new services. We had to create new libraries for some specific use cases. Apart from that, it was mostly smooth experience. We rarely had to tune or adjust the code for performance. Today we have a big monorepo with 20+ apps. My long term concerns are more about whether the tooling will work if we try to scale it to 100+ apps with a single monorepo.
We majorly depend on Plug, hackney, Exq, brod and Ecto.
We majorly depend on Plug, hackney, Exq, brod and Ecto.
I have been writing Elixir full time for over 4 years now and I could not be happier with the language and surrounding community! With an incredibly small team (just myself and one colleague working on the backend), we are able to develop and operate very high throughput applications that reliably handle over 100k requests/s (2 main web facing apps, plus a handful of supporting services). We generate millions of dollars of revenue for our customers each week, and sleep very well at night.
I still love it a few years in. Every project I've used it on has worked really nicely with low resource usage and close to zero maintenance. Switching from RoR to Phoenix/Elixir takes some learning, mostly due to the switch to functional programming, but it's worth it imo. Everything becomes so easy to reason about, test, debug, etc. You'll learn a lot from it and become a better developer in general even when going back to ruby/python afterward.
Highly relevant thread from less than a year ago: https://news.ycombinator.com/item?id=23283675
I've been writing Elixir full time since March this year and I've loved it.
Here's a few of the highlights for me:
1. It makes me want to write more tests.
In other languages, I always defaulted to opening up a terminal to quickly hammer out something before implementing it and usually came back to the tests as an after thought. Sure with an IDE integration you can highlight and execute just the test you're looking at, but in many cases I found it clunky.
With Elixir, the entire test suite executes so fast that it's easier and faster to just work with the tests than hammer through things in the console.
For the situation where the console works better, you can copy the iex lines above your method as a code comment and that will run as a test when you run your test suite (so tests as documentation essentially).
Lastly on the test front, the assert_value library is incredibly helpful for hammering out first versions of unit tests.
2. After taking the Coding Gnome course from Dave Thomas, I love the approach to code structure.
Dave emphasizes thinking of the functionality of your application independently from the interfaces which access it. For example, the HTTP layer, a REST API, a Websocket layer, the command line, and an IEX terminal are all different interfaces.
Thinking of my code that way and developing around an internal API rather than doing something like REST first testing, etc has made things a lot cleaner for me. I'm also a big fan of the defdelegate approach for that internal API layer.
The libraries I've needed so far have been really solid, but I generally don't pull in libraries unless I really need them anyway. If I'm connecting to an API, I'd rather write the connections directly in most cases as I need them rather than pull in an API library directly for it. Gives me more control and better understanding of things and I like that. YMMV.
3. Tooling wise, VSCode has been great for me.
I've considered reaching for IntelliJ with the Elixir plugin, but as it stands right now I'm very happy with VSCode. It's been a great experience and all that I need on a day to day basis.
There's a lot more to say than that, but these are my biggest things that I'm liking so far.
Here's a few of the highlights for me:
1. It makes me want to write more tests.
In other languages, I always defaulted to opening up a terminal to quickly hammer out something before implementing it and usually came back to the tests as an after thought. Sure with an IDE integration you can highlight and execute just the test you're looking at, but in many cases I found it clunky.
With Elixir, the entire test suite executes so fast that it's easier and faster to just work with the tests than hammer through things in the console.
For the situation where the console works better, you can copy the iex lines above your method as a code comment and that will run as a test when you run your test suite (so tests as documentation essentially).
Lastly on the test front, the assert_value library is incredibly helpful for hammering out first versions of unit tests.
2. After taking the Coding Gnome course from Dave Thomas, I love the approach to code structure.
Dave emphasizes thinking of the functionality of your application independently from the interfaces which access it. For example, the HTTP layer, a REST API, a Websocket layer, the command line, and an IEX terminal are all different interfaces.
Thinking of my code that way and developing around an internal API rather than doing something like REST first testing, etc has made things a lot cleaner for me. I'm also a big fan of the defdelegate approach for that internal API layer.
The libraries I've needed so far have been really solid, but I generally don't pull in libraries unless I really need them anyway. If I'm connecting to an API, I'd rather write the connections directly in most cases as I need them rather than pull in an API library directly for it. Gives me more control and better understanding of things and I like that. YMMV.
3. Tooling wise, VSCode has been great for me.
I've considered reaching for IntelliJ with the Elixir plugin, but as it stands right now I'm very happy with VSCode. It's been a great experience and all that I need on a day to day basis.
There's a lot more to say than that, but these are my biggest things that I'm liking so far.
Been building backend systems for nearly 20 years in Java/Ruby/Elixir. Elixir is by far the most productive language/ecosystem that I've used. I've built 4 systems in the last 5 years and they've all gone smoothly and performed well in production. Only thing on the wish list is full static typing (there's dialyzer which is useful but very much feels like the bolt-on that it is).
I don't use it professionally, but I built a side-project in Elixir a few years ago and was amazed at how much I was able to get done with such a little amount of code. The service is still running today with basically no maintenance. For me it was a great choice and I would totally build my next project with Elixir on the backend.
I think of this "applications don't need much maintenance" observation when reading some of the "libraries don't get updated often" complaints here. A lot of the libraries in the ecosystem are already super stable and that's a great thing!
I picked Elixir to develop Statuspal 4 years ago as a solo founder, I’m pretty happy with the decision so far, we’ve been in production for close that time and I feel very productive and enjoy it a lot.
That’s not to say we never encounter hiccups, we’ve been bitten by a few libraries getting unmaintained, a few drastic changes in Phoenix in the first years, and a hard time getting a proper deployment setup, but nowadays is much more mature.
Thanks to Elixir we got away with things like not needing to cache (for quite some time) with great performance and with little resources, not worrying about the app becoming slow if 6 people visit at the same time.
Hiring Elixir developers is not as easy as RoR devs but is doable, I had good experience in Elixir specific places like https://elixirjobs.net/ and Upwork to a lesser degree.
That’s not to say we never encounter hiccups, we’ve been bitten by a few libraries getting unmaintained, a few drastic changes in Phoenix in the first years, and a hard time getting a proper deployment setup, but nowadays is much more mature.
Thanks to Elixir we got away with things like not needing to cache (for quite some time) with great performance and with little resources, not worrying about the app becoming slow if 6 people visit at the same time.
Hiring Elixir developers is not as easy as RoR devs but is doable, I had good experience in Elixir specific places like https://elixirjobs.net/ and Upwork to a lesser degree.
Having done python for many years and coming to Elixir the things that I find Elixir does really well are:
- mix and the general tooling (package management, testing, deployment)
- iex - specifically being able to run a shell at the same time as running my app. It makes it easy to test and explore code from the REPL
- documentation (both in iex and hexdocs) - Navigating Elixir documentation is standardized and easy
- Immutability - it took a while to get used to but now I wouldn't have it any other way
- mix and the general tooling (package management, testing, deployment)
- iex - specifically being able to run a shell at the same time as running my app. It makes it easy to test and explore code from the REPL
- documentation (both in iex and hexdocs) - Navigating Elixir documentation is standardized and easy
- Immutability - it took a while to get used to but now I wouldn't have it any other way
and the standard way of doing config is great.
Very satisfied with elixir and the ecosystem is growing! There are some performance concerns if you're doing a large amount of list or string manipulations but these are somewhat special cases and I tend to reach out to a Rust NIF to handle them which resolves the problem.
Somebody posted my post which sums up my experience a while ago[0]. In short: No regret, just make sure you are not building something that can be done twice faster with an existing Ruby library or so. But for a long-term team project, I would prefer Elixir codebase.
[0] https://news.ycombinator.com/item?id=26702222
[0] https://news.ycombinator.com/item?id=26702222
The only thing I don't like about Elixir is the fact that it doesn't come default on most distros so to use it even for scripting I need to pull strings to get it approved. Otherwise Elixir would replace Ruby for me wholesale
The comparisons to Ruby are a bit superficial. Having written and then torn apart highly abstracted code in Elixir, I would always try to keep my code as low abstraction as possible in Elixir which I need not really do in Ruby. Otherwise I find debugging concurrency problems very difficult (and yes, you can still create many concurrency problems in Elixir). If you are doing single-threaded stuff, there is almost no reason to use Elixir. I do like Phoenix better than Rails, but only marginally
The comparisons to Ruby are a bit superficial. Having written and then torn apart highly abstracted code in Elixir, I would always try to keep my code as low abstraction as possible in Elixir which I need not really do in Ruby. Otherwise I find debugging concurrency problems very difficult (and yes, you can still create many concurrency problems in Elixir). If you are doing single-threaded stuff, there is almost no reason to use Elixir. I do like Phoenix better than Rails, but only marginally
There are things about Elixir I love, most of which come from the Erlang language (esp. their processes and gen behaviors). There are those I dislike (tooling is not where I'd like, tracing to underlying Erlang is hard sometimes).
There are projects where I'd choose Erlang or Elixir (typically M&S or HPC efforts where the processes really come into play, or real-time mission critical efforts where every minute of downtime could cost lives).
Most other projects are based on what the shop I'm in uses, or my personal preference for the task. I'm finding I'm choosing Rust more and more, outside of my day job, which is strictly C++ at the moment (but we're investigating Rust).
There are projects where I'd choose Erlang or Elixir (typically M&S or HPC efforts where the processes really come into play, or real-time mission critical efforts where every minute of downtime could cost lives).
Most other projects are based on what the shop I'm in uses, or my personal preference for the task. I'm finding I'm choosing Rust more and more, outside of my day job, which is strictly C++ at the moment (but we're investigating Rust).
I am super happy with Erlang/Elixir, having build and run game backends, Kafka replicators, an ML platform (models in Python) and several social apps over the years.
My story is a bit different but maybe interesting to contrast:
I used to work with Ruby for years when I switched to Erlang 9 years ago. So for me the syntax was unfamiliar and the actor model was completely new. Elixir and Phoenix where not around so I started with processes, messages, gen_server and the like. I started building an Erlang-process load balancer, learning about mailboxes and supervision in the process. Later I switched to Elixir and felt reminded of the Ruby syntax, really liking it plus new things like the pipe operator.
For me the biggest learning that needs to happen (apart from general FP) is on structuring applications. One way to think about it is having long-running micro services within the VM along with short-lived processes for small tasks like serving a single http request.
I can see that coming from Ruby today and using Phoenix can give you a cozy feeling where you build stuff without thinking too much about OTP, processes and how the VM does things (scheduling, mailboxes, monitoring, GC, supervision, distribution). And I think that's totally fine unless you want to step outside the framework and really make use of all the things that set Erlang/Elixir apart.
So maybe one way to get started today is looking at Erlang first, explicitly because it's unfamiliar.
Corroborate the "some libraries now feel unmaintained" view given elsewhere. Also the language itself and best practise seems to change now quite often and there's a bit of a tendency to do things in multiple ways through shorthand macros which can be a bit confusing (bit of the LISP problem going on here). That said the structure of my code is vastly better than when I was doing everything in Python trying to use multiprocessing and/or threads and/or asyncio.
Two years in, Elixir+Phoenix is an extremely productive setup for me.
So here's my experience as a hobbyist.
I really enjoyed using Elixir when it gained some traction around 2017-2018 and found the language to be beautiful. The documentation is also great. Here's a few reasons why I never kept using it for my own projects.
Most of the time Elixir feels like overkill. It's easier to use Node.js or Golang to create simple services or prototypes. The mental overhead of having to go from an imperative language to a functional one is high. Once I had paid that cost and gotten over the learning curve, I found it exhausting to write and didn't really feel like I was getting a lot of value.
Take BEAM processes and supervision trees for instance. Almost all of my projects are containerized, split into different services, and have some kind of redundancy on top. When I was deploying Node.js projects onto VPSs I almost always used Docker, systemd, or pm2. Once I started working with AWS regularly, I was using ECS and Lambda for everything. The ability to easily create discrete services and have redundancy for those services meant that I didn't really get a lot of value from having this single Elixir instance that is responsible for many things.
Take ETS: when I started using Elixir, I already had years of experience using Redis and preferred it to most in-memory data stores. I tried to give ETS a shot but found myself wanting the Redis API over and over. Thankfully, the Redix library was excellent and had great support for almost all Redis features, but it always felt like I was using Elixir incorrectly by not utilizing ETS.
Some other points that have already been iterated in other comments:
* Packages are very hit or miss. Sometimes a package will only have an Erlang counterpart and coding efficiently becomes harder if you don't know or understand Erlang well
* The IDE tooling is also hit or miss :( It sucks when your IDE starts to freeze or doesn't understand how to autofill certain things
* Environment configuration is kind of a pain. In the beginning it was really hard to tell what the initial starting point of my application was and how to feed in configuration values to those different parts of my app. I wish this part of Elixir was easier.
* Phoenix was just too much. It always felt like a massive framework and I would rather have had something closer to Koa (Node.js) or Mux (Golang).
I really enjoyed using Elixir when it gained some traction around 2017-2018 and found the language to be beautiful. The documentation is also great. Here's a few reasons why I never kept using it for my own projects.
Most of the time Elixir feels like overkill. It's easier to use Node.js or Golang to create simple services or prototypes. The mental overhead of having to go from an imperative language to a functional one is high. Once I had paid that cost and gotten over the learning curve, I found it exhausting to write and didn't really feel like I was getting a lot of value.
Take BEAM processes and supervision trees for instance. Almost all of my projects are containerized, split into different services, and have some kind of redundancy on top. When I was deploying Node.js projects onto VPSs I almost always used Docker, systemd, or pm2. Once I started working with AWS regularly, I was using ECS and Lambda for everything. The ability to easily create discrete services and have redundancy for those services meant that I didn't really get a lot of value from having this single Elixir instance that is responsible for many things.
Take ETS: when I started using Elixir, I already had years of experience using Redis and preferred it to most in-memory data stores. I tried to give ETS a shot but found myself wanting the Redis API over and over. Thankfully, the Redix library was excellent and had great support for almost all Redis features, but it always felt like I was using Elixir incorrectly by not utilizing ETS.
Some other points that have already been iterated in other comments:
* Packages are very hit or miss. Sometimes a package will only have an Erlang counterpart and coding efficiently becomes harder if you don't know or understand Erlang well
* The IDE tooling is also hit or miss :( It sucks when your IDE starts to freeze or doesn't understand how to autofill certain things
* Environment configuration is kind of a pain. In the beginning it was really hard to tell what the initial starting point of my application was and how to feed in configuration values to those different parts of my app. I wish this part of Elixir was easier.
* Phoenix was just too much. It always felt like a massive framework and I would rather have had something closer to Koa (Node.js) or Mux (Golang).
No regrets, Elixir is a great language running in a rock-solid runtime, with such a nice community around it. Recommend that you give it a try.
I run GetToKnow (https://gettoknowapp.com) on Elixir.
It costs me $50/mo total (app + DB) and I can easily support 20k users across 250 organizations (some of whom are paid).
I'm basically ramen profitable overnight and my overhead is incredibly low. It's essentially pure profit.
With Ruby/Rails this would be at least x4 the cost.
It costs me $50/mo total (app + DB) and I can easily support 20k users across 250 organizations (some of whom are paid).
I'm basically ramen profitable overnight and my overhead is incredibly low. It's essentially pure profit.
With Ruby/Rails this would be at least x4 the cost.
I love Elixir, and personally like to use it for hobby projects, but I don't dare to use it in anything I plan to make a big deal out of. Not because it's bad, but because hiring another Elixir developer would be expensive as hell.
It's an amazing language but it's hard to hire for. I wouldn't want to pay someone the kind of money I get paid for it.
It's an amazing language but it's hard to hire for. I wouldn't want to pay someone the kind of money I get paid for it.
We’re very happy with it, essentially using it as a full-stack front-end though, rather than whole app. This is partly due to resourcing issues, partly due to having an aint-broke don’t fix rails service that Elixir replaced part of (our CMS, specifically). I think the rails service will stay, the benefit of porting is just too low as we’re a small team.
Functional programming is OK up to a certain degree of complexity... Good if you have a lot of junior developers on your team because it prevents certain kinds of mistakes which juniors tend to make. But many FP projects end up becoming a giant pile of spaghetti code eventually.
I think this is because FP doesn't put emphasis on separation of concerns like OOP does. FP advocates separating state from logic as being more important than separating concerns across components.
With OOP, if some piece of state concerns the same business domain as some piece of logic, then they should be co-located. On the other hand, FP will happily violate this principle in favour of keeping state and logic separate.
Having built highly complex, modular systems with OOP, I don't see how it would have been possible to implement these systems in such a modular way using FP... Co-locating related state and logic is absolutely essential to achieve modularity.
I have yet to see any complex FP system which was not spaghetti code.
I think this is because FP doesn't put emphasis on separation of concerns like OOP does. FP advocates separating state from logic as being more important than separating concerns across components.
With OOP, if some piece of state concerns the same business domain as some piece of logic, then they should be co-located. On the other hand, FP will happily violate this principle in favour of keeping state and logic separate.
Having built highly complex, modular systems with OOP, I don't see how it would have been possible to implement these systems in such a modular way using FP... Co-locating related state and logic is absolutely essential to achieve modularity.
I have yet to see any complex FP system which was not spaghetti code.
OOP also leads to spaghetti code. Everything turns into a steaming pile of crap if you don’t work to avoid that reality.
Yes, but the difference is that OOP can scale indefinitely but FP cannot.
If you don't co-locate related state and logic, ensuring that each piece of state reaches the correct components becomes a logistical nightmare at scale (either needs to traverse many intermediate components or needs to be exposed globally to all components).
If you don't allow components to mutate state locally, you need a strategy to distribute all your data directly from external stores to the correct components and also a strategy to send state updates back to the relevant stores. When you have multiple components which share some of the same data, this is impossible to do in an efficient and reliable way because of the latency between the external store and the components (components risk overwriting each other's data by sending conflicting updates, for example).
It's a logistical nightmare, because, without co-locating state with logic in some components, you cannot control how state updates are combined and then applied onto the external store. Components have no awareness of each other so they cannot coordinate. Every read and write has to go through the external store which is both inefficient and unreliable when you factor in latency. (The idea of caching violates FP principles).
The advantage of co-located state is that it can be updated synchronously without any latency so there is no possibility of conflicts.
If you don't co-locate related state and logic, ensuring that each piece of state reaches the correct components becomes a logistical nightmare at scale (either needs to traverse many intermediate components or needs to be exposed globally to all components).
If you don't allow components to mutate state locally, you need a strategy to distribute all your data directly from external stores to the correct components and also a strategy to send state updates back to the relevant stores. When you have multiple components which share some of the same data, this is impossible to do in an efficient and reliable way because of the latency between the external store and the components (components risk overwriting each other's data by sending conflicting updates, for example).
It's a logistical nightmare, because, without co-locating state with logic in some components, you cannot control how state updates are combined and then applied onto the external store. Components have no awareness of each other so they cannot coordinate. Every read and write has to go through the external store which is both inefficient and unreliable when you factor in latency. (The idea of caching violates FP principles).
The advantage of co-located state is that it can be updated synchronously without any latency so there is no possibility of conflicts.
>> If you don't allow components to mutate state locally,
Code mutation is, in my personal experience, a shit show. With Elixir, you I have to worry about some random process mutating your data because it can't, as it's literally immutable. I have never, not a single time, wished I could mutate a data structure in Elixir, because I can think of no case where it makes my life easier. Even quasi-objects, in the C++/Java OOP sense, like GenServers w/ internal state may appear to be mutating data from the outside, but from the inside they still rely on copying the data to update the state. It's so much easier for me to reason about.
Maybe different things simply appeal to different people. I could make arguments for OOP being harder to scale, but maybe that's just true for how my brain works.
Code mutation is, in my personal experience, a shit show. With Elixir, you I have to worry about some random process mutating your data because it can't, as it's literally immutable. I have never, not a single time, wished I could mutate a data structure in Elixir, because I can think of no case where it makes my life easier. Even quasi-objects, in the C++/Java OOP sense, like GenServers w/ internal state may appear to be mutating data from the outside, but from the inside they still rely on copying the data to update the state. It's so much easier for me to reason about.
Maybe different things simply appeal to different people. I could make arguments for OOP being harder to scale, but maybe that's just true for how my brain works.
State mutations are safe and easy to handle if the state is fully contained inside a blackbox (a class) and you only return copies of the state but never the actual references.
A blackbox should never expose object references (its internal state) to its parent components. It should also avoid passing object references to child components unless it's sure that the child component will never mutate this state in an unexpected way.
A blackbox should never expose object references (its internal state) to its parent components. It should also avoid passing object references to child components unless it's sure that the child component will never mutate this state in an unexpected way.
Obvious troll is obvious but... I assure you there are many high complexity systems in production today using FP that are not spaghetti code. Just like there are OOP codebases which are spaghetti, abstractions are used or abused. I’ve seen both very bad and very good Ruby projects. OOP wasn’t the direct reason why they were one or the other.
Inherited a couple projects. Was interested at first, but now dislike it. At this point I think I'm just done with languages that don't have static typing. I hate having to remember or figure out things that my tools should just be able to tell me. Unproductive waste of time & effort.
We're not using it with Phoenix, but I'm also very, very done with RoR—after many years using it and getting sick of how dependably any long-lived RoR project I encountered turned into an onboarding-hell mess of "WTF does this do even? Which gem is this from? Is it from a gem?"—to which Elixir + Phoenix is often compared, so I don't think that would improve my experience.
We're not using it with Phoenix, but I'm also very, very done with RoR—after many years using it and getting sick of how dependably any long-lived RoR project I encountered turned into an onboarding-hell mess of "WTF does this do even? Which gem is this from? Is it from a gem?"—to which Elixir + Phoenix is often compared, so I don't think that would improve my experience.
Nice question, I'm just starting with Elixir for a side project. Has anyone else find it to have a steep learning curve? Coming from Java/Scala and Python, I find it harder to wrap around then Scala was years ago. Shortcuts with mix like mix phx actually make it a bit more complicated for me because I'm used to understanding what is exactly happening under the hood.
My biggest hurdle was being too impatient to learn how to code with immutable data. I banged my head on the desk for two days to get through what I felt was a trivial problem (something with updating files in S3), which I eventually rewrote in python in less than an hour.
Immutability (and the resulting maintainability and predictability) is really appealing to me, though. When I try it again, I think I'll focus on educating myself around the language upfront and not just learning as I go.
Everything else about the language, Phoenix, and the tooling was really nice.
For the same reasons as others have said, I would not pick Elixir for a business, though.
Immutability (and the resulting maintainability and predictability) is really appealing to me, though. When I try it again, I think I'll focus on educating myself around the language upfront and not just learning as I go.
Everything else about the language, Phoenix, and the tooling was really nice.
For the same reasons as others have said, I would not pick Elixir for a business, though.
To answer your question, yes. My background is also primarily in Python (after brief flirtations with other languages during and shortly after college). When trying to learn Elixir (or Scheme, for that matter), my primary hurdle has been thinking in terms of idiomatic Elixir. The struggles aren’t with understanding the syntax (even for Scheme) but rather with understanding the typical patterns used such that I can start a project from scratch without heavy reliance on tutorial materials.
In other phrasing, I’ve quickly mastered the “draw three thin ovals” portion but am now stuck at “draw the rest of the phoenix”. Speaking of Phoenix, I also agree about “mix phx.gen” to be more magical than what I’m used to.
In other phrasing, I’ve quickly mastered the “draw three thin ovals” portion but am now stuck at “draw the rest of the phoenix”. Speaking of Phoenix, I also agree about “mix phx.gen” to be more magical than what I’m used to.
Getting hang of functional programming takes time. Writing code elixir way requires unlearning what you have learning from imperative languages.
I've used ocaml in the past and I not new to functional programming, but the whole Phoenix framework is somewhat confusing.
> Scala
Scala isn't exactly an imperative language. If anything it's the actor model isn't exactly easy to wrap your head around
Scala isn't exactly an imperative language. If anything it's the actor model isn't exactly easy to wrap your head around
> Java, Python
I was talking more about Java/Python. Also Scala has inheritance and OOP. Which don’t exist in elixir has only map.Map + additional field is struct in elixir.
Function capture, enumerations, pattern matching, implicit return and tuples returning status is what confuses new people.
Most try to implement some kind of inheritance in elixir.
Actor model is in OTP. Process, supervison, actor and messages are concepts of OTP. Elixir does not have actor in in its language constructs.
There is no replacement/alternative for OTP if you want distributed systems.
Many tried to reimplement Erlang in their languages and failed miserably.
I was talking more about Java/Python. Also Scala has inheritance and OOP. Which don’t exist in elixir has only map.Map + additional field is struct in elixir.
Function capture, enumerations, pattern matching, implicit return and tuples returning status is what confuses new people.
Most try to implement some kind of inheritance in elixir.
Actor model is in OTP. Process, supervison, actor and messages are concepts of OTP. Elixir does not have actor in in its language constructs.
There is no replacement/alternative for OTP if you want distributed systems.
Many tried to reimplement Erlang in their languages and failed miserably.
I’m about 18 months in, and I’m still loving Elixir.
I like the pipe syntax a lot. I dislike the fake type system, it some how the worst of both worlds. I regret having an elixir project.
I've been using Elixir for 4+ years, and I'm very happy with it. I'm a one-man band, so the talent pool isn't an issue.
My biggest joy is that once you get the application working, it stays working. I have ~20 production nodes, and they all just happily run. This was not my experience with Ruby and Rails.
It's not fun to try to interpret Erlang crash dumps, though.
My biggest joy is that once you get the application working, it stays working. I have ~20 production nodes, and they all just happily run. This was not my experience with Ruby and Rails.
It's not fun to try to interpret Erlang crash dumps, though.
We're using in a project (through Nerves framework) and slowly walking away from it. Hiring is the biggest hurdle; our product is simple enough that we can just have a bunch of .NET backend developers rewrite everything in Elixir. Hiring a .NET person is simple and cheap; hiring an Elixir dev is impossible where I live.
[deleted]
I work for an Elixir shop right now, and am very fresh (started a few months ago) and this is my first Elixir job.
My first impressions are that Elixir is different, but not necessarily better. Having come from Go, which is a very manual process, Elixir comes with a lot baked in.
With any niche language (which I consider Elixir to be) the benefits don't really kick in until the last 20% of adoption. The first 80% can be done by any language, with very little deviation from the other.
That last 20% is ETS, OTP, and other Elixir/Erlang-esque features, and I don't think 90% of the companies that adopt a language really gets into that level. Kubernetes, Caching, Horizontal Scaling is now so much easier and cheaper to bring in than an expert or the investment into the language that niche languages don't provide all that much value at this point.
My first impressions are that Elixir is different, but not necessarily better. Having come from Go, which is a very manual process, Elixir comes with a lot baked in.
With any niche language (which I consider Elixir to be) the benefits don't really kick in until the last 20% of adoption. The first 80% can be done by any language, with very little deviation from the other.
That last 20% is ETS, OTP, and other Elixir/Erlang-esque features, and I don't think 90% of the companies that adopt a language really gets into that level. Kubernetes, Caching, Horizontal Scaling is now so much easier and cheaper to bring in than an expert or the investment into the language that niche languages don't provide all that much value at this point.
I've used it for a few small production APIs, as well as internal TV dashboard things - and it works great!
There are a few business services that I would eventually like to move to it, but I don't have the time or resources currently. (As much as I like it, it's quite a shift mentally)
There are a few business services that I would eventually like to move to it, but I don't have the time or resources currently. (As much as I like it, it's quite a shift mentally)
I initially wrote the backend for my current startup in Elixir, using Phoenix. As many Elixir developers, I'm coming from the Ruby and Rails world. I really enjoyed the language and there are definitely things in Phoenix that are a vast improvement compared to what's available in Rails (changesets are awesome for instance).
However, after some weeks of development, I decided to move the project to Rails. We were still pre-launch so it didn't impact any users and only took a couple of days. The two main reasons for the move were:
1. *Ecosystem.* The Ruby and Rails ecosystem is just so much bigger and more mature. I cannot criticize Elixir for that, I'm just stating the fact. Ruby is many years advance and that shows in the breadth and maturity of libraries and deployment options. 2. *Re-learning basic things.* I found myself needing to learn how to do things in Elixir that I fully mastered in Ruby. I had to reinvent my own wheel in a way. And when you're trying to move fast to get your product out there, this is a waste of time.
In the end, I realized that for my purposes, Elixir/Phoenix is just not 10x better than Ruby/Rails. I can tell that learned from some of the mistakes of Ruby/Rails and many things are better. But they're not drastically better for the project that I'm building, which in the end is a GraphQL backend for a more-or-less CRUD mobile application.
Since the migration to Ruby, I'm much more productive and get things done much faster. I also spend a lot less time learning how to do X or Y. I felt relief when I didn't have to follow the Elixir ecosystem anymore and was able to unsubscribe from Elixir Newsletter and from the Elixir podcasts.
I know that my move does not help my criticism that the Elixir ecosystem is too small. But I value the success of my startup more than the need to help advance the Elixir world.
Maybe we will suffer long-term because of this choice, although examples like Shopify, Stripe or GitHub show that you can maintain massive codebases just fine in Ruby. But at this point of our startup, time to launch and velocity pretty much beats any other criteria.
However, after some weeks of development, I decided to move the project to Rails. We were still pre-launch so it didn't impact any users and only took a couple of days. The two main reasons for the move were:
1. *Ecosystem.* The Ruby and Rails ecosystem is just so much bigger and more mature. I cannot criticize Elixir for that, I'm just stating the fact. Ruby is many years advance and that shows in the breadth and maturity of libraries and deployment options. 2. *Re-learning basic things.* I found myself needing to learn how to do things in Elixir that I fully mastered in Ruby. I had to reinvent my own wheel in a way. And when you're trying to move fast to get your product out there, this is a waste of time.
In the end, I realized that for my purposes, Elixir/Phoenix is just not 10x better than Ruby/Rails. I can tell that learned from some of the mistakes of Ruby/Rails and many things are better. But they're not drastically better for the project that I'm building, which in the end is a GraphQL backend for a more-or-less CRUD mobile application.
Since the migration to Ruby, I'm much more productive and get things done much faster. I also spend a lot less time learning how to do X or Y. I felt relief when I didn't have to follow the Elixir ecosystem anymore and was able to unsubscribe from Elixir Newsletter and from the Elixir podcasts.
I know that my move does not help my criticism that the Elixir ecosystem is too small. But I value the success of my startup more than the need to help advance the Elixir world.
Maybe we will suffer long-term because of this choice, although examples like Shopify, Stripe or GitHub show that you can maintain massive codebases just fine in Ruby. But at this point of our startup, time to launch and velocity pretty much beats any other criteria.
We tried it and moved away from it. A few reasons - one is IDE support, which has been mentioned in this thread. The other was release configuration. At the time we were working on it, it was more difficult than it should have been to use env variables at runtime (rather than build time).
I'm used to the Spring Boot approach - start with having different Spring profiles for different environments, and then let your secrets come in via env vars, but doing this via Distillery at the time required some hackery - they wanted you to build a QA build and a prod build, which didn't make much sense. Maybe it's better now, but that turned me off a lot to using it.
I'm used to the Spring Boot approach - start with having different Spring profiles for different environments, and then let your secrets come in via env vars, but doing this via Distillery at the time required some hackery - they wanted you to build a QA build and a prod build, which didn't make much sense. Maybe it's better now, but that turned me off a lot to using it.
> Maybe it's better now, but that turned me off a lot to using it.
Sorry to hear KZeillmann! For those wondering, releases - which is one of the ways you package your Elixir project for production - are part of Elixir itself since v1.9 (~2 years ago) and reading secrets from env vars is supported out of the box. Just put the relevant code in the config/runtime.exs file.
Sorry to hear KZeillmann! For those wondering, releases - which is one of the ways you package your Elixir project for production - are part of Elixir itself since v1.9 (~2 years ago) and reading secrets from env vars is supported out of the box. Just put the relevant code in the config/runtime.exs file.
Here's my relevant post about choosing Elixir: https://lucjan.medium.com/choose-exciting-technology-e735bba...
TL;DR: very satisfied
TL;DR: very satisfied
[deleted]
3 years in and Elixir still rocks!
Very satisfied. Love writing it, and have seen it take root at other companies because devs exposed to it have loved it and taken it with them when they left.
Not exactly on topic, but does anyone have experience with the Akka ecosystem as an option to Elixir/Erlang? I'm considering it for a new project.
My 2c. I was learning Elixir / Phoenix for a startup but found it was missing way too many libraries & lacked the breadth & depth of the Stack Overflow knowledge base as compared to the Ruby on Rails ecosystem.
It was a cool experiment. Most devs would have learnt other Object Oriented Programming languages but learning Elixir would mean switching to a different paradigm.
It was a cool experiment. Most devs would have learnt other Object Oriented Programming languages but learning Elixir would mean switching to a different paradigm.
I use Elixir and don't regret it, but I'm still mostly in Erlang.
I regret "Elixir" the language itself. I feel they should have added a few more features to Erlang, like module parameters, and not bothered with Elixir.
It makes "Erlang" look superficially like Ruby and gets people who are ill-prepared to understand the Erlang mindset into the Erlang community.
I regret "Elixir" the language itself. I feel they should have added a few more features to Erlang, like module parameters, and not bothered with Elixir.
It makes "Erlang" look superficially like Ruby and gets people who are ill-prepared to understand the Erlang mindset into the Erlang community.
> It makes "Erlang" look superficially like Ruby and gets people who are ill-prepared to understand the Erlang mindset into the Erlang community.
I don't think it turned out to be true. For myself and many others, we wouldn't get into Beam without Elixir. As a Rubyist I don't understand what mindset I am missing?
I don't think it turned out to be true. For myself and many others, we wouldn't get into Beam without Elixir. As a Rubyist I don't understand what mindset I am missing?
I think perhaps you don't have the required superiority complex :)
What a silly gatekeepingmindset. Of course developers coming into a new paradigm are not going to immediately get it. That is the whole point of people being able to learn new things. If a Ruby dev starts learning Elixir and it's a steep curve for them, and they manage to do it, good on them!
I'm a Rails developer and have often wanted to try out Elixir but haven't found a compelling reason (or perhaps, project) to do so yet. Maybe I'll take the plunge and write my next app in it... Maybe get stuck in and try it on your next project too? I'd be interested to hear what you think as we're in similar positions I think.
You will enjoy OTP and Beam, But you will miss Ruby plug-ins.
If this is a personal project, go ahead and try it. See what you think.
If this is a project for a company, then look at the intersection of what they have in-house expertise in running and maintaining and what you know well, and use that. Probably going to be Ruby on Rails if that's your usual thing.
If this is a project for a company, then look at the intersection of what they have in-house expertise in running and maintaining and what you know well, and use that. Probably going to be Ruby on Rails if that's your usual thing.
I’ve been working with Elixir for a variety of use-cases for years and I just love it.
The only problem we had is the obvious: You don’t have all the libraries you will find in JS or Python. But usually is easy to dig into the oss libraries and create a PR, and the community is amazing!
I don't like the operators' logic in elixir. There should be one for assigning variables, one for pattern matching and there is no rebinding of variables.
Something like:
Something like:
//for assignment
x = 1
//for pattern matching
x == 1
Then what would you use for testing equality?
And what would you use if you were pattern matching _and_ assigning in the same statement? I.e.
And what would you use if you were pattern matching _and_ assigning in the same statement? I.e.
{:ok, value} = function()Could be like that:
// equality with is already
Automatically translated.
// equality with is already
1 == 1.0 //true
1 === 1.0 //false
x = 1
x ^ 1
x =^ 1 or x ^= 1
Automatically translated.
The more I use and learn languages the more I prefer Elixir's (to be honest, Erlang's) programming model. I'm not a types person (yet) so that is not as important to me as the building blocks and how it allows you to organise programs.
I think the first question you should ask yourself is, do you expect the same level of "pick a lib, drop a lib" as you would in RoR, or Nodejs? I haven't had any problem with libs, basically because I'm ok with writing http requests if I need to, or do an auth flow myself - it's not like those things are complex - but the first times it might take you more time than just picking something off that works immediately. On the other hand, the core of what I usually need, is pretty sturdy and extendable - Phoenix/Websockets/Ecto(Postgresql, you might have a different exp with other dbs)/Oban and the standard lib/erlang for all sorts of things that in many languages require external libs (or aren't really doable without taking a sabbatical).
Also I don't know if I live in a parallel world, but in many other languages, even ones with pretty heavy investing, many libraries that aren't just translating http responses into whatever language representation of that, are subpar, or not extendable, or you need to almost learn a new language to use them, they're solving things that shouldn't be a library. There's plenty of good libraries out there, including in nodejs, but comparing for instance its ecosystem is kinda pointless, when perhaps 90% of the libs in there don't really warrant existing, or are to cover basic shortcomings or don't solve really anything, or are specific to being run in a browser.
The second is, are you curious enough about the underlying mechanics and learning the programming model? This is sort of essential, because in most languages/VMs everything is sort of a single program, where all things sprawl from a form of "main()", and in Erlang you organise (or should) your application as many different "main()"s, it's almost like an OS. It's still obviously started from a single point, but once started it's like having multiple applications running in a concerted fashion. There's a curve to learning how to leverage that - and to be honest, not all problems require that - although again, the more I see other languages and use them the more I miss the structured form of programs it allows.
The third is, it's a functional language - if you're not used to it in any way some ways of solving problems might not be apparent immediately - they're not more difficult or complex, they're just different - for me solving problems with OOP is also not straightforward - it doesn't mean it's worse, I just don't practice it as much as I do functional programming. There's also obviously problems that are much better expressible with mutable data, but you have enough scape hatches for those cases that really need it - on the upside there's also plenty of problems that are better expressed in functional languages.
Lastly, some useful patterns and ways of doing things require some "acclimatisation", like using pattern matching to describe functions, conditions, and execution paths, ditching almost completely (almost) exceptions and throws in favour of tagged returns, building reliable sync/async flows etc. The testing history in my view is excellent, as are the tools it includes, mix, iex, releases, and overall I would say it made me a much better programmer. I also would take some people's shitting directly on the language or libs complaints with a grain of salt - I've seen a fair bit of idiotic uses of stuff in it (like holding a hammer by the head), and in those cases ask yourself if the libraries and programs other's use or suggest instead are good software and evaluate them in the same context - complete external tools run by companies vs basic stdlib functionality.
I think the first question you should ask yourself is, do you expect the same level of "pick a lib, drop a lib" as you would in RoR, or Nodejs? I haven't had any problem with libs, basically because I'm ok with writing http requests if I need to, or do an auth flow myself - it's not like those things are complex - but the first times it might take you more time than just picking something off that works immediately. On the other hand, the core of what I usually need, is pretty sturdy and extendable - Phoenix/Websockets/Ecto(Postgresql, you might have a different exp with other dbs)/Oban and the standard lib/erlang for all sorts of things that in many languages require external libs (or aren't really doable without taking a sabbatical).
Also I don't know if I live in a parallel world, but in many other languages, even ones with pretty heavy investing, many libraries that aren't just translating http responses into whatever language representation of that, are subpar, or not extendable, or you need to almost learn a new language to use them, they're solving things that shouldn't be a library. There's plenty of good libraries out there, including in nodejs, but comparing for instance its ecosystem is kinda pointless, when perhaps 90% of the libs in there don't really warrant existing, or are to cover basic shortcomings or don't solve really anything, or are specific to being run in a browser.
The second is, are you curious enough about the underlying mechanics and learning the programming model? This is sort of essential, because in most languages/VMs everything is sort of a single program, where all things sprawl from a form of "main()", and in Erlang you organise (or should) your application as many different "main()"s, it's almost like an OS. It's still obviously started from a single point, but once started it's like having multiple applications running in a concerted fashion. There's a curve to learning how to leverage that - and to be honest, not all problems require that - although again, the more I see other languages and use them the more I miss the structured form of programs it allows.
The third is, it's a functional language - if you're not used to it in any way some ways of solving problems might not be apparent immediately - they're not more difficult or complex, they're just different - for me solving problems with OOP is also not straightforward - it doesn't mean it's worse, I just don't practice it as much as I do functional programming. There's also obviously problems that are much better expressible with mutable data, but you have enough scape hatches for those cases that really need it - on the upside there's also plenty of problems that are better expressed in functional languages.
Lastly, some useful patterns and ways of doing things require some "acclimatisation", like using pattern matching to describe functions, conditions, and execution paths, ditching almost completely (almost) exceptions and throws in favour of tagged returns, building reliable sync/async flows etc. The testing history in my view is excellent, as are the tools it includes, mix, iex, releases, and overall I would say it made me a much better programmer. I also would take some people's shitting directly on the language or libs complaints with a grain of salt - I've seen a fair bit of idiotic uses of stuff in it (like holding a hammer by the head), and in those cases ask yourself if the libraries and programs other's use or suggest instead are good software and evaluate them in the same context - complete external tools run by companies vs basic stdlib functionality.
It is hard to find learning resources when trying to write NIFs for BEAM. The documentation and bindings are fine if you are using C, but when using some rarer programming language it can be quite difficult to get along.
[deleted]
I think it's the greatest thing ever. I wrote like 300 words over two blog posts here: https://amattn.com/p/the_sublime_developer_efficiency_of_eli...
tldr:
- It’s quirky - There’s a learning curve - Taking the time to climb that curve can result in elegant solutions - The endgame is high developer efficiency
Not only that, but I find it fun and enjoyable. The ecosystem isn't the largest, but the other positives more than make up for the deficits for me.
I only started learning elixir around November or so last year and I've launched two SaaS products in the past 6 months.
tldr:
- It’s quirky - There’s a learning curve - Taking the time to climb that curve can result in elegant solutions - The endgame is high developer efficiency
Not only that, but I find it fun and enjoyable. The ecosystem isn't the largest, but the other positives more than make up for the deficits for me.
I only started learning elixir around November or so last year and I've launched two SaaS products in the past 6 months.
I use Erlang, Is Elixir a better alternative now?
Answer is always no. Erlang is not better than Elixir. Elixir is not better than Erlang.
I've been a senior or staff engineer at several companies companies that have their backend tech stacks either primarily or entirely in Elixir. Two of those companies are now unicorns, Divvy (my current company) and Podium. I've seen elixir work great for small teams (~10-15 engineers total) and scale for that company as it went to 100-200 engineers.
Engineers at both unicorn companies consider Elixir one of the reasons they were able to grow the way they did, both in terms of customer count and engineers. Sure, it was hard to find people who had production experience with the language. Didn't really matter; deploy it with Docker (and eventually Kubernetes) the way you would anything else, and if you need clustering then libcluster can manage most of that for you.
Learning OTP is a nice-to-have, but 98% of the time your devs don't actually need in-depth understanding of it (assuming you're a typical web-based startup). Web servers hitting a database is naturally pretty scalable as long as you design your database decently. Scaling your database is _way_ more important to scaling technical systems than your choice of programming language.
Even if your team doesn't need a deep understanding of OTP, _you_ should have a good understanding of GenServer, GenStatem, Application, and Supervisor so you can evaluate 3rd party libs or develop in-house libs. Most devs who are working in product need to focus more on how to write well-factored code to interact with data services like Postgres, Redis, or Kafka.
Yeah, there's a lot of hype around hot code loading, ETS, Mnesia, and the like. Don't use them unless you absolutely have to. ETS is fine for a local cache once you have a generic garbage-collector as long as you don't care about losing that cache on deploy. You probably care, so just use Redis most of the time.
The claim that it's impossible to hire Elixir devs is way overblown. Just hire smart people; software engineering principles are applicable across languages even if the languages have different paradigms. You might have to find new ways of implementing those principles, but discussions around good boundaries and extensible code are more important than "when should I use if vs case vs cond vs pattern-match in a function head?". Podium hired a _lot_ of engineers right out of dev bootcamps. They paid for that in code quality for sure, but even the most green engineers were able to get going in Elixir pretty quickly. As long as you have one or two "seed" engineers who are willing and able to teach others, the hiring problem isn't really a problem.
I'll get a lot of flack for this one, but if your company has a monolithic codebase, Umbrella Applications are a great way to enforce internal boundaries if you're on Elixir 1.11 and have warnings-as-errors set up. Keep splitting any sub-apps that start getting large and the warnings-as-errors will prevent circular dependency hell for you.
If you're doing a service-oriented or microservices architecture, Elixir is pretty great. Synchronous communication is pretty easy to set up if you want synchronous communication; Absinthe makes a great API gateway, gRPC support is decent on both the client and server sides (though testing still needs to be improved with the gRPC lib...)
If you're using plain ol' HTTP, there are a plethora of HTTP client libs that scale well (and a number that don't without effort - some painful lessons at Divvy on that one). Phoenix is a great HTTP server framework, and LiveView is great if you don't want your team to have specialized frontend vs backend devs or get an MVP off the ground.
Kafka support is... fine, I guess. As long as you only need basic Consumer/Publisher capabilities, anyways. If you need anything more advanced, you have to go somewhere else to get the stateful processing capabilities that Flink or Kafka Streams or KSQL will give you.
Redis support is good, with varying options for high-level vs low-level implementations.
The hardest part of working in the ecosystem is the ecosystem itself. The built-in tooling is amazing, but Ruby/Java/JS/<insert other top 10 tiobe language here> will always have a larger selection of libraries.
Engineers at both unicorn companies consider Elixir one of the reasons they were able to grow the way they did, both in terms of customer count and engineers. Sure, it was hard to find people who had production experience with the language. Didn't really matter; deploy it with Docker (and eventually Kubernetes) the way you would anything else, and if you need clustering then libcluster can manage most of that for you.
Learning OTP is a nice-to-have, but 98% of the time your devs don't actually need in-depth understanding of it (assuming you're a typical web-based startup). Web servers hitting a database is naturally pretty scalable as long as you design your database decently. Scaling your database is _way_ more important to scaling technical systems than your choice of programming language.
Even if your team doesn't need a deep understanding of OTP, _you_ should have a good understanding of GenServer, GenStatem, Application, and Supervisor so you can evaluate 3rd party libs or develop in-house libs. Most devs who are working in product need to focus more on how to write well-factored code to interact with data services like Postgres, Redis, or Kafka.
Yeah, there's a lot of hype around hot code loading, ETS, Mnesia, and the like. Don't use them unless you absolutely have to. ETS is fine for a local cache once you have a generic garbage-collector as long as you don't care about losing that cache on deploy. You probably care, so just use Redis most of the time.
The claim that it's impossible to hire Elixir devs is way overblown. Just hire smart people; software engineering principles are applicable across languages even if the languages have different paradigms. You might have to find new ways of implementing those principles, but discussions around good boundaries and extensible code are more important than "when should I use if vs case vs cond vs pattern-match in a function head?". Podium hired a _lot_ of engineers right out of dev bootcamps. They paid for that in code quality for sure, but even the most green engineers were able to get going in Elixir pretty quickly. As long as you have one or two "seed" engineers who are willing and able to teach others, the hiring problem isn't really a problem.
I'll get a lot of flack for this one, but if your company has a monolithic codebase, Umbrella Applications are a great way to enforce internal boundaries if you're on Elixir 1.11 and have warnings-as-errors set up. Keep splitting any sub-apps that start getting large and the warnings-as-errors will prevent circular dependency hell for you.
If you're doing a service-oriented or microservices architecture, Elixir is pretty great. Synchronous communication is pretty easy to set up if you want synchronous communication; Absinthe makes a great API gateway, gRPC support is decent on both the client and server sides (though testing still needs to be improved with the gRPC lib...)
If you're using plain ol' HTTP, there are a plethora of HTTP client libs that scale well (and a number that don't without effort - some painful lessons at Divvy on that one). Phoenix is a great HTTP server framework, and LiveView is great if you don't want your team to have specialized frontend vs backend devs or get an MVP off the ground.
Kafka support is... fine, I guess. As long as you only need basic Consumer/Publisher capabilities, anyways. If you need anything more advanced, you have to go somewhere else to get the stateful processing capabilities that Flink or Kafka Streams or KSQL will give you.
Redis support is good, with varying options for high-level vs low-level implementations.
The hardest part of working in the ecosystem is the ecosystem itself. The built-in tooling is amazing, but Ruby/Java/JS/<insert other top 10 tiobe language here> will always have a larger selection of libraries.
Can I ask what HTTP library did you end up with? Thanks.
Happy to have stayed away from it ever since.
This question reminds me of a story about Yahoo! Stores, which came out of Yahoo!’s acquisition of Viaweb, cofounded by PG. As he has frequently mentioned, Viaweb was written in Lisp and he felt they got an inherent advantage by using Lisp [0].
Several years after Yahoo! acquired Viaweb I was having lunch with the then-VP in charge of Stores and other business products, who was not from the original Viaweb team. The Yahoo! team was rewriting Stores in C++ (and Perl, apparently from a current Google search, although I only remember him mentioning C++). He kind of rolled his eyes when he said for some reason the original team wrote it in Lisp. He said it was hard to hire Lisp programmers to join the team.
PG was not well-known yet, so even if we could just search the web to find his reasoning for using Lisp (the article was written in 2001), we wouldn’t have thought of searching. But even if we had found it, I don’t think it would have mattered. There’s a different set of advantages and tradeoffs for a small team building a new product, when they are focused on fast development and growth and they come from a similar background, vs. a team in a larger company that has people coming and going and wants the ability to hire from the general developer pool without having to train everyone on a less-common language.
Disclaimers: this is a generalization, of course. You might be able to point to counterexamples. Some larger companies are more willing to hire language specialists and experts.
I’m just relaying what I was told. Please don’t angrily debate me on the benefits of languages like Elixir and Lisp. Your anger would be misplaced. Personally I absolutely love those kinds of languages and would much, much rather use them than something like Java [1]. That’s why I stayed a hacker my whole career and never became a manager.
[0] http://www.paulgraham.com/avg.html
[1] http://www.paulgraham.com/javacover.html
Several years after Yahoo! acquired Viaweb I was having lunch with the then-VP in charge of Stores and other business products, who was not from the original Viaweb team. The Yahoo! team was rewriting Stores in C++ (and Perl, apparently from a current Google search, although I only remember him mentioning C++). He kind of rolled his eyes when he said for some reason the original team wrote it in Lisp. He said it was hard to hire Lisp programmers to join the team.
PG was not well-known yet, so even if we could just search the web to find his reasoning for using Lisp (the article was written in 2001), we wouldn’t have thought of searching. But even if we had found it, I don’t think it would have mattered. There’s a different set of advantages and tradeoffs for a small team building a new product, when they are focused on fast development and growth and they come from a similar background, vs. a team in a larger company that has people coming and going and wants the ability to hire from the general developer pool without having to train everyone on a less-common language.
Disclaimers: this is a generalization, of course. You might be able to point to counterexamples. Some larger companies are more willing to hire language specialists and experts.
I’m just relaying what I was told. Please don’t angrily debate me on the benefits of languages like Elixir and Lisp. Your anger would be misplaced. Personally I absolutely love those kinds of languages and would much, much rather use them than something like Java [1]. That’s why I stayed a hacker my whole career and never became a manager.
[0] http://www.paulgraham.com/avg.html
[1] http://www.paulgraham.com/javacover.html
Clarification on my last sentence: it’s not that managers code in languages like Java. It’s that managers have different priorities, such as hiring. In my experience those priorities lead to different technology decisions.
Any comments on BEAM as it pertains to security? Is it ripe for being picked apart for vulnerabilities? Could these be exploited remotely via Elixir/Erlang web applications?
My advice, not that anyone is asking, is only do Elixir if you love it. If you are doing it expecting it to become the next Node thats definitely not happening.