4 ms·

Could someone with professional experience int Elixir give an overview of what's the ecosystem like? It's hard to imagine working with such a niche language. H

Could someone with professional experience int Elixir give an overview of what's the ecosystem like? It's hard to imagine working with such a niche language. How easy is it to find quality libraries? Connectors to external systems? Tooling? Someone to ask when running into problems? Also, what's the market like for Elixir developers? Did you learn the language on the job? For a specific project? In your spare time?

minhajuddin 7y ago
The Elixir ecosystem is really healthy. You can find almost any package you want on hex (https://hex.pm/ https://hex.pm/). Moreover, because it is built on top of erlang you can seamlessly use any Erlang code (which a lot of Elixir apps use). You can usually find high-quality libraries with a google search or looking at the number of stars of a hex package. Mix, the build tool is awesome and the language now has out of the box support for creating deployment releases. There are a lot of high paying jobs for Elixir.
verttii 7y ago
It really depends where you're coming from. If you're from the enterprise world I'd expect you'll find the ecosystem limited for anything else than web related, maybe even for enterprise web integrations. If you're coming from something even more niche (for web) like Haskell you'll think the ecosystem is flourishing. Libraries are generally of good quality and reasonably well documented. The community is very energetic and supportive. Moreover, there's an exceptional range of libraries and solutions available for certain problem domains in which the Erlang platform excels such as distributed concurrency and soft real-time applications in general. If the problems you work on fall outside of the web sphere Elixir is not a good fit generally.
- elcritch 7y ago
  I can’t agree about the "just web dev" part. After using Elixir extensively in embedded devices it’s been fantastic. Some libraries are lacking, especially scientific. Still I find the time implementing say, polynomial curve fitting, to be more than compensated for by the robustness of the architecture and avoiding the quagmire of OOP code. It’s actually kind of fun to me using Elixir/BEAM for data processing.
  - verttii 7y ago
    Fair enough, I should've put it more general like "distributed computing". Something that does networking stuff and prioritizes low latency instead of high throughput.
    - anko 7y ago
      I find the "high throughput" comment a bit weird, but i've seen it a lot of times. Do you mind drilling into it a bit more? I see posts like this https://blog.discordapp.com/scaling-elixir-f9b8e1e7c29b https://blog.discordapp.com/scaling-elixir-f9b8e1e7c29b where they are talking millions of events per second. I also work in the distributed messaging space and so far my experiments have shown elixir to be able to keep up with our scala stack with the advantages of no thread tuning and much easier debugging. So I'm curious why this keeps popping up.
      - elcritch 7y ago
        Perhaps it’s in reference to compute throughput or disk io? BEAM doesn’t do quite as well in those areas. Not bad but ok. I just did some micro benchmarks on matrex compared to numpy and surprisingly the Elixir nif’s were about 10% faster on my MacBook. Dirty threads have helped nif’s on providing compute throughput too.
      - verttii 7y ago
        My point was rather that that's where Elixir excels. Throughput is always a compromise with latency in garbage collectors and schedulers. Elixir prioritizes low consistent latency with its garbage collector and preemptive scheduling. Whereas many other systems, such as Haskell's GHC compiler/runtime prioritize high throughput instead for better computational performance. All the computations have to run inside a process in Elixir. Erlang's platform constrains each process so that any single process cannot hog all the resources available. Therefore, you need to split the computation to many processes when you do CPU intensive work. And processes carry message passing overhead, leading to reduced maximum throughput. Something like lots of small messages with minimal processing (think: chat) over a bunch of network connections sounds like the ideal sweet spot for Elixir.
hew 7y ago
Learned on the job. Previous professional background PHP, JS. Beginner to what I think to be competent ("full stack", a range between infra and clustered prod deployments to page layouts in Phoenix LiveView) in about four months. I've been able to find high quality Elixir packages without trouble. I haven't had to fall back to Erlang packages for any holes but I feel confident because I could.
techacolyte42 7y ago
I use Elixir about 30% of my time at work. I feel like 75% of my code/architectural sense comes from studying how the Elixir community does things - the quality of discussion in the forums and issue trackers is amazing and generally packages feel quite comprehensible. It's a breath of fresh air and clarity after React Native and Rails - there are a lot more resources for those two, but I find myself doing a lot more digging through noise. Learned on the job, I get a little recruiter email about Elixir specifically but there are definitely less companies that use it. There's reasonable chance I'll end up in Go or Clojure for my next position but even if I were to never use Elixir again the learning will have been worth it.
AlchemistCamp 7y ago
> Did you learn the language on the job? For a specific project? In your spare time? I moved my last startup to Elixir due to some pretty harsh constraints: 1) I was a the sole developer of a complex app 2) It involved real-time chat and WebRTC 3) Most of its users were in SE Asia and it was a freemium model This meant I needed a highly productive framework and neither Rails or Laravel were great choices from a technical perspective or in terms of server costs. Phoenix Presence was also a major bonus since there are so many edge cases around (chat room) presence that are easy to mess up when users have multiple devices. That specific need pushed me to learn the language, and it was such a great experience that I made it my go-to for all web development. > How easy is it to find quality libraries? I've been very pleased with the quality of the libraries. Elixir tends to draw more experienced developers and I don't see as much "resume-driven Github" behavior, though of course some is inevitable. There's also usually a clear choice of library to use for a given goal, which is a huge plus over the JS ecosystem. There are a lot of useful libraries out there in the Rails and Laravel ecosystems that I wish existed for Elixir, though. Probably the most frustrating thing on the libraries side is the lack of first-party libraries from companies such as Stripe. Many company's API docs generally assume the user is pulling in their first-party Ruby/PHP/Java/JS/Python/etc library and Elixir usually doesn't make the list. > Tooling? The tooling was a big step up from what I was used to! Zero complaints there, except a few minor ones if you're running on Windows. > Someone to ask when running into problems? I've had hit and miss experiences with the Slack channel, but the forum is pretty much the best Q/A experience I've ever had for technical issues. > Also, what's the market like for Elixir developers? It used to be easy to hire them since there were a lot of people who wanted to use it and not so many companies hiring for it. Now, it seems a bit more balanced.
dobs 7y ago
I feel like my experiences are in sharp contrast to many others here. I love Elixir the language but find myself still having to throughly review new libraries to avoid footguns. In particular with "connectors" -- DB drivers, API clients, basic protocol implementations, etc. And resolving those issues normally means fixing them ourselves, often with a significant refactor to someone else's library. And in turn that's meant some of us having to become fairly proficient with Erlang. So while I'm optimistic about the future of Elixir there are still some pain points that I think relate directly to the immaturity of the community.
- elcritch 7y ago
  Are many of these issues related more to older Erlang libraries? Most all of the Elixir libraries that aren’t a WIP have been pretty good for me. Just curious which sort of protocols too. Not always, but I do find older Erlang libraries often lack unit testing and consistent doc tooling, likely due to lack of tooling in earlier days.
  - dobs 7y ago
    Probably 50/50 old (but popular) Erlang libraries and newer Elixir libraries. For protocols, we have a not-uncommon use case for which there’s no mature HTTP client. Mint might be an option but it’s new enough that I haven’t evaluated yet.
- verttii 7y ago
  I actually have a similar experience. This is basically due to having no type system, at least the problems we've encountered.
conradfr 7y ago
As someone casually looking for Elixir opportunities in Paris, France my observation is that there's not a lot of them (expected), and usually come with a RoR requirement (expected as well, I guess). Also it seems some companies rewrite their Elixir services in Go?
- jaynetics 7y ago
  I've made the same observation in Berlin. Not a lot of job offers, and those that exist are more like "yeah, we're also trying out a bit of Elixir in our stack...". Such a shame.
lawik 7y ago
A few years back I wanted to try it for a microservice but found it didn't integrate with our system because of missing features in the ZeroMQ libs of the time. So there are and were corners where things aren't fully fleshed out. I imagine you can find these odd corners in most ecosystems. I've been happy with the libraries I've found and used in general. All the common web stuff seems to be there. ExAws solves most of the cloud integration I've dealt with. But I don't imagine I'd find a selection of high-level, highly ergonomic Google Sheets libraries the way you would in Python. Not yet. I'd say its still early days but healthy for the job market. I've found freelance work with an Elixir shop recently which is fun. But it is nowhere near Python, JS and all. Still, plenty of people making a living as employees or long-term contractors doing it. And it seems to be growing at a steady rate. I'm hopeful. Learned it out of interest. Tracked down my current client through the Elixir Slack actually.

minhajuddin 7y ago

The Elixir ecosystem is really healthy. You can find almost any package you want on hex (https://hex.pm/ https://hex.pm/). Moreover, because it is built on top of erlang you can seamlessly use any Erlang code (which a lot of Elixir apps use). You can usually find high-quality libraries with a google search or looking at the number of stars of a hex package. Mix, the build tool is awesome and the language now has out of the box support for creating deployment releases. There are a lot of high paying jobs for Elixir.

verttii 7y ago

It really depends where you're coming from. If you're from the enterprise world I'd expect you'll find the ecosystem limited for anything else than web related, maybe even for enterprise web integrations. If you're coming from something even more niche (for web) like Haskell you'll think the ecosystem is flourishing. Libraries are generally of good quality and reasonably well documented. The community is very energetic and supportive. Moreover, there's an exceptional range of libraries and solutions available for certain problem domains in which the Erlang platform excels such as distributed concurrency and soft real-time applications in general. If the problems you work on fall outside of the web sphere Elixir is not a good fit generally.

elcritch 7y ago
I can’t agree about the "just web dev" part. After using Elixir extensively in embedded devices it’s been fantastic. Some libraries are lacking, especially scientific. Still I find the time implementing say, polynomial curve fitting, to be more than compensated for by the robustness of the architecture and avoiding the quagmire of OOP code. It’s actually kind of fun to me using Elixir/BEAM for data processing.
- verttii 7y ago
  Fair enough, I should've put it more general like "distributed computing". Something that does networking stuff and prioritizes low latency instead of high throughput.
  - anko 7y ago
    I find the "high throughput" comment a bit weird, but i've seen it a lot of times. Do you mind drilling into it a bit more? I see posts like this https://blog.discordapp.com/scaling-elixir-f9b8e1e7c29b https://blog.discordapp.com/scaling-elixir-f9b8e1e7c29b where they are talking millions of events per second. I also work in the distributed messaging space and so far my experiments have shown elixir to be able to keep up with our scala stack with the advantages of no thread tuning and much easier debugging. So I'm curious why this keeps popping up.
    - elcritch 7y ago
      Perhaps it’s in reference to compute throughput or disk io? BEAM doesn’t do quite as well in those areas. Not bad but ok. I just did some micro benchmarks on matrex compared to numpy and surprisingly the Elixir nif’s were about 10% faster on my MacBook. Dirty threads have helped nif’s on providing compute throughput too.
    - verttii 7y ago
      My point was rather that that's where Elixir excels. Throughput is always a compromise with latency in garbage collectors and schedulers. Elixir prioritizes low consistent latency with its garbage collector and preemptive scheduling. Whereas many other systems, such as Haskell's GHC compiler/runtime prioritize high throughput instead for better computational performance. All the computations have to run inside a process in Elixir. Erlang's platform constrains each process so that any single process cannot hog all the resources available. Therefore, you need to split the computation to many processes when you do CPU intensive work. And processes carry message passing overhead, leading to reduced maximum throughput. Something like lots of small messages with minimal processing (think: chat) over a bunch of network connections sounds like the ideal sweet spot for Elixir.

hew 7y ago

Learned on the job. Previous professional background PHP, JS. Beginner to what I think to be competent ("full stack", a range between infra and clustered prod deployments to page layouts in Phoenix LiveView) in about four months. I've been able to find high quality Elixir packages without trouble. I haven't had to fall back to Erlang packages for any holes but I feel confident because I could.

techacolyte42 7y ago

I use Elixir about 30% of my time at work. I feel like 75% of my code/architectural sense comes from studying how the Elixir community does things - the quality of discussion in the forums and issue trackers is amazing and generally packages feel quite comprehensible. It's a breath of fresh air and clarity after React Native and Rails - there are a lot more resources for those two, but I find myself doing a lot more digging through noise. Learned on the job, I get a little recruiter email about Elixir specifically but there are definitely less companies that use it. There's reasonable chance I'll end up in Go or Clojure for my next position but even if I were to never use Elixir again the learning will have been worth it.

AlchemistCamp 7y ago

> Did you learn the language on the job? For a specific project? In your spare time? I moved my last startup to Elixir due to some pretty harsh constraints: 1) I was a the sole developer of a complex app 2) It involved real-time chat and WebRTC 3) Most of its users were in SE Asia and it was a freemium model This meant I needed a highly productive framework and neither Rails or Laravel were great choices from a technical perspective or in terms of server costs. Phoenix Presence was also a major bonus since there are so many edge cases around (chat room) presence that are easy to mess up when users have multiple devices. That specific need pushed me to learn the language, and it was such a great experience that I made it my go-to for all web development. > How easy is it to find quality libraries? I've been very pleased with the quality of the libraries. Elixir tends to draw more experienced developers and I don't see as much "resume-driven Github" behavior, though of course some is inevitable. There's also usually a clear choice of library to use for a given goal, which is a huge plus over the JS ecosystem. There are a lot of useful libraries out there in the Rails and Laravel ecosystems that I wish existed for Elixir, though. Probably the most frustrating thing on the libraries side is the lack of first-party libraries from companies such as Stripe. Many company's API docs generally assume the user is pulling in their first-party Ruby/PHP/Java/JS/Python/etc library and Elixir usually doesn't make the list. > Tooling? The tooling was a big step up from what I was used to! Zero complaints there, except a few minor ones if you're running on Windows. > Someone to ask when running into problems? I've had hit and miss experiences with the Slack channel, but the forum is pretty much the best Q/A experience I've ever had for technical issues. > Also, what's the market like for Elixir developers? It used to be easy to hire them since there were a lot of people who wanted to use it and not so many companies hiring for it. Now, it seems a bit more balanced.

dobs 7y ago

I feel like my experiences are in sharp contrast to many others here. I love Elixir the language but find myself still having to throughly review new libraries to avoid footguns. In particular with "connectors" -- DB drivers, API clients, basic protocol implementations, etc. And resolving those issues normally means fixing them ourselves, often with a significant refactor to someone else's library. And in turn that's meant some of us having to become fairly proficient with Erlang. So while I'm optimistic about the future of Elixir there are still some pain points that I think relate directly to the immaturity of the community.

elcritch 7y ago
Are many of these issues related more to older Erlang libraries? Most all of the Elixir libraries that aren’t a WIP have been pretty good for me. Just curious which sort of protocols too. Not always, but I do find older Erlang libraries often lack unit testing and consistent doc tooling, likely due to lack of tooling in earlier days.
- dobs 7y ago
  Probably 50/50 old (but popular) Erlang libraries and newer Elixir libraries. For protocols, we have a not-uncommon use case for which there’s no mature HTTP client. Mint might be an option but it’s new enough that I haven’t evaluated yet.
verttii 7y ago
I actually have a similar experience. This is basically due to having no type system, at least the problems we've encountered.

conradfr 7y ago

As someone casually looking for Elixir opportunities in Paris, France my observation is that there's not a lot of them (expected), and usually come with a RoR requirement (expected as well, I guess). Also it seems some companies rewrite their Elixir services in Go?

jaynetics 7y ago
I've made the same observation in Berlin. Not a lot of job offers, and those that exist are more like "yeah, we're also trying out a bit of Elixir in our stack...". Such a shame.

lawik 7y ago

A few years back I wanted to try it for a microservice but found it didn't integrate with our system because of missing features in the ZeroMQ libs of the time. So there are and were corners where things aren't fully fleshed out. I imagine you can find these odd corners in most ecosystems. I've been happy with the libraries I've found and used in general. All the common web stuff seems to be there. ExAws solves most of the cloud integration I've dealt with. But I don't imagine I'd find a selection of high-level, highly ergonomic Google Sheets libraries the way you would in Python. Not yet. I'd say its still early days but healthy for the job market. I've found freelance work with an Elixir shop recently which is fun. But it is nowhere near Python, JS and all. Still, plenty of people making a living as employees or long-term contractors doing it. And it seems to be growing at a steady rate. I'm hopeful. Learned it out of interest. Tracked down my current client through the Elixir Slack actually.