No, it’s got an active community and fresh developments, so it’s definitely not dead. The concurrency story is/was poor, so some people left Ruby but many remain and many still join.
The answer to your question is "no," because there are a significant number of people who feel that they are more productive in Ruby than in any other language. My organization has a large repository of Ruby scripts for doing manual tasks, created by somebody who felt exactly that way.
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.
ActiveRecord is Ruby's nigh unassailable superpower for webdev. A few jobs back my last act in that role was moving all DB access from a separate Scala microservice into a Rails minilith, saving many, many lines of code and network round trips.
Ditto... I really enjoy Django's ORM (makes the trivial tasks dead-easy and steps out of the way when needed) and would like to know if it can be even better by borrowing ideas from ActiveRecord.
As someone with a lot of experience in other languages who joined a ruby shop, imho its best use is for teams that already know and like it. Its at a few thriving companies so it wont die anytime soon, but i dont personally think its a good choice otherwise. Mostly because i think types, more robust error handling, or the wider ecosystem (ex python, js) that other languages provide offer more avenues for professional development and ways to reuse / extend language expertise.
Nah. It's not as "cool" as it used to be, but IMO Rails is still the best around at banging out a decent web app with a moderate amount of functionality and traffic. It still has better integration with front-end side than any other backend framework out there, including the ones in the cool new languages.
Definitely not dead. But if were a new software engineer trying to work out what language I should pick up next Ruby would be pretty far down the list these days.
It's alive in the way PHP is alive. It has so much stuff built on it that it will be around for a long time. But I don't feel Ruby is a good choice for projects anymore. The failure of bringing types in to the language has really doomed it. Pretty much all cases you might consider using Ruby, TypeScript is a better choice.
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.
We have 20,000 rspec tests. They do a huge amount. But every few months, something slips through. Especially when the change relates to 3rd party gems.
Having to write a billion unit tests to replace the type checker is just abysmal.
If you're writing tests that test for that I think you've missed the point entirely of testing. I hope you don't think the typechecker works for logic?
Yea devs just don't understand that Ruby is strongly typed. In fact, it's the most strongly typed language out there besides Scala. It's just not statically typed.
That does nothing for the fact that gem authors regularly change things without warning and you can’t tell until the code is run. Something a type checker trivially solves for you.
> Pretty much all cases you might consider using Ruby, TypeScript is a better choice.
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.
Breaking changes are not an issue, it’s the fact you can’t spot them before deploying. TS would warn you when compiling, but Ruby gives you nothing until that specific code gets run.
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.
Sure but what's the point of types if none of the packages you use are using it or are even tested in the first place?
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.
We just looked at our options at work and landed back on Rails. The problem is the Javascript ecosystem is just bad for any project that needs to live for more than a year. The database libraries changes every 6 months, stuff is just constantly rewritten over and over. I agree that Typescript is nice but the eco system is awful. If you want a batteries included framework, that is used at scale, has a lot of history behind it, and doesn't churn every 6 months, there are only a few that you can use. Rails is one.
We looked in to it and it didn’t seem usable with Rails. DHH has also made comments on Twitter that he is strongly against adding type support to rails. I’m also yet to encounter a gem which has types. While basically every single npm package is TS now.
Strictly speaking this doesn't answer to the spirit of the question but... I'm currently making money by working at Rails and Django projects started by my customers years ago. Rails' ones are systematically in a better shape than Django ones. I'd say that either Rails or Ruby or both are structurally better than the Django / Python pair at delivering sound and maintainable projects.
I remember an argument made in the context of a Stackoverflow blog post (one of the "which programming language do people use/like the most/least") that Ruby/Rails was dropping off in popularity because it was becoming more common for a new developer to have to work on the "legacy" Rails application (and therefore dislike it because they have difficulty understanding it the same as any application one didn't design themselves).
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 dead for new development, and dying as a legacy language. Not many people are using Ruby for new development, they've all moved on to Node/React. And most people who have RoR apps are looking to rewrite them in Node/React.
39 comments
[ 2.3 ms ] story [ 71.0 ms ] threadIt'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.
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.