Half of the Ruby that I write is not web applications - it's scripts that configure servers, import and export data, optimise a manual process, etc. Ruby is perfectly performant in those scenarios.
It's become a horrible meme I can run a script that reformats a 30 line CSV file the way I want it in 0.05s and someone will almost certainly lean over and say "Ruby is too slow, you really need to upgrade to <x>". Or the intranet application I wrote in Sinatra last year for a total of four users, where all I got questions about how it could be usable without "asynchronous".
That said, I don't understand Ruby's performance position. IBM released a preview of their JIT implementation over a year ago, with much fanfare. By many accounts, it held major practical improvements. Since then, I haven't heard a thing about it, and the Ruby team seem to be spending years talking about implementing the same thing.
ruby is really good for solving small problems quickly. Don't get me wrong, proficiency in your shell will go a long way. But when something starts to get complicated I can bang it out in ruby and it's just done.
Web apps do drive ruby's adoption, though. Now that I know ruby I use it for many things, but I learned it initially for rails. Many other languages (like python) can fulfill ruby's scripting usages (I would argue javascript can't - despite its many strengths it's just a little too awkward)
Matches my use case completely. I haven't built a rails app but learned ruby with a view of doing that but never did (I believe it's important to know the language before the framework - in hindsight, a good decision with Rails specifically).
I like the standard library and I love the gems that fill the gaps the stdlib shouldn't really fill.
Many devs I know reach for the language they use day to day and their scripts and productivity suffer. Ruby is almost like an openly secret weapon in that sense.
I wish Ruby wasn't run by Matz and his team. The number of improvements they can offer is just too little. And they don't do well to get and include feedback from others. It's true that they've been working on Ruby for a long time, and they deserve credit. But it's time for Ruby to grow past Matz and his team.
If Ruby can offer:
- real threads
- great performance
Then the conversation about Ruby would be about the right things - do you like the syntax, the feel, would it work for your team, etc. We wouldn't be bickering about "performance" all the time.
It's become a horrible meme I can run a script that reformats a 30 line CSV file the way I want it in 0.05s and someone will almost certainly lean over and say "Ruby is too slow, you really need to upgrade to <x>". Or the intranet application I wrote in Sinatra last year for a total of four users, where all I got questions about how it could be usable without "asynchronous".
That said, I don't understand Ruby's performance position. IBM released a preview of their JIT implementation over a year ago, with much fanfare. By many accounts, it held major practical improvements. Since then, I haven't heard a thing about it, and the Ruby team seem to be spending years talking about implementing the same thing.