I don’t understand why Ruby and Rails get a reputation for being outdated or “legacy.” Over the last several years both have seen massive numbers of contributions, both in improvements and new features. I’d be surprised if any tool for building a new web app could even come close to what Rails has to offer across the full stack.
It’s the same thing with php. I would say it’s probably because they are languages from the 90s, but then you have python and JavaScript which are from the same era too and people never question their relevance or “modernity”. All of these languages (even java) have been in constant development since then and all of them have modern features. Why are some considered modern and some outdated when they are all basically from the same era?
Don't recent PHP releases actually have a pretty good selection of nice, modern features? Union types, JIT compiler, pattern matching against types, nullsafe operator, gradual typing, etc. It seems like FP style is better and better supported with each new release, which is another hallmark of modern languages like Rust.
If you're stuck on some cursed, barely-maintained PHP 6 legacy codebase, you can't enjoy these things, but when it comes to choosing PHP for new projects it seems like it's more modern than its reputation.
For anything else you might use ruby for you can use python, so you might as well just use python.
If rails is the best at making web apps, and other ecosystems in other languages maybe get you 90% of the way, might as well use something else and not deal with ruby sucking at other jobs.
I'd say that other frameworks get you 70% of the way of Rails maximum and if that's what your building, it doesn't help knowning that the language is better in other areas you won't use.
It's because it's not receiving a constant hype that other fullstack frameworks have, so people thing it's outdated. But in reality, Rails is boring, it's a beast and it just works
Since it doesn't have as much interest from FAANG people treat it like its dead meat. Rails powers a ton of smaller apps (and some very large ones) but everyone thinks their idea is the going to be the second coming and therefore it needs all the insane optimizations that power Google etc.
I feel its the MVC part that IMHO kind of sucks. I really dont like how it couples you to all sorts of frameworky stuff. A simple router is what you really need in 99% of cases.
I think it's just so strongly associated with a certain era (10-15 years ago) that it's hard for people to get it into the present day. Also, Rails is so dominant in Ruby that there aren't libraries/frameworks for the "latest trends" with as much mindshare.
I wouldn't be against starting a new project in Ruby or RoR.
I've been toying with Perl+CGI-scripts lately and find its super productive with the benefit that I can do serverless without the lock-in.
I don't think the software engineering field is particularly rational and mostly follows trends or what looks good or familiar. We have a proclivity to assume that anything old is legacy. Most developer have never studied any CS history and are quite young, so they're bound to reinvent the wheel as well.
I think its fine to use older technology if its the right fit for the problem, and since the tech is battle-tested, you can read up as to why it went out-of-fashion, and as a result can minimize the risks with using it. It's "predictably disappointing".
This is anecdotal, but one thing I do when comparing languages and frameworks, is browse the most popular libraries on GitHub from that ecosystem, and see how much maintenance they're getting. I usually use the contributors graph, as well as review how/when issues are handled. Ruby projects seem to have the most contributors maintaining the "deepest" libraries of any ecosystem I've seen, consistently, for the longest time. In other ecosystems I keep seeing one guy trickle-maintain some massively popular (based on stars) project that fizzled out over time. You could argue that some of that is due to "completeness", but I keep seeing evidence to the contrary: still many unsolved issues, but the initial activity spike subsides down to a trickle. To me that's what represents the health of an ecosystem: not how many new projects are created, but rather how well supported existing projects are.
I've noticed the exact same thing. Every tablestakes component has a gold standard library (sidekiq, puma, devise, rake, vcr, and so many others) and all seem to have been updated within the last week. The community might be small and have a dull outward appearance, but anyone who works with Ruby knows that the ecosystem has been blooming with life for 2 decades.
> - Rails handles our API, domain logic, and billing workflows.
- Go powers services that need high I/O concurrency or long-lived network connections.
- Rust handles CPU-bound jobs.
Very similar to Shopify. Rails for business line stuff. Go/Rust for performance critical services. React for front end. Python for Datascience/ML.
A language intentionally designed for DX + a pragmatic, stable, well organized framework minimizing boilerplate and BS are still the winning formula for fast web app development.
The productivity and joy I get from working with this stack are immeasurable. I’ve been ruined in terms of having zero tolerance for the agony that comes with the JS ecosystem for example.
I expect a Camry to keep on working with regular, normal maintenance.
I'm probably doing something wrong, but in my experience the amount of magic that Ruby allows (and RoR and library creators use), create for situations where updating code is extremely risky. It can be mitigated by having an extensive testing-codebase, but those only tell you if your assumptions still hold up, they don't help you in fixing your issues per-se.
And half of these tests are checking that your invariants are being upheld, things that you get for free with statically typed languages.
I work with python and typescript (occasionally c++) for my day job. I love getting to ship complete vertical slices of functionality. But I’m tired of all the faffing about. I’m sick of reinventing wheels and integrating with paid services that should be part of a frame work (e.g. auth). And writing the same types 3 times (pydantic, orm, front end)… I just want to focus on my product’s raison d'etre.
And I feel like I’ve found that with Rails. In my free time I’ve recently chosen Rails to build apps for myself. I’m aware that there’s a productivity bias in new projects but so far everything I’ve needed my app to do has come out of the box with Rails (e.g. object storage). If you’ll pardon the pun, I feel like I have these guard rails that prevent me from going off on tangents and keep me focussed on the product.
And I’ve got the app hosted! This is a first for me and I’ve been a dev for 15 years. I feel like a lot of the complexity of web dev is tamed with this framework and that I’m on a very well trodden path.
> So just build in Ruby and when you hit a bottleneck, rewrite that bottleneck in C or Rust...
This is basically what we do at my startup. Though, some things we build elsewher from the start, knowing they need language specific tooling (like Python is best for working with LLMs).
You just can't beat the speed at which you can build business logic in Rails. Most features never hit the point of needing actual, raw performance so on 95% of what you build, you get to work incredibly fast. That still makes up for the 5% of features that you rip out and move elsewhere.
I am hoping we have even more surprises in Rails World in two weeks time.
And may be a glimpse of ZJIT? It is not just Ruby and Rails has gotten faster, CPU performance and core count has been getting cheaper.
One thing I forgot to post last time in the GitHub CEO step down thread. I am hoping Microsoft won't force GitHub to move away from Ruby Rails. I remember there were some noise early on during the acquisition M$ wanted to get rid of it.
Having been on Microsoft acquisition before, generally they encourage .Net usage for greenfield if possible but it’s pretty gentle encouragement. I’ve heard they are getting pretty pushy against C++.
I've always blamed the "rails can't scale" take on how easy it is for inexperienced devs to build full stack apps. But code gen has 1000x this so I'd imagine that will fade.
I wonder if AI will eventually make faster languages (eg Rust, Crystal) nearly as simple to ship with, and therefore a better choice. Or maybe that will end up being a new language entirely.
I wonder how much can be attributed to liking vs disliking low level things. Some people like knowing which register their data is in (and sometimes it actually does matter) while others just don't want to get into those details.
I'd say, don't fight this bias - choose the tools that resonate with you.
1. If you know Python, Lua, JS and C, how hard would it be to learn Ruby?
2. What’s the best way to learn Ruby and Rails today?
3. How important is it that you know the previous versions of Rails? I remember looking for some resources a while ago and got a sense that there’s a lot of history that you need to know to really grok the latest version of Rails.
4. I’m worried about all the “magic” in Rails, but at the same time intrigued by the productivity that brings. Is there something that explains what’s going on behind the scenes?
With rails you'd always have to pay for absence of strict types with extensive testing where you'd basically have to verify that data structures match.
My team mostly writes glue code and infrastructure, occasionally the odd web service that runs in an AWS Lambda. We have a few small CLI tools as well. Most of what we have that isn't written in Bash is written in Python.
The other day I wrote a small script in Ruby, because I wanted to use a first-party SDK in a language I'd at least dabbled in before, and for GitHub, the only such candidate language was Ruby. This tiny little script doesn't do much, and its real (non-dev) dependencies are very few. There's no big framework like Rails.
(I don't have a lot of experience in either Ruby or Python— in school I wrote chiefly Java, and when I was an application engineer, I worked primarily in Scala. I'm more accustomed to statically typed languages.)
I set up more of less all the same stuff for this Ruby project as I did for our Python projects: linters, LSP, code navigation tools, an isolated development environment supplied in part by Nix and in part by language-specific tools, and integrated everything with my Emacs config (with direnv doing most of the heavy lifting; everything should be easy to integrate with VSCode as well). Like some of our Python scripts, it does most of its work with libraries but occasionally shells out to an external command line tool.
From top to bottom, the tooling was better. Choices were simpler and fewer. The default linting rules come from just one place, and are comprehensive and opinionated. The REPL is better and integrates better with my editor. Getting a complete debugger set up was trivial. There's even a gradual typing system that actually does something at runtime, instead of a useless joke that just gives (potentially bogus!) completion hints to your editor. The runtime may be slower, but startup time is better, which is a better fit for our main use cases (CLI and AWS Lambda).
At the same time, the code is better, and effortlessly so. Things that require third-party libraries to do ergonomically in Python (like calling external programs) are just built in and feel good to use. The code feels more concise and the expressions more natural, thanks to small things that have been in Ruby forever, like the "unless" keyword. Exception handling is very concise and doesn't always require breaking things out into multiple indented lines. Passing contexts around is less annoying (though it can't be done as implicitly as in Scala). Besides my code, the language itself feels cleaner. Actually everything is an object. Even statements are expressions.
Are there things I miss? Sure. I'd rather be working in a language with static typing and immutability by default. I'd probably rather work in a compiled language. Maybe what I really want is Gleam or something.
But tbh, our single Ruby codebase feels more modern than anything else we've written, not less. My team has predominantly chosen other languages because "it's more popular" and "it's easier to hire for", but I think that was a mistake.
And what's Ruby's maintainability like? As in, once the project gets inherited by a new dev, or your reach a larger than a couple of devs scale?
Not being ironic, genuinely curious. My only parallel is JavaScript and that becomes a pain in the ass quick due to the small bugs that go unnoticed, even working as a lone dev. TypeScript catches a great deal of those and you can get by with less testing and a more readable (imo) codebase, so a win-win for me.
I've been working with Django/Python for many years, and around 10 years switched to JS stack, because of work (and because I read HN too much).
Last year finally convinced me that the entire JS community is sick, they want to re-invent the wheel all the time and making new libraries obsolete in months. So I started to use Django again. Most of the things needed for MVPs or prototypes are covered by their admin panel, thn when I need to build a front, I decide if use views or a simple frontend (next.js, svelte, etc) that communicates to my API.
39 comments
[ 3.7 ms ] story [ 65.2 ms ] threadA truly modern language is Rust.
Don't recent PHP releases actually have a pretty good selection of nice, modern features? Union types, JIT compiler, pattern matching against types, nullsafe operator, gradual typing, etc. It seems like FP style is better and better supported with each new release, which is another hallmark of modern languages like Rust.
If you're stuck on some cursed, barely-maintained PHP 6 legacy codebase, you can't enjoy these things, but when it comes to choosing PHP for new projects it seems like it's more modern than its reputation.
If rails is the best at making web apps, and other ecosystems in other languages maybe get you 90% of the way, might as well use something else and not deal with ruby sucking at other jobs.
so why not use JS directly or build on top of that???? that's what people do
I wouldn't be against starting a new project in Ruby or RoR.
I don't think the software engineering field is particularly rational and mostly follows trends or what looks good or familiar. We have a proclivity to assume that anything old is legacy. Most developer have never studied any CS history and are quite young, so they're bound to reinvent the wheel as well.
I think its fine to use older technology if its the right fit for the problem, and since the tech is battle-tested, you can read up as to why it went out-of-fashion, and as a result can minimize the risks with using it. It's "predictably disappointing".
Very similar to Shopify. Rails for business line stuff. Go/Rust for performance critical services. React for front end. Python for Datascience/ML.
The productivity and joy I get from working with this stack are immeasurable. I’ve been ruined in terms of having zero tolerance for the agony that comes with the JS ecosystem for example.
But it'll take you very, very far for a very, very long time.
This is such a good statement and describes it very well, I'll actually use it!
I'm probably doing something wrong, but in my experience the amount of magic that Ruby allows (and RoR and library creators use), create for situations where updating code is extremely risky. It can be mitigated by having an extensive testing-codebase, but those only tell you if your assumptions still hold up, they don't help you in fixing your issues per-se.
And half of these tests are checking that your invariants are being upheld, things that you get for free with statically typed languages.
And I feel like I’ve found that with Rails. In my free time I’ve recently chosen Rails to build apps for myself. I’m aware that there’s a productivity bias in new projects but so far everything I’ve needed my app to do has come out of the box with Rails (e.g. object storage). If you’ll pardon the pun, I feel like I have these guard rails that prevent me from going off on tangents and keep me focussed on the product.
And I’ve got the app hosted! This is a first for me and I’ve been a dev for 15 years. I feel like a lot of the complexity of web dev is tamed with this framework and that I’m on a very well trodden path.
> - Go powers services that need high I/O concurrency or long-lived network connections.
> - Rust handles CPU-bound jobs.
It's always amazed me than the discourse around dynamic vs. static languages is that you can't have both.
Like, dynamic languages are literally built on a foundation of static, compiled languages. Ruby's source is C and now some Rust.
So just build in Ruby and when you hit a bottleneck, rewrite that bottleneck in C or Rust...
This is basically what we do at my startup. Though, some things we build elsewher from the start, knowing they need language specific tooling (like Python is best for working with LLMs).
You just can't beat the speed at which you can build business logic in Rails. Most features never hit the point of needing actual, raw performance so on 95% of what you build, you get to work incredibly fast. That still makes up for the 5% of features that you rip out and move elsewhere.
Nowadays, yjit is so good that there is no real reason to use c extensions
And may be a glimpse of ZJIT? It is not just Ruby and Rails has gotten faster, CPU performance and core count has been getting cheaper.
One thing I forgot to post last time in the GitHub CEO step down thread. I am hoping Microsoft won't force GitHub to move away from Ruby Rails. I remember there were some noise early on during the acquisition M$ wanted to get rid of it.
IF they do a rewrite, that should buy us at least 5 years, based on my experience with large-scale rewrites lol
I'd say, don't fight this bias - choose the tools that resonate with you.
1. If you know Python, Lua, JS and C, how hard would it be to learn Ruby?
2. What’s the best way to learn Ruby and Rails today?
3. How important is it that you know the previous versions of Rails? I remember looking for some resources a while ago and got a sense that there’s a lot of history that you need to know to really grok the latest version of Rails.
4. I’m worried about all the “magic” in Rails, but at the same time intrigued by the productivity that brings. Is there something that explains what’s going on behind the scenes?
I don't buy it anymore
The other day I wrote a small script in Ruby, because I wanted to use a first-party SDK in a language I'd at least dabbled in before, and for GitHub, the only such candidate language was Ruby. This tiny little script doesn't do much, and its real (non-dev) dependencies are very few. There's no big framework like Rails.
(I don't have a lot of experience in either Ruby or Python— in school I wrote chiefly Java, and when I was an application engineer, I worked primarily in Scala. I'm more accustomed to statically typed languages.)
I set up more of less all the same stuff for this Ruby project as I did for our Python projects: linters, LSP, code navigation tools, an isolated development environment supplied in part by Nix and in part by language-specific tools, and integrated everything with my Emacs config (with direnv doing most of the heavy lifting; everything should be easy to integrate with VSCode as well). Like some of our Python scripts, it does most of its work with libraries but occasionally shells out to an external command line tool.
From top to bottom, the tooling was better. Choices were simpler and fewer. The default linting rules come from just one place, and are comprehensive and opinionated. The REPL is better and integrates better with my editor. Getting a complete debugger set up was trivial. There's even a gradual typing system that actually does something at runtime, instead of a useless joke that just gives (potentially bogus!) completion hints to your editor. The runtime may be slower, but startup time is better, which is a better fit for our main use cases (CLI and AWS Lambda).
At the same time, the code is better, and effortlessly so. Things that require third-party libraries to do ergonomically in Python (like calling external programs) are just built in and feel good to use. The code feels more concise and the expressions more natural, thanks to small things that have been in Ruby forever, like the "unless" keyword. Exception handling is very concise and doesn't always require breaking things out into multiple indented lines. Passing contexts around is less annoying (though it can't be done as implicitly as in Scala). Besides my code, the language itself feels cleaner. Actually everything is an object. Even statements are expressions.
Are there things I miss? Sure. I'd rather be working in a language with static typing and immutability by default. I'd probably rather work in a compiled language. Maybe what I really want is Gleam or something.
But tbh, our single Ruby codebase feels more modern than anything else we've written, not less. My team has predominantly chosen other languages because "it's more popular" and "it's easier to hire for", but I think that was a mistake.
Not being ironic, genuinely curious. My only parallel is JavaScript and that becomes a pain in the ass quick due to the small bugs that go unnoticed, even working as a lone dev. TypeScript catches a great deal of those and you can get by with less testing and a more readable (imo) codebase, so a win-win for me.
Last year finally convinced me that the entire JS community is sick, they want to re-invent the wheel all the time and making new libraries obsolete in months. So I started to use Django again. Most of the things needed for MVPs or prototypes are covered by their admin panel, thn when I need to build a front, I decide if use views or a simple frontend (next.js, svelte, etc) that communicates to my API.