No framework that acts like Rails should be considered a stable stack.
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 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.
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.
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.