I write CRUD apps for a living , how is Elixir gonna make it easier for me? It can't and it won't. Not saying it's bad or anything, just has nothing for me personally.
1. Phoenix's channels make communication between a frontend and backend pretty effortless. Create a channel, publish a message, and anyone listening to the channel picks it up. Communicating updates from the server to the client is simple. Communicating between clients is equally simple.
2. Elixir has great support for spawning and managing background processes. My go-to is Rails, and if I want to manage background work I have to use something like Sidekiq and Redis. It works, but Elixir is much nicer. I've written systems that need to manage heavy amounts of background work and I dream of rewriting them in Elixir.
Just a few data points that might be helpful.
It's like, okay, so there's the functional programming, the similarities to Ruby, the BEAM VM, the concurrency.... but what does it do for me? They're not exactly selling points on their own because other languages can compete with those things.
As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
You make an app using Ruby on Rails, keep developing it, and it keeps growing. You monitor your traffic and it gets bigger, now you add more servers to handle the traffic (it costs you $20/server, now you need 4). A couple more developments, memory usage starts to grow also.. Now, you need to increase memory of your server.. but now you also need Websockets, so you add both and need to add more resources to handle the scale, and the cycle continues.
When you use Elixir/Erlang and it’s BEAM VM, it’s highly efficient and scalable out of the box, so you won’t need to do “much” of the above. A simplistic explanation but shows the point.
OK, so in real life maybe the costs can actually be an order of magnitude higher than this.
But for $60/$80 a month? Is like no money.
That is less than one hour of time for even a cheap developer including taxes and other overhead, or okay call it two hours a month of time if you want to be generous. So if Elixir instead of Rails (or, of course worse, _switching_ to Elixir from current Rails) takes more than, say, 24 hours of developer time in a year... you didn't save money.
You're getting down voted mostly because of your tone (IMO) but the appeal if Elixir is just a reality of experience.
When I found it, I was 15 years in my career and when I dove in, learned it and saw how it addressed so many short term and long term issues that appear in application development...the balance was the closest thing I'd seen to perfect.
But if I hadn't experienced the pain, I would never have appreciated it all the little details.
All I ever see is people exclaiming how awesome it is and then the responses turn out to be underwhelming for various reasons. Like hot reloading isn't that special or unique anymore.
But that's an interesting talk. I didn't have time to go through the whole thing but the core of it seems to be the pros of erlang like BEAM's high concurrency advantages and uniformity of tools running on top of otp.
It's an interesting argument.
https://blog.codeship.com/comparing-elixir-go/
Hot reloading is very unique though (but not necessary for most use cases). There's no other stack outside of the BEAM that has an equivalent. A lot of what is offered by the BEAM isn't even possible in other stacks because it requires a collective of language decisions working together.
Think how much the code would be simpler and easier to reason about without caching. Or reducing the numbers of servers you need from 150 to 2 and with better performance [1]
[1] https://www.techworld.com/apps-wearables/how-elixir-helped-b...
Sorry to be blunt but this is nonsense, languages and stacks are just tools.
When I was working on banking systems the idea of using dynamic typed language would have been insane. Now that I’m in a two man’s shop working on low traffic web app I’m happily using Rails for the CRUD work. And if tomorrow I were to work on a public high traffic real-time app like Discord I would do it in Elixir. There is no such thing as your stack.
Coming from a php / node.js background it seems very overwhelming
The default elixir-lang getting started is pretty good. https://elixir-lang.org/getting-started/introduction.html
Some people prefer this community one https://elixirschool.com/en/
You also don't have to worry about performance and concurrency. I would actually argue that you have to worry less about performance and concurrency because you can go further without having to resort to cache layers, tuning, etc.
But ultimately, I don't disagree with you. If you are building CRUD apps, then any technology is likely fine. Perhaps there is a chance Phoenix will start to take a bigger pie of the "CRUD apps space" with LiveView (https://github.com/phoenixframework/phoenix_live_view). If you could produce CRUD apps at the pace you do today, but making them interactive and realtime is orders of magnitude simpler, would that interest you?
Anyhow, your characterization there I don't think is quite right. For one Java does not typically use a background job set up, because it is a first-class multithreaded runtime so it seems more likely prepared to use a threadpool for some concurrent processing before it say tosses things out to a task queue. Similarly as most java web servers are on a thread pool model for concurrency as opposed to async IO, you'll also have true in request concurrency for things like making a few calls to the DB and then collecting them. This thread pool is not well abstracted typically, and the mutable object model leads you to writing classically tricky multithreaded code with data races and the like.
For something like node where you are not really likely to be using threads, you are pretty hard tied to async IO as your method of concurrency. So you have a really easy job if all you're doing is async calls to say a DB with no need for data processing. Here once you need real computation you will have essentially no option other than using a task queue.
Then when it comes to python you have essentially the worst of all worlds. it's not easy to do concurrent IO or computation without some form of background processing.
I believe that when it comes to the elixir runtime the idea is that they have removed async IO from the mix and instead put up a concurrency API that is as simple to manage as async IO in something like node. Under the covers is all delegating out simple blocking code to a thread/process pool, but the immutable data model and API makes it so that data is not shared across the pool, trying to keep the classic concurrent mistakes hard to make.
Nothing that can be done in elixir seem to be impossible or even astoundingly hard in some other technology, but the unified API for all forms of concurrency seem like a nice way to make it a runtime that can handle many different types of workloads in a simple and cohesive way. That simple way also seeming to not need you to bring in things like a redis task queue where you generally would need to use it or some other external solution.
Sure, you may want to move your Java/Erlang jobs to Redis/SQS/etc for different reasons, but it is not your starting point. And given you were explicitly talking about CRUD apps, being able to have everything you need with only your app + database, without a need for Redis, workers, or tasks queues, leads to operational simplicity.
Erlang/Elixir processes don't share memory (Actor model) like Java threads do, giving it a distinct advantage (see Akka for Actor model in Java).
But yeah, for heavy stuff even in Elixir, you might want to outsource that to a Job server (which there are many libraries in Elixir for this).
For instance you linked the spring application events integration with redis, while that is definitely an option it's not one you'd immediately reach for. Instead you'd more likely set up and use application events and/or domain events (if using spring data) handled locally with thread pool. The benefit here is that of course way less set up and complexity, but you can also handle these events sync or async.