Matz is a great guy and epic language designer; and ruby is, for the most part (80% I'd say) a very well-designed language too. However had, ruby has a problem (or, several smaller ones, but also one big one: WHERE ARE THE NEW RUBY USERS! This is the big one, the other problems somewhat tie into this, but in part are also partially unrelated, e. g. python being successful means the share will be smaller for ruby, and JavaScript became so important because the browser is so dominating).
TIOBE is for the most part crap, but the tendency is also not completely fabricated. Ruby is at rank #25 with 0.67% right. Again, those numbers aren't that relevant, and they fluctuate WAY too much in suspicious ways - TIOBE has many issues, but ruby was doing better in the past there, so something changed. So, not only needs to be an unbiased analysis, but much more importantly so a contingency plan. I feel that in many ways ruby is also way too japanese centric. This is fine for a language that is only used in Japan, but a language should have no real country-focus per se, it should be usable everywhere without constraint. With a contingency plan I mean specific things to do. You can not solve this with single steps - that approach does not work. We saw this with the quest to make ruby faster. Ok, ruby is faster now, that's great, but then why aren't there more users? If ruby being much faster was the number #1 goal, why aren't older users returning for the most part? Why are new users hardly picking up ruby?
I don't want to make this sound too pessimistic per se, mind you. But ruby is now where perl was about 10 or perhaps even 15 years ago. Perl had the problem of perl5 versus perl6, but also python as stronger competitor. Perl5 failed to go against python. Ironically enough perl5 is more active than perl6 - that was also poor planning the perl folks did. (Version changes can be hugely problematic, Guido does not want python4 largely because python2 to python3 transition was problematic.)
Ruby really needs a plan with several items that work. Even more so as matz will sooner than later go into post-design stage (like Guido did with regard to Python though Guido is still somewhat involved with python, just not necessarily as sole decision maker now).
It's self-fulfilling and nothing to do with the language. Companies want to reduce the number of technologies in their stacks, and Ruby always loses out to Python and Node in part because it's viewed as harder to hire for Ruby skills. So there's less demand, and that leads to fewer people learning it or getting exposed to it on the job.
You also get things thrown at Ruby like how monkey-patching makes it hard to develop at scale which I find unreasonable but is nevertheless part of the conversation.
None of this is really within the gift of Ruby itself to solve. It needs another project like Rails which is so good within its niche that it can't be ignored. Rails itself is tarnished.
As a long time Ruby dev it's really hard to separate from Rails...and there has been both drama (which is ok to an extent, you want passionate people to care about things), but it's unfortunately led to some severe stagnation on the part of the Rails ecosystem versus rivals.
At a time where other frameworks (thinking mostly of Next+Vercel and Laravel here) are merging their frameworks with hosting, deployment, services and ops the Rails ecosystem has gone the other way and tried to bring back "you can host it yourself on a VPS!".
While there are merits to both approaches, the market really seems to have spoken and it prefers the integrated approach.
My memory of Next (and somewhat Laravel, although I'm definitely stale in php) is not so much that they got traction because of the hosting/deployment.
They were decent free frameworks that started getting popular, and the hosting/deployment tooling came later as a way for the companies to make money.
I don't see Rails skipping the tooling there as a bad thing, although I also don't see adding that tooling as a bad thing either.
---
That said - I really don't like modern Rails all that much. And I think that does directly play into the issue, because I think you're entirely right that Ruby and Rails are tightly coupled in a bad way for Ruby.
Basically - Modern Rails reminds me of legacy ASP tooling from the microsoft world... It does it all, magically (wizard me up a new controller, magic man!), and god fucking help you if it breaks. It's not that it's impossible to untangle, but good luck hunting down your exact spot where the magic broke and then finding decent documentation for your specific version of Rails, buried under all the blog-trash weight of the old versions.
Combined with relatively poor documentation (seriously, why is this so bad?), and it's not a fun framework to use as a newcomer.
The cherry on top is that lots of companies that are Rails shops are now fairly mature, and have relatively large codebases and teams, and Ruby is genuinely bad for large teams.
My first run in with Ruby was for CLI tooling way back around it's initial 1.0 release, and I like Ruby quite a bit in that space, but I won't install it just for that. Too much momentum for Node/Python which are almost always there in some form or another by default.
Rails needs a "Dotnet Core" variant with less magic, less stuff in general, and solid conceptual documentation as a breathe of fresh air. Because I'd actually pick Dotnet Core over Rails right now (or ideally, neither).
Ruby is an insular language by design. It's intended to be easy to use and "make programmers happy". Whereas popular languages are usually adopted for falsifiable reasons such as performance, type safety, memory safety, etc.
When it comes to languages that don't take themselves that seriously, the tragedy of Ruby is that Python is easier to get into with its much bigger community and ecosystem. Python is more likely to make the average programmer happy.
>>Python is more likely to make the average programmer happy.
Its a weird place to be. I was making ChatGPT write lots of Python code to do some analysis on the Stock market, and it was crazy how much code I was able to write in a day. I'm talking like a million+ lines of code. In a day.
To that end, it also means the cost of Python code today is $0 given how much can be generated so quickly.
Its a useful language, but pretty much anything you do with it today doesn't have as much value.
If there was a plan to be had here, it would be to merge with Crystal and focus on building native apps for phones. Nobody is really happy with any of the options there - Dart/Flutter were close, but fail on the server side. Kotlin Multiplatform is making a serious go at it but it's still too complicated. Bringing the ease of Rails development to native mobile app development would be huge.
I know it’s not exactly what you’re looking for, but many years ago I tinkered with RubyMotion, and in recent years I have successfully launched in the app stores with the mobile versions of Jumpstart Pro using way less effort than a Swift or Kotlin developer would due to the way Jumpstart Rails integrates nicely with their iOS and Android templates.
As a long time Dart/Flutter developer, I think Dart is slowly making its way to the server too. It’s more performant than Python (and I assume Ruby too), and nicer to work with than other statically typed languages (which I guess are mostly JVM or CLR based).
The third party package ecosystem is smaller but I think this will become less and less relevant as coding agents get better.
As Please Stop Citing TIOBE (https://nindalf.com/posts/stop-citing-tiobe/) points out, languages do have random fluctuations. It’s garbage data, so this is unsurprising. Between 2016-17 Java dropped 42% and C dropped 62%. That indicated nothing then, because they both promptly recovered. It was just noise.
Don’t take TIOBE seriously. You’ll feel better.
Look at the other suggested metrics - Google trends, GitHub repos, Developer surveys etc. None of these are perfect, but they’re more meaningful than TIOBE.
>I feel that in many ways ruby is also way too japanese centric. This is fine for a language that is only used in Japan, but a language should have no real country-focus per se, it should be usable everywhere without constraint.
I've never heard this argument before. How exactly is it Japanese centric?
I don’t think the language itself is Japanese centric. In the past the discussions among the language development often happened in Japanese, but I don’t think it’s the case anymore (though I don’t follow it closely) since there are a lot of international core language contributors now
I’m a new Ruby user. Been a dev for more than a decade and I picked it up for various things over the last year or two. These were not legacy projects, this was purely my curiosity to explore new tools. Have really enjoyed it!
Ruby adoption has been low to non existent for as long as I remember. Lets say, 15+ years now. Python kind of took over scripting space. That also means Perl ceded its space to Python as well. But man Perl does one thing really well, and that is acting as a glue language for anything Unix. So it will always have one good use and it does that really well.
Ruby revival was a thing during the time of Rails, but that went away with React + Node taking over the frontend world almost entirely.
>>TIOBE has many issues, but ruby was doing better in the past there, so something changed.
Tiobe indeed has its issues. But their results do not surprise me. Perl is in the top 10. Python is no. 1. Out side of these things you are going to write SQL for database. And mostly Java for apps, and C for embedded systems. C++ for performant applications. And JS for anything on browser.
Ruby just doesn't have a space and a sufficient following in that space.
There is also that problem of not having a Killer app.
A lot of bootcamps taught Ruby and Rails in the mid-2010s, so it hasn’t been stagnant for 15 years, maybe since 2017-2018. Then Python (with DS and ML domains exploding) and JS/TS (with Node and React) left Ruby far behind.
One disgust-moment I had was when AI narrated nature documentary on BBC or BBC-like channel and faked as David Attenborough. Now people may say "he got a great voice, even after he is gone we should have his voice" (he is old but not dead right now, thankfully - protect David at all costs), but I kind of changed my mind. I think AI should not fake stuff to us. So no fake-narrations either - what you see is what you get, at all times. On youtube this is now rampant; I need a minus AI version for youtube since AI just wastes my time.
Funnily enough the BBC have something of a standard when it comes to presenting foreign-language speakers through an interpreter that would have worked well here, AI or not, and that's to play the original speaker slightly before but quieter than the translation. You can hear their true voice and their intonation, but you still get the translation.
Agree with you on voices. I love Attenborough but I would strongly prefer that when he stops working or passes on we not recreate his voice or likeness with AI. It’d ruin his legacy because it’ll leave me with that feeling of disgust when I hear his voice, the exact opposite of what he’d want.
Off topic, but do you comment on reddit under the same handle?
> Matz: But as a programmer, the language I want to use might more often be C. I'm a C programmer, have been for many years. A C programmer for decades.
Matz is a great guy and epic language designer; and ruby is, for the most part (80% I'd say) a very well-designed language too. However had, ruby has a problem (or, several smaller ones, but also one big one: WHERE ARE THE NEW RUBY USERS! This is the big one, the other problems somewhat tie into this, but in part are also partially unrelated, e. g. python being successful means the share will be smaller for ruby, and JavaScript became so important because the browser is so dominating).
TIOBE is for the most part crap, but the tendency is also not completely fabricated. Ruby is at rank #25 with 0.67% right. Again, those numbers aren't that relevant, and they fluctuate WAY too much in suspicious ways - TIOBE has many issues, but ruby was doing better in the past there, so something changed. So, not only needs to be an unbiased analysis, but much more importantly so a contingency plan. I feel that in many ways ruby is also way too japanese centric. This is fine for a language that is only used in Japan, but a language should have no real country-focus per se, it should be usable everywhere without constraint. With a contingency plan I mean specific things to do. You can not solve this with single steps - that approach does not work. We saw this with the quest to make ruby faster. Ok, ruby is faster now, that's great, but then why aren't there more users? If ruby being much faster was the number #1 goal, why aren't older users returning for the most part? Why are new users hardly picking up ruby?
I don't want to make this sound too pessimistic per se, mind you. But ruby is now where perl was about 10 or perhaps even 15 years ago. Perl had the problem of perl5 versus perl6, but also python as stronger competitor. Perl5 failed to go against python. Ironically enough perl5 is more active than perl6 - that was also poor planning the perl folks did. (Version changes can be hugely problematic, Guido does not want python4 largely because python2 to python3 transition was problematic.)
Ruby really needs a plan with several items that work. Even more so as matz will sooner than later go into post-design stage (like Guido did with regard to Python though Guido is still somewhat involved with python, just not necessarily as sole decision maker now).
It's self-fulfilling and nothing to do with the language. Companies want to reduce the number of technologies in their stacks, and Ruby always loses out to Python and Node in part because it's viewed as harder to hire for Ruby skills. So there's less demand, and that leads to fewer people learning it or getting exposed to it on the job.
You also get things thrown at Ruby like how monkey-patching makes it hard to develop at scale which I find unreasonable but is nevertheless part of the conversation.
None of this is really within the gift of Ruby itself to solve. It needs another project like Rails which is so good within its niche that it can't be ignored. Rails itself is tarnished.
As a long time Ruby dev it's really hard to separate from Rails...and there has been both drama (which is ok to an extent, you want passionate people to care about things), but it's unfortunately led to some severe stagnation on the part of the Rails ecosystem versus rivals.
At a time where other frameworks (thinking mostly of Next+Vercel and Laravel here) are merging their frameworks with hosting, deployment, services and ops the Rails ecosystem has gone the other way and tried to bring back "you can host it yourself on a VPS!".
While there are merits to both approaches, the market really seems to have spoken and it prefers the integrated approach.
My memory of Next (and somewhat Laravel, although I'm definitely stale in php) is not so much that they got traction because of the hosting/deployment.
They were decent free frameworks that started getting popular, and the hosting/deployment tooling came later as a way for the companies to make money.
I don't see Rails skipping the tooling there as a bad thing, although I also don't see adding that tooling as a bad thing either.
---
That said - I really don't like modern Rails all that much. And I think that does directly play into the issue, because I think you're entirely right that Ruby and Rails are tightly coupled in a bad way for Ruby.
Basically - Modern Rails reminds me of legacy ASP tooling from the microsoft world... It does it all, magically (wizard me up a new controller, magic man!), and god fucking help you if it breaks. It's not that it's impossible to untangle, but good luck hunting down your exact spot where the magic broke and then finding decent documentation for your specific version of Rails, buried under all the blog-trash weight of the old versions.
Combined with relatively poor documentation (seriously, why is this so bad?), and it's not a fun framework to use as a newcomer.
The cherry on top is that lots of companies that are Rails shops are now fairly mature, and have relatively large codebases and teams, and Ruby is genuinely bad for large teams.
My first run in with Ruby was for CLI tooling way back around it's initial 1.0 release, and I like Ruby quite a bit in that space, but I won't install it just for that. Too much momentum for Node/Python which are almost always there in some form or another by default.
Rails needs a "Dotnet Core" variant with less magic, less stuff in general, and solid conceptual documentation as a breathe of fresh air. Because I'd actually pick Dotnet Core over Rails right now (or ideally, neither).
Ruby is an insular language by design. It's intended to be easy to use and "make programmers happy". Whereas popular languages are usually adopted for falsifiable reasons such as performance, type safety, memory safety, etc.
When it comes to languages that don't take themselves that seriously, the tragedy of Ruby is that Python is easier to get into with its much bigger community and ecosystem. Python is more likely to make the average programmer happy.
>>Python is more likely to make the average programmer happy.
Its a weird place to be. I was making ChatGPT write lots of Python code to do some analysis on the Stock market, and it was crazy how much code I was able to write in a day. I'm talking like a million+ lines of code. In a day.
To that end, it also means the cost of Python code today is $0 given how much can be generated so quickly.
Its a useful language, but pretty much anything you do with it today doesn't have as much value.
> Ruby really needs a plan
If there was a plan to be had here, it would be to merge with Crystal and focus on building native apps for phones. Nobody is really happy with any of the options there - Dart/Flutter were close, but fail on the server side. Kotlin Multiplatform is making a serious go at it but it's still too complicated. Bringing the ease of Rails development to native mobile app development would be huge.
I know it’s not exactly what you’re looking for, but many years ago I tinkered with RubyMotion, and in recent years I have successfully launched in the app stores with the mobile versions of Jumpstart Pro using way less effort than a Swift or Kotlin developer would due to the way Jumpstart Rails integrates nicely with their iOS and Android templates.
https://jumpstartrails.com/
As a long time Dart/Flutter developer, I think Dart is slowly making its way to the server too. It’s more performant than Python (and I assume Ruby too), and nicer to work with than other statically typed languages (which I guess are mostly JVM or CLR based).
The third party package ecosystem is smaller but I think this will become less and less relevant as coding agents get better.
4 replies →
[dead]
Started using Ruby 18 months ago. It's a joy to use. The main problem I encountered switching to it is that the ecosystem is in a very poor state.
Can you elaborate what exactly you mean by that and what you encountered?
Having dropped out of the Ruby space for Python and then Erlang, all I can say is that rails was the reason I left.
It seemed that the only thing anyone used ruby for, was for web with rails. Any solution that didn’t involve rails (e.g. sinatra) wasn’t further it.
As Please Stop Citing TIOBE (https://nindalf.com/posts/stop-citing-tiobe/) points out, languages do have random fluctuations. It’s garbage data, so this is unsurprising. Between 2016-17 Java dropped 42% and C dropped 62%. That indicated nothing then, because they both promptly recovered. It was just noise.
Don’t take TIOBE seriously. You’ll feel better.
Look at the other suggested metrics - Google trends, GitHub repos, Developer surveys etc. None of these are perfect, but they’re more meaningful than TIOBE.
Well ruby has been in decline for the past 10 years... https://trends.google.com/trends/explore?date=2016-12-02%202...
and it's not even worthy of being compared to python, the line is so insignificant that it looks flat https://trends.google.com/trends/explore?date=2016-12-02%202...
>I feel that in many ways ruby is also way too japanese centric. This is fine for a language that is only used in Japan, but a language should have no real country-focus per se, it should be usable everywhere without constraint.
I've never heard this argument before. How exactly is it Japanese centric?
I don’t think the language itself is Japanese centric. In the past the discussions among the language development often happened in Japanese, but I don’t think it’s the case anymore (though I don’t follow it closely) since there are a lot of international core language contributors now
1 reply →
I’m a new Ruby user. Been a dev for more than a decade and I picked it up for various things over the last year or two. These were not legacy projects, this was purely my curiosity to explore new tools. Have really enjoyed it!
>>WHERE ARE THE NEW RUBY USERS!
Ruby adoption has been low to non existent for as long as I remember. Lets say, 15+ years now. Python kind of took over scripting space. That also means Perl ceded its space to Python as well. But man Perl does one thing really well, and that is acting as a glue language for anything Unix. So it will always have one good use and it does that really well.
Ruby revival was a thing during the time of Rails, but that went away with React + Node taking over the frontend world almost entirely.
>>TIOBE has many issues, but ruby was doing better in the past there, so something changed.
Tiobe indeed has its issues. But their results do not surprise me. Perl is in the top 10. Python is no. 1. Out side of these things you are going to write SQL for database. And mostly Java for apps, and C for embedded systems. C++ for performant applications. And JS for anything on browser.
Ruby just doesn't have a space and a sufficient following in that space.
There is also that problem of not having a Killer app.
A lot of bootcamps taught Ruby and Rails in the mid-2010s, so it hasn’t been stagnant for 15 years, maybe since 2017-2018. Then Python (with DS and ML domains exploding) and JS/TS (with Node and React) left Ruby far behind.
1 reply →
This is an English translation of the original Japanese interview: https://kaigaiiju.ch/episodes/matz2
I mention this because I was put off by Matz's voice in the English audio, it's not his voice!
We are doomed in the AI age. :(
One disgust-moment I had was when AI narrated nature documentary on BBC or BBC-like channel and faked as David Attenborough. Now people may say "he got a great voice, even after he is gone we should have his voice" (he is old but not dead right now, thankfully - protect David at all costs), but I kind of changed my mind. I think AI should not fake stuff to us. So no fake-narrations either - what you see is what you get, at all times. On youtube this is now rampant; I need a minus AI version for youtube since AI just wastes my time.
Funnily enough the BBC have something of a standard when it comes to presenting foreign-language speakers through an interpreter that would have worked well here, AI or not, and that's to play the original speaker slightly before but quieter than the translation. You can hear their true voice and their intonation, but you still get the translation.
Agree with you on voices. I love Attenborough but I would strongly prefer that when he stops working or passes on we not recreate his voice or likeness with AI. It’d ruin his legacy because it’ll leave me with that feeling of disgust when I hear his voice, the exact opposite of what he’d want.
Off topic, but do you comment on reddit under the same handle?
> Matz: But as a programmer, the language I want to use might more often be C. I'm a C programmer, have been for many years. A C programmer for decades.
There's the lede. :)
It kind of makes sense. I feel that Ruby is a nicer syntax sugar over C at the end of the day.
[dead]