> Applications these days - well, a large number of them - need to be realtime
A large number of applications where and for what purpose? I think a large number of applications don't need to be realtime. The majority of applications exist that we never see, or frankly never know exist: SMBs that we've never heard of that are approaching (or have approached) the seven-figure revenue mark.
I do think, though, that a large number of developers have had their perception poisoned by this very crowd: that they need real-time, or a front-end framework, or plans for massive scale because they think they have to build the next Stripe or Twitter or FAANG-scale thing. Many of us, just like many applications, aren't going to scale like that, or hold those jobs.
The internet blossomed without real-time just fine. I think that it'd be just fine without it.
The funny thing is that I basically agree with you 100%. I constantly rail against, and mercilessly tease, companies building with microservices from day 1 or going with low-level high-performance languages like golang or rust before they even have a single customer "because FAANG does it". Monolith until you literally can't anymore. High level until you are forced to use something lower.
I did say that Rails is perfectly adequate for certain classes of applications. I guess the point I was trying to make, poorly as it turns out, is that for consumer applications at least, Rails is no longer the "sweet spot" and you hit up against its limitations earlier than ever and will, not might, will be forced to deploy ever more complex workarounds for basic functionality that you get out of the box in something like Phoenix. OK, forget websockets. How about scheduling a daily summary email? Daily reports? Anything other than a build-the-world, serve-request, tear-down-the-world HTTP query? Now you're running some separate thing and boom, there goes the simplicity.
I get you. I'm the "use boring tools" guy as well. But the tools have to be actually capable of doing the job, and the job has changed, well the kind of things I seem to be involved with have changed, and the Rails productivity "edge" lasts weeks at best.
And they're all inferior to what Elixir can do out of the box without ductaping on 3rd party tools. Running other services like Redis is not only not a breeze, it's an additional expenses and thing to monitor.
I assume most big Elixir apps use Redis or something similar anyway for its speed and reliability (it can periodcally persist for instance) instead of saving everything in memory. Redis is widely used with a huge community support and you usually don't want to lose all your background job info (you don't have to use an actual DB, but Redis seems like a good compromise for many companies). If you don't want Redis there are background job gems for Postgres/MySQL etc.
As for monitoring - in our current micro service world adding or removing Redis is peanuts. You have so much stuff to monitor you need strong monitoring, and usually a whole team dedicated to set it up. Doing that for Ruby or Elixir is negligble. I'd even say Ruby is more straightforward to monitor for devops people than Elixir (that's from stories I've read, not an expert on that).
There's plenty of real issues with Ruby (and with Elixir), but what you're arguing here is simply non issues imo.
Fair points regarding eventually using redis; it is common. But we haven't had to reach for it yet and handle some light caching and background jobs right in Elixir.
As for monitoring, it's better than it used to be - Elixir's Telemetry library is pretty awesome. There's even some UIs built for it:
Ah yeah, was generalising somewhat. You're right, it's perhaps a "mid" level language. Maybe even high level in areas it is intended for, such as channel tooling, etc. Regardless, it's much more verbose than true high-level languages such as Ruby and I would not consider it a good choice for a startup unless they were specifically writing actual infrastructure code.
Regardless - it's certainly implicated in the cargo cult of "dozens of golang microservices all talking to each other in a combinatory explosion of GRPC" antipattern i've seen startups succumb to before. One of them ran out of runway with less than 10 actual customers, after spending 18 months building an MVP that would "scale".
Maybe I can propose a new law: "If you have more microservices than you have customers, you are scaling prematurely".
> How about scheduling a daily summary email? Daily reports?
Forgive me if I'm wrong (I don't know Phoenix that well), but don't you need some external library like Exq do perform background jobs? How is Phoenix+Exq different from Rails+Sidekiq?
You don't need to run a jobs server, the language itself handles the processes. Most people use a library but the work still happens in the language runtime. And you can even build your own on top of supervisors, genserver, etc.
A large number of applications where and for what purpose? I think a large number of applications don't need to be realtime. The majority of applications exist that we never see, or frankly never know exist: SMBs that we've never heard of that are approaching (or have approached) the seven-figure revenue mark.
I do think, though, that a large number of developers have had their perception poisoned by this very crowd: that they need real-time, or a front-end framework, or plans for massive scale because they think they have to build the next Stripe or Twitter or FAANG-scale thing. Many of us, just like many applications, aren't going to scale like that, or hold those jobs.
The internet blossomed without real-time just fine. I think that it'd be just fine without it.