is ruby dead?
That seems to track with this if a Rails application is actually more likely to become "legacy" but it could also be the same for Python/Django. I just remember the Ruby/Rails point in particular because that's primarily what I work on.
It's unfortunate for my company, because it would have been better if this functionality had been incorporated in our Scala services codebase, but it gives me the perspective of having used Ruby and Scala in the same system, on the same problems. My personal opinion, predating this experience but strengthened by it, is that dynamically typed languages have lost most if not all of their appeal in the face of improvements to statically typed languages.
In the 2000s, I often used the escape hatch of Boost Python and Jython to make myself more productive when working with C++ and Java codebases. I could get things done so much faster in Python that it was worth the awkwardness of dealing with language interop. These days, I don't bother. I can write quick, small, readable scripts in the same statically typed language that I use for large-scale programming.
Django guy here so unaware, what makes it so great?
I have been doing Rails for the last 8 years but it's really showing it's age. Constant issues in our app that TypeScript would have caught, along with pretty dismal support for advanced editor features you see with typed languages.
Having to write a billion unit tests to replace the type checker is just abysmal.
Yeah no thanks, I don't want to deal with the npm madness. Not to mention that there's nothing in the JavaScript world that is as good as Activerecord yet.
I also don't think this argument makes sense, you don't like changes that are breaking stuff and recommend the JS ecosystem, probably the most churn-heavy ecosystem that exist?
At my work we have a roughly half Rails / half React app, despite that, at least 80% of the updates are on the JS side and unlike Rails, those packages are usually poorly tested and often break functionality. Maintenance is much harder on the JS side.
I recently had an issue where updating ruby caused kernel#open to change its parameter list, but all of our tests has this call mocked out since it makes a web request. Then it blows up in production. Despite all my efforts I couldn’t even find the changelog or PR that caused this breakage.
I also have the same story on the JS side, we upgraded the package to open notifications, they broke the API and kept the types the same. Now we added a test that notifications are working (we're basically doing the package maintainer's job).
Ruby's update story isn't prefect, far from it but I'll take it any day against npm. I worry at every package upgrade on the JS side.
What's making it even worse is that the stdlib is very limited on the JS side, so this effect is compounded by the number of packages needed to fill the gap.