Remember, Java and the JVM essentially have this today: front end frameworks, back end frameworks, data pipelines, big data processing, entire databases, etc.
In your opinion, what will make the Elixir flavor of this situation different?
In terms of what it's good at, we very successfully employed Erlang as the command and control language for some semi-embedded system medical devices. The runtime is predictable in terms of performance and memory, and fast enough for a lot of things. Where it wasn't, it's easy enough to talk to C. All the fault-tolerant bits are nice for a system like that where you want it to take note of a failure and restart the subsystem that failed. Lots of good logging, introspection and diagnostic tools exist.
AFAIK, any modernish language is good enough to get something up and running regardless of the task.
In the middle you will probably have a large number of problems that it's ok-ish at. But not really sure on what the distribution is here.
Can you give an examples? Respectfully, you were asked for tasks and instead gave a description of the category.
I can only think of real-time, or real performance limited software (example: rocket guidance software, aviation, etc). With these every modicum of performance per millisecond matters; but these constraints only apply in a few (relatively) small fields of software development.
Of course, maybe there's a generalized BEAM to C call library I'm not aware of? (I didn't think to search for one until now)
Also, honestly, it's a little easier to have a C daemon than an erlang daemon. Just call daemon() before the service loop vs setting up an app file. Of course, you have to build hotload yourself from dlopen and friends, and you lose out on a lot of features.
I'm looking for the equivalent of Perl's h2xs, or something like that. (which incidentally, maybe I should be writing these things in perl ;)
Elixir releases are built in and easy to use. You don't have to write an app file directly for instance.
I usually use ports for C interface (rather than NIFs). I have a little boilerplate C and Elixir that I recycle to do the ground work and then it's just your specific implementation detail.
In practice I haven't found the immutability of Elixir that useful for concurrency because data is deep copied when it goes across processes anyways. This is in comparison to Clojure where you can safely and perfomantly share immutable data across multiple threads.
To be clear, for NPCs it worked fine. But players are hoarders and in an RPG that can result in a ridiculous amount of data being attached to them.
A lot of languages that have more limited existing use have more gaps in their ecosystems. That means that to get something going quickly, you run into cases where you spend a lot more time building (or validating and tweaking existing but relatively rough) support infrastructure that you would just grab a well-tested, established library for in a language with a richer community and ecosystem. This is an area where the top tier ecosystems (Python, .NET, JVM) really shine over even second-tier popular ones like Ruby, and where both of those tower over things like BEAM, which has the additional problem that it has a fairly high impedance for incorporating C libraries, where many other platforms (some also with stronger ecosystems of their own) also more easily consume C libraries.
This extends both to broad application domains (e.g., scientific libraries) and to things like probability of having an idiomatic, language specific, well-supported client for a new service you want to tie in and incorporate.
If you're running a server—sure, BEAM me up.
Things I like using it for:
- long running services
- doing anything w/ concurrency
- setting up cron-like processes that run every so often
- actor model anything
- stateful services
- web development using Phoenix & Ecto
- parsing
- encoding/decoding
Things I don't like are primarily related to it being a small enough community. That means libraries for third party services aren't always the best, and using it in the enterprise means that the smaller talent pool is less attractive when the company's priority is to use proven/boring tech for which you can hire tons of developers. I also don't think Elixir has a clear value proposition when you're writing small, single purpose functions for a serverless architecture (even though I really like writing it), or when you're company decides to go all in on Kafka for communication between micro services.
Just my two cents.
The single unix process that BEAM uses is more conducive to some kinds of systems than some of the hackier-feeling solutions for the Rails ecosystem to tie different pieces together.
What's the issue with Kafka and Elixir?
Being able to utilize erlang libraries means there are a ton of heavily production tested libraries you can easily drop into an elixir project.
I also encountered some pain with the AWS client for Elixir when our company implemented SSO. There was a lack of support for a certain flavor of environment variable if I recall correctly. It's not horrible, just a pain.
hard disagree on all but c++, .net and maybe python
I think people forget erlang has been around a long long time and I've written ruby for years and can speak with great confidence that the equivalent ruby libraries in elixir are typically much higher quality
I've written Rails professionally for almost 10 years and have been following / playing with Elixir since 2016. While Ruby / Rails are amazing and the ecosystem is well suited getting a project off the ground extremely quickly, I'm just a big Elixir fan and hope to work with it professionally one day. I'll parrot reasoning from some of the sister comments.
"having an entire environment of consistent actors, fault tolerance, hot reloading, etc is a tempting proposition." - Very tempting indeed!
"Code elegance and development joy, maybe?" - Coming from Ruby / Rails, I agree 100%
"Not being statically typed" - Again, I've worked mainly in dynamically typed languages. I've experienced typing in Javascript and wasn't the biggest fan. But don't get me wrong, Rails can be awful when trying to dig multiple objects deep to understand what the data structure of the return value is so its not completely off the hook.
I think Elixir's big selling point is getting the BEAM runtime wrapped in a more modern language with more modern tooling. Lots of the positives people list about Elixir are due to BEAM, which you can also get in Erlang.
I was in love with Ruby and hated Java around 2009, but the latter has gotten so much better with IntelliJ IDEA, to the point where I have to admit that working with JavaFX from IntelliJ was likely my most serene programming job ever. To me, the whole ecosystem is only worthwhile because of JetBrains.
Robust IDE support for Elixir is probably a must-have requirement for many nowadays. I am really tempted by the design of Elixir and find Java/Go/C++ aesthetically repulsive, but I'll happily forget about that if I can keep my refactoring muscle memory.
It was very interesting experience being a long-time Pythonista having to be like "Isn't this awesome language with a Ruby-like syntax great???" and being told nah, let's just use async python by people who had spent years writing Ruby code.
This also helps with recruiting, as the tools work similarly. I didn't spend a lot of time in Rails, and decided not to go that way again, but I did appreciate that I got to recycle some of that new thinking when I started writing Node.
Phoenix also seems to be designed to recruit Rails developers. You could do worse than porting missing tools and crates from Ruby, and as far as I'm aware nobody has nominated themselves as the TJ of Elixir.
More importantly, the functional style used with Elixir will likely mean shallow usage patterns that are more composable than the deep layers upon layers of 'architecture' that plagues long lived class-based OO designs.