5 ms·

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 day

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.

Gigachad 3y ago
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.
- dham 3y ago
  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.
- lcnPylGDnU4H9OF 3y ago
  Are you familiar with rbs (https://github.com/ruby/rbs https://github.com/ruby/rbs)? If so, what issues do you see with using that over TypeScript?
  - Gigachad 3y ago
    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.
- craigmcnamara 3y ago
  Sounds like you don’t write tests
  - Gigachad 3y ago
    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.
    - gregors 3y ago
      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?
      - vinceguidry 3y ago
        Seriously, just introduce type contracts or a full static type system. Ruby has both.
        dham 3y ago
        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.
        Gigachad 3y ago
        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.
        vinceguidry 3y ago
        Should be caught easily with regular unit/integration tests. And again, ruby has static type system, you just have to use it.
- realusername 3y ago
  > 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.
  - Gigachad 3y ago
    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.
    - realusername 3y ago
      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.

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.

Gigachad 3y ago

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.

dham 3y ago
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.
lcnPylGDnU4H9OF 3y ago
Are you familiar with rbs (https://github.com/ruby/rbs https://github.com/ruby/rbs)? If so, what issues do you see with using that over TypeScript?
- Gigachad 3y ago
  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.
craigmcnamara 3y ago
Sounds like you don’t write tests
- Gigachad 3y ago
  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.
  - gregors 3y ago
    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?
    - vinceguidry 3y ago
      Seriously, just introduce type contracts or a full static type system. Ruby has both.
      - dham 3y ago
        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.
        Gigachad 3y ago
        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.
        vinceguidry 3y ago
        Should be caught easily with regular unit/integration tests. And again, ruby has static type system, you just have to use it.
realusername 3y ago
> 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.
- Gigachad 3y ago
  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.
  - realusername 3y ago
    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.