Also the ruby ecosystem is in decay. A lot of libraries are abandoned or on life-support - just do a random search on rubygems and check release dates.
Every language has this problem.
Even Elixir. The sole maintainer of the most popular AWS library isn't using AWS anymore so he stopped maintaining the package. He tried to give the project to another maintainer but after months of asking, no one wanted to take over the project.
There's also lots of Elixir libs where it looks like some package author was super gung-ho about making something and then the repo hasn't been touched in 4 years.
I see the same thing in Python too but one big difference is, with Python (and Ruby and Go and PHP) you often have officially supported libraries for things like AWS, Stripe and other important / popular services. With Elixir, you'll be on the hook for writing your own clients for most services.
I've asked Stripe a few times if they will add an Elixir client officially but they always give the same response of it's not worth it because there's not enough demand.
I want Elixir to get more popular but it's a very sketchy world outside of a few Elixir packages that are either developed / maintained by the core team, or have a huge following because it's solving a problem that pretty much everyone has. Basically you need to be prepared to develop libraries and a lot of glue code yourself to get started before solving your "real" business logic.
But the reality is, that all the interesting and cool stuff is happening somewhere else now. Ruby is still a great language, but the active community outside rails is shrinking and the creativity isnt there anymore. People prefer to explore novel ideas in different languages now - rust, go, elixir etc, even if they do ruby for a living.
And rails is showing its age too. Every rails project i encountered was a petrified spagetti monolyth that had to be broken up and refactored into smaller pieces.
If the answer to the question of "will it be supported in 5 years" is no, it can never be considered a "stable stack".
If I do the same thing on RoR it will not, guaranteed.
I've lost count of the number of times I've gotten a new client and had them on a web framework that was EOL, on a version of the language that was EOL, and on an OS that was EOL (because they couldn't get the EOL language/framework running on a modern OS).
Anytime you use something like RoR you're automatically taking on a higher maintenance burden because you MUST upgrade or you'll find yourself in a spot where you're trying to decide if you want to rewrite or pull it up to the newest version.
No part of that description screams stability.
If you're using ASP.Net MVC then your app should also come across to .net core fairly painlessly.
The only real challenge is going from the old webforms with its page lifecycle to the asp.net core. But depending on how the application was originally implemented, that really should just be about the frontend, not the entire app. And of course EF core has changes you'll need to deal with as well if you're using it.
It's by no means seamless, but MS did the best they could to maintain compatibility between the two, and you only do it once.
It should also be noted that .net framework is almost 20 years old. Doing something like this once in a 15 year period is a far cry from Laravel's every 6 months or RoR's 2-3 year cadence. IOW, it's not optimal that the divide between framework and core exists, but it's a far better story than Laravel, RoR, et al.
> And who's to say .net core doesn't have any breaking changes in 5 years, are they guaranteeing not to do any breaking changes at all to the framework?
ASP.Net core is literally just a set of libraries. You'll be able to run those on the modern version of .net in 10 years from now. We know this because it's what they did with asp.net. An application built on asp.net 1.0 will work on 4.8.
While I understand your point, not on a modern OS you can't. You literally can't build the tools necessary to run it on a modern OS. I know because I've had to deal with this many many times. You literally are forced to run that stack on a version of ruby that's EOL and on an OS that's EOL.
I mean yes, you CAN do that, just like you can run Windows Server 2000, but it's really really not a good idea.
There's no plan to ever have a v2.0.
I think most elixir projects are on Phoenix, and while I can't speak too much about the speed of that project, the poster you're responding too has clearly stated they have an app that's 4 years old and running just fine so I have to believe it's not as much of an issue as you think.
There are some new choices for building releases that make it easier for people who prefer to use run time environment mentioned variables for configuration instead of compile time ones. Previous ways of building releases still work as before.
I make releases with Distillery just as I did back in 2016. The main change in my release workflow is that now I use Gitlab CI/CD, and that's unrelated to any Elixir or Phoenix changes.
I don't know what that means in this context. What I do know is that RoR versions go EOL roughly 2-3 years after they're released. That's not stable by any stretch of the imagination.