I am just curious, why would I use Rails over something like .Net in today's time? I am no apologist for .Net or anything, I am just genuinely curious.

It's an engineering decision with tradeoffs, like every engineering decision.

Actually the latter is a candidate to k8s because the team knows less and less of server management. I think they are going to replace complexity with complexity for something that fits well in a small VM. We will see.

About Elixir, I don't think it's an overkill. I find its pattern matching much better than anything similar in Python and Ruby. Running a background job without having to use Celery or Sidekiq is great. The deploy story is worse than Ruby's (IMHO) in part because it's compiled (I prefer to deploy with Capistrano than having to build and deploy.) Python's deploy story just doesn't exist. According to the project I'm using a self made Capistrano equivalent, git pull or sending git patches to the server.

Unless you have some specific requirements for you app like high concurrency or memory safety and so on, then you can pick whatever you (or your team) are most comfortable with: Django, Rails, Symphony, .. are all excellent.

It's more about solving business problems and building great systems than anything else. All tools have pros and cons of course, it's simply up to us to review the requirements and pick the right one for the job.

You are not wrong though, and it's quite annoying when hopping between multiple .Net versions. I feel like I have a bit of insight into what it would have been like to be developing in Python during the 2.x to 3.x schism years back.

Then, they come up with The New Thing every few years, which is not backwards compatible and only handles 20% of what the old thing did + a few new things, but they promise this is the future and will eventually have all the features. The Old Thing is always there if you want it, so there's no reason to revolt when this happens.

The New Thing will eventually be replaced by a Newer Thing, get frozen in its current status, and the Newer Thing will be promised to be the future.

A nice example is Windows GUI. The Old Thing is GDI. Then they invented WinForms in .NET, then WinForms was abandonned in favor of WPF, then WPF was abandonned in favor of Metro/Modern/Universal apps, and last I checked they had some new HTML+JS-based stack available. All of these frameworks still work - you can take an app built with any of them and run it on the latest Windows, and you can even build a new App based on any of them and still find resources for it etc. But none of the old ones are getting new features, and MS will steer you to one of the newer ones instead.

The same kind of thing happened with communication frameworks (COM, then WCF, then???), with ORMs (ADO.NET, LINQ to SQL, Entity Framework, Entity Framework Core) and I'm sure others.

I detect a similar strategy with Apple and the app store: make it so that the long tail of small developers can't invest in more than one platform by moving goalposts so frequently you spend any spare cycles you have trying to keep up.

But all t he other stuff common to popular libraries still applies, tons of community support, huge extensibility, large population of devs that have experience building large apps.

That means it's not likely to make huge breaking changes without lots of notice. Its development team isn't going to find something more interesting to do tomorrow. Lots of people know it. There are lots of libraries and tools that work with it. Its capabilities and limitations are well understood and predictable. Its future isn't tied to a single vendor. Lots of people know it.

I mean, I solve most of my problems with the hammers I have at hand. But I try not to fall exclusively in this trap of “I will use tech X because that’s what I know.”

But I see a majority of my programming peers who will avoid moving “forward” because it’s easier to “stay behind.” At first, this works, because the difference between what’s new and evolving versus what’s established and a “core competency” is trivial and easy to marginalize. As it persists over time though, the investment can become a real millstone.

I am pretty comfortable with Python. We use it some pretty key areas in our product. It’s an established technology and competency for us. Last year, I needed to construct a service that was going to involve spinning up LOTS of little long lived threads. I was concerned about doing this in Python. Doing so would be easy and straightforward. “Because I know it” would definitely have said “do this in Python right now, deal with scaling issues later.” Instead I looked around and deemed this a good reason to take Elixir for a spin. I’m glad I did. It turned out to be a good fit for this problem. “Because I don’t know it” caused others around me to raise their eyebrows and question my approach initially. Was it the 100% best choice? Who knows for sure. But it’s worked out well. Ironically, just the other day, a data serialization library I have in both systems, the Python one needed to run faster (new use case for it suddenly needed speed that we didn’t hitherto care about). After some profiling, I rearchitected the python algorithm to be more similar to the Elixir one and gained about 50% speed up.

That would be a VERY interesting case study. Any chance you could write it up as a blog post or similar?

You could just fade out rails as you could with any other monolith, but many companies aren't doing it because it offers legitimate advantages.