|
| ▲ | nonconstant an hour ago | parent | next [-] |
| 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 8 minutes ago | parent [-] | | 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. |
|
|
| ▲ | regularfry 10 hours ago | parent | prev | next [-] |
| 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 3 hours ago | parent [-] | | 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. |
|
|
| ▲ | michaelbuckbee 7 hours ago | parent | prev | next [-] |
| 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 6 hours ago | parent | next [-] | | 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 2 hours ago | parent [-] | | Shopify uses Rails to serve nearly a billion users, and they fund several people specifically to improve tooling. Look into @burke for example. |
| |
| ▲ | dismalaf 2 hours ago | parent | prev [-] | | > 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? |
|
|
| ▲ | Towaway69 8 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | mkl95 9 hours ago | parent | prev | next [-] |
| 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 8 hours ago | parent [-] | | >>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. | | |
| ▲ | Krakodil 35 minutes ago | parent | next [-] | | Interesting. Have you also asked ChatGPT to write Ruby code? How much of quality Ruby code can it write in the same time? | |
| ▲ | block_dagger 2 hours ago | parent | prev [-] | | ChatGPT was writing 11+ lines of usable Python every second for 24 hours? I highly doubt that. Also your reasoning about value is confusing. |
|
|
|
| ▲ | pxc 4 hours ago | parent | prev | next [-] |
| 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 3 hours ago | parent [-] | | 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 2 hours ago | parent [-] | | > 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™ 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. |
|
|
|
| ▲ | solatic 9 hours ago | parent | prev | next [-] |
| > 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. |
| |
| ▲ | pxc 4 hours ago | parent | next [-] | | 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 3 hours ago | parent [-] | | 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. |
| |
| ▲ | nmfisher 9 hours ago | parent | prev | next [-] | | 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 8 hours ago | parent | next [-] | | Agreed. I feel like dart is where Python was 20 years ago. It’s exciting and its integration story is taking off. | | |
| ▲ | stephenhuey 7 hours ago | parent [-] | | 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. | | |
| |
| ▲ | solatic 7 hours ago | parent | prev [-] | | > 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 6 hours ago | parent [-] | | 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 3 hours ago | parent [-] | | 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 7 hours ago | parent | prev [-] | | 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/ |
|
|
| ▲ | futurecat 6 hours ago | parent | prev | next [-] |
| 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. |
| |
|
| ▲ | tjpnz 9 hours ago | parent | prev | next [-] |
| >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 8 hours ago | parent | next [-] | | 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 8 hours ago | parent [-] | | 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 2 hours ago | parent | prev [-] | | 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. |
|
|
| ▲ | testdelacc1 9 hours ago | parent | prev | next [-] |
| 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. |
| |
|
| ▲ | scop 7 hours ago | parent | prev | next [-] |
| 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! |
|
| ▲ | dismalaf 2 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | kamaal 8 hours ago | parent | prev [-] |
| >>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 8 hours ago | parent [-] | | 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 7 hours ago | parent [-] | | 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. |
|
|