[HN Gopher] Matz 2/2: The trajectory of Ruby's growth, Open-Sour...
___________________________________________________________________
Matz 2/2: The trajectory of Ruby's growth, Open-Source Software
today etc.
Author : kibitan
Score : 104 points
Date : 2025-12-26 17:07 UTC (7 days ago)
(HTM) web link (en.kaigaiiju.ch)
(TXT) w3m dump (en.kaigaiiju.ch)
| PaulRobinson wrote:
| > 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. :)
| shevy-java wrote:
| It kind of makes sense. I feel that Ruby is a nicer syntax
| sugar over C at the end of the day.
| block_dagger wrote:
| That is a surprising take. I wouldn't describe Ruby that way
| at all.
| dismalaf wrote:
| What? Ruby has very little in common with C, it's just
| implemented in C...
|
| Ruby is more like Smalltalk and Perl had a baby...
| pil0u wrote:
| 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!
| shevy-java wrote:
| 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.
| regularfry wrote:
| 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.
| testdelacc1 wrote:
| 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?
| shevy-java wrote:
| 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).
| regularfry wrote:
| 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.
| DonHopkins wrote:
| DHH should have just called it "Ruby on Abtransport" -- a
| more honest reflection of his brand of strongly opinionated
| right wing authoritarianism: rigid, centralized, intolerant
| of dissent, obsessed with keeping the trains running on time
| rather than questioning where they're going, all while
| pretending it's just good engineering.
| testdelacc1 wrote:
| 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.
| arccy wrote:
| 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.go
| ogle.com/trends/explore?date=2016-12-02%202...
| testdelacc1 wrote:
| Yeah that's brutal. Thanks for sharing.
| solatic wrote:
| > 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.
| nmfisher wrote:
| 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.
| autogn0me wrote:
| Agreed.
|
| I feel like dart is where Python was 20 years ago. It's
| exciting and its integration story is taking off.
| stephenhuey wrote:
| As a Ruby dev who has built a couple Flutter apps, I was
| surprised how pleasant Dart was compared to JavaScript
| and TypeScript, and I sincerely hope it largely replaces
| those on both client and server.
| dismalaf wrote:
| Unfortunately Google gave up on Dartium a long time
| ago...
| solatic wrote:
| > third party ecosystem is smaller... less and less
| relevant as coding agents get better
|
| I disagree. The problem isn't with getting an
| implementation for some favored sort algorithm, it's about
| integrating with external systems. That's a million times
| easier when you're not crafting the equivalent of an
| untyped curl call dealing with raw JSON bodies and can
| instead use official SDKs provided by the external system
| provider.
|
| Not even GCP offers a client SDK in Dart, let alone AWS or
| Azure. Sure, there's a Postgres package for Dart, but
| you're working with raw arrays on the result rows - no Dart
| support in sqlc. What about a payment provider like Stripe?
| Nope. Or an email provider like SendGrid? Also no.
|
| I mean... this is one of the reasons why Go is so popular.
| You're practically guaranteed to find an SDK for the
| service you need to connect to. And that's not because the
| Go team at Google had some special marketing magic that the
| Dart team at Google didn't have access to, that's just
| organic growth. Do you really think services are going to
| wake up across the industry and start offering Dart SDKs??
| nmfisher wrote:
| That was my point about coding agents - as long as
| there's a standard protocol (usually HTTP REST), Claude
| Opus could roll out a client library in almost the same
| amount of time it would take me to find the right name
| for the official pip package. Equally, they make it a lot
| easier for providers to roll out official SDKs. I did
| this recently for Tencent's Hunyuan API and I didn't even
| have to think about it. This type of API integration will
| be trivially solvable in the near future.
| solatic wrote:
| I see what you're saying, and I recognize that a coding
| agent will spit out something usable, but it still feels
| wrong. When a service provider puts out an SDK, _they_
| are responsible for it and are incentivized to update it
| when their API updates. If I ask an LLM to generate an
| SDK for me, then _I_ am responsible for the SDK code
| despite the fact that I am not responsible for the API
| itself. This is not good Conway 's Law alignment; it's
| the kind of thing you do when you have no other choice
| but to accept the debt that comes with it.
| stephenhuey wrote:
| 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/
| pxc wrote:
| What does "merge with Crystal" mean, when Ruby is a deeply
| dynamic language and Crystal is statically typed?
| Write/endorse a Ruby implementation in Crystal? Create
| frameworks for various kinds of applications that let you
| easily use Ruby for some components and Crystal for others?
| Other general work on interop?
| solatic wrote:
| Merge with Crystal meaning, recognize that both projects
| have more in common from a language and culture perspective
| than they are different, get the committers and steering
| folk to talk together, collaborate together, combine the
| work. Think for example how Python has a great C FFI, you
| have a highly dynamic Python layer that can sit on top of C
| code for optimized hotpath code. Now imagine you instead
| have a highly dynamic Ruby layer with great integration
| with a Crystal layer for optimized hotpath code, where
| because the Ruby and Crystal folks are working together,
| everything is a first class citizen, all the code is in the
| same language family, using the same build toolchain,
| packaging toolchain, etc. Write standard Crystal libraries
| for compiling to native mobile platforms and write Rails-
| style views in Ruby for mobile app views, for example.
| mkl95 wrote:
| 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.
| kamaal wrote:
| >>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.
| block_dagger wrote:
| ChatGPT was writing 11+ lines of usable Python every second
| for 24 hours? I highly doubt that. Also your reasoning
| about value is confusing.
| Krakodil wrote:
| Interesting. Have you also asked ChatGPT to write Ruby
| code? How much of quality Ruby code can it write in the
| same time?
| tjpnz wrote:
| >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?
| arnvald wrote:
| 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
| lloeki wrote:
| Historically - like, _way_ back - a lot of the Ruby core
| chatter happened on a japanese mailing list, and that 's
| where a lot of decisions ended up taking place, or it
| wasn't uncommon to have sudden hard subjects bombdrop on
| the english side while a lot of discussion already happened
| on the mailing list already so it was hard to catch up.
|
| These days it seems like bugs.ruby-lang.org has most of the
| chatter.
| dismalaf wrote:
| Most of the interesting things happening in the Ruby space
| other than Rails are Japanese...
|
| Mruby for example (embeddable Ruby). It's used a bunch by
| Japanese game studios in place of say, Lua, but it's nearly
| impossible to find any information about how to use it in
| English.
|
| The largest non-Rails focused Ruby convention also happens in
| Japan.
| kamaal wrote:
| >>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.
| arnvald wrote:
| 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.
| kamaal wrote:
| That's not the definition of stagnant I would use. Its
| mostly on the lines of people learning the language,
| starting new projects, discussions etc.
|
| There are more discussions on Perl being dead, than Ruby
| being alive.
| Towaway69 wrote:
| 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.
| michaelbuckbee wrote:
| 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.
| horsawlarway wrote:
| 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).
| my65thaccount wrote:
| Shopify uses Rails to serve nearly a billion users, and
| they fund several people specifically to improve tooling.
| Look into @burke for example.
| dismalaf wrote:
| > At a time where other frameworks (thinking mostly of
| Next+Vercel and Laravel here) are merging their frameworks
| with hosting, deployment, services and ops
|
| You mean doing what Ruby did 19 years ago?
| scop wrote:
| 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!
| futurecat wrote:
| 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.
| top_sigrid wrote:
| Can you elaborate what exactly you mean by that and what you
| encountered?
| futurecat wrote:
| I can't be exact and thorough in a HN comment. I will just
| state that the happy path is too narrow. The ecosystem
| needs a big push for a better DX and a better direction.
|
| Ruby should look at how the PHP ecosystem was modernized.
| Sure the syntax has always been awful and is even more
| degraded now, but the ecosystem is globally in a much
| better place.
| pxc wrote:
| At my place of employment, we use Python for everything by
| default because "everyone knows Python" (which hasn't really
| been true of our small team where multiple members have far
| more experience in other languages than Python).
|
| It grows, in my opinion, out of a desire for programmers to be
| interchangeable code extruders. The idea that a company might
| have to train anyone, or that a new hire might have to
| gradually adjust to a team's chosen languages and idioms, is
| antithetical to the dream of programmers as cheaply replaceable
| cogs in the machine.
|
| This is a chicken-and-egg problem, and I suspect it can only
| really be solved when the labor market for programmers heavily
| favors workers. It's only then that large numbers of
| professional programmers significantly weigh aesthetics of
| language in their choices of job. It's also then that startups,
| which might have cultures that are more opinionated and/or less
| risk averse when it comes to language choice, are abundant and
| thriving. The rise of Python at Google worked on that same
| basis, didn't it?
|
| I don't know that anyone can control the fate of a programming
| language like this. Maybe all you can do is make sure it's a
| lovely, useful language and the rest is up to fate.
| snek_case wrote:
| I would argue that there's obviously value in having your
| company/team use well-known languages and tools if they do
| the job well. Same as using open standards and well-known
| design patterns. If you choose a lesser known language, there
| better be a clear reason why.
| pxc wrote:
| > there's obviously value in having your company/team use
| well-known languages and tools
|
| Sure. I never said this desire on the part of management is
| generally irrational.
|
| It's just that this (often rational) preference for "safe
| bets" leads to ossification and repetition. It's self-
| reinforcing and eventually becomes disconnected from the
| inherent virtues or vices involved in the thing chosen.
|
| If you enjoy participating in this network effect as a
| hiring manager or tech lead or whatever, or feel it's part
| of your duty as an ROI-maximizer, that's fine. You're
| probably right.
|
| It just seems clear that when such feedback loops are
| strong and risk aversion is high, it leaves little room for
| new languages to break into the "market" by competing on
| their intrinsic merits. So when that happens, it'll
| coincide with times and places of relatively high industry
| optimism and developer freedom.
|
| > Same as using open standards
|
| Open standards are about interoperability and user freedom,
| and don't really have anything to do with novelty or
| popularity.
|
| > Same as using [...] well-known design patterns
|
| A common pattern in designs of solutions for common
| problems that is counterproductive, or even just not very
| effective, is called an "anti-pattern". The honorific
| "design pattern" is reserved for patterns that are Actually
| Good(tm) in some way that would hold true even if no one
| knew them.
|
| Consequently, "this design pattern isn't well known" just
| means "this solution is highly effective for addressing a
| common problem, but isn't very famous".
|
| "Use well-known design patterns" is at least as much about
| choosing things because they're elegant, composable,
| flexible, performant, etc., as it is about choosing them
| because they're famous-- hopefully much more so.
| dismalaf wrote:
| Honestly, Ruby being "niche" helps prevent its
| enshittification... JS and Python are being turned into Java.
|
| Ruby is still a great language for individuals who want to do
| things as opposed to simply create slop so they can get a chill
| job.
|
| Forget TIOBE, maybe look at how much actual software or how
| many startups use Ruby. I bet it outperforms relative to the
| total amount of people who use it.
| nonconstant wrote:
| Ruby is #5 most used and #3 most loved programming language in
| the Pragmatic Engineer survey 2025:
| https://newsletter.pragmaticengineer.com/p/the-pragmatic-eng...
|
| It means that basically, Ruby is huge in the SF Bay thanks to
| its adoption by startup founders, but it is a lot less popular
| outside of the Bay Area.
| testdelacc1 wrote:
| Which is not a bad thing. If at least a few of those startups
| become big they could sustain the Ruby community with jobs
| and sponsorship, like Shopify and GitHub do today.
___________________________________________________________________
(page generated 2026-01-02 23:01 UTC)