It's also the best ecosystem for indie/small team development. With a handful of well-established libraries, one can go a long way without having to reach for separate/dedicated queue/messaging systems, job or workflow orchestrations, even spinning up an ephemeral machine just to run heavy workloads is not complex. Frameworks like Ash make an entire category of server applications a matter of a few declarative modules.
I know a team using it to replace ancient massive mainframe based systems with modern distributed systems and the gist is that the language is fine, but mostly ideal for use cases that leverage the ErlangVM or BEAM stack.
The downside they run into is the ecosystem isnt there, at least a couple guys wish they had just used Kotlin/Java for library interoperability with so much existing code already built and battle tested for specific purposes.
To put it simply, the BEAM lets you swallow all of your dependent services into a consistent API, no matter network distance or machine dependability. In Python it feels like my main thread, DB, job queue, and OS are all speaking different languages. With Elixir I don't spend much time at all getting different services to work together, at least an order of magnitude less.
Elixir is not perfect, but for me working alone dependency hell was the bottleneck with Python. Now the bottleneck is adding features, which is right where it should be.
I think in many cases the ecosystem issues are overblown. For the common 90% of use cases there are battle tested libraries out there.
For the less common ones, we tend to just roll our own which in most cases isn't that bad if you have reference implementations.
I think the most under-appreciated aspect of Elixir is how it helps reduce complexity. And there isn't a silver bullet here, but the tooling, immutability, pattern matching, process-based concurrency model, etc are all design decisions that, IMHO lead to simpler, more robust code.
(Caveat: of course, like any language, you can make a mess of things.)
I think that's a good point. Our largest pain point with Elixir is definitely the size of the community and the associated dearth of niche libraries. The technology behind it, though, is solid enough that once those libraries exist, things really take off. My team wrote several open source medical libraries for Elixir and we've seen it really expand into the healthcare market.
It's also the best ecosystem for indie/small team development. With a handful of well-established libraries, one can go a long way without having to reach for separate/dedicated queue/messaging systems, job or workflow orchestrations, even spinning up an ephemeral machine just to run heavy workloads is not complex. Frameworks like Ash make an entire category of server applications a matter of a few declarative modules.
Out of curiosity, what does one use for distributed storage in Elixir ?
What makes you say that? Honestly asking.
I know a team using it to replace ancient massive mainframe based systems with modern distributed systems and the gist is that the language is fine, but mostly ideal for use cases that leverage the ErlangVM or BEAM stack.
The downside they run into is the ecosystem isnt there, at least a couple guys wish they had just used Kotlin/Java for library interoperability with so much existing code already built and battle tested for specific purposes.
To put it simply, the BEAM lets you swallow all of your dependent services into a consistent API, no matter network distance or machine dependability. In Python it feels like my main thread, DB, job queue, and OS are all speaking different languages. With Elixir I don't spend much time at all getting different services to work together, at least an order of magnitude less.
Elixir is not perfect, but for me working alone dependency hell was the bottleneck with Python. Now the bottleneck is adding features, which is right where it should be.
I think in many cases the ecosystem issues are overblown. For the common 90% of use cases there are battle tested libraries out there.
For the less common ones, we tend to just roll our own which in most cases isn't that bad if you have reference implementations.
I think the most under-appreciated aspect of Elixir is how it helps reduce complexity. And there isn't a silver bullet here, but the tooling, immutability, pattern matching, process-based concurrency model, etc are all design decisions that, IMHO lead to simpler, more robust code.
(Caveat: of course, like any language, you can make a mess of things.)
I'm curious what libraries they wish existed.
I think that's a good point. Our largest pain point with Elixir is definitely the size of the community and the associated dearth of niche libraries. The technology behind it, though, is solid enough that once those libraries exist, things really take off. My team wrote several open source medical libraries for Elixir and we've seen it really expand into the healthcare market.
I'd like to have a look at those, have a github link?