Why we still build with Ruby
getlago.com
getlago.com
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.
I prefer Django's having models defined in code and being able to generate views and migrations based off these. The auth situation seems more robust.
Obviously there's direct benefit to me with working with a familiar language.
The decision to give Rails a go instead really game down to me trying to minimise how many pieces I need to tape together. And with Django it seems I'd need to sort out my own frontend story and build my own deployment process. Rails has defaults for both of these now. I'm fully prepared I might decide to rebuild with Django in the future, but right now Rails is working.
A truly modern language is Rust.
When Ruby made western presence it was clunky. No one knew what it was and it got stuck with that personality. It had an ecosystem too but never hooked in to the western world.
Java is tainted by Oracle and seen as "business".
And it's also weird how Postgres has made an uprising appearance. It was sitting duck back in the 00's. I knew it existed because as an script kiddie I could install a php forum and select it as a database backend but I never did.
Want to make a LCD display? You can simply by slapping a python library in to your code.
Ecosystems pull coders in. Thinking about it, it's probably why Perl was popular before with CPAN.
The old net was special but skills had to be learnt. Remember the days when you had one server for one service?
The new net is terrible but everything is handed to you on a golden plate.
IMHO deploying PHP to production is easier than Ruby/Python. You need a web-server but once it's configured (not a rocket science) you just copy all .php files. For ruby you also want to have a web-server (e. g. nginx) unless the load is negligible. If you want to deploy a project with all dependencies you probably need something like rvm but some gems would be easier to install form OS packages (like pg or other wrappers around C/C++ libraries installed from OS packages too). And then for ruby you need an additional daemon (HTTP) which will be restarted on updates (and auto-restarted if it will crash).
"There are only two kinds of languages: the ones people complain about and the ones nobody uses" -- Bjarne Stroustrup
At least when I first encountered Ruby it felt somewhat cool and exotic, I think because of a combination of its friendly website (compared to say Java), Japanese origin, and the fact that some of the first Ruby I ever learned was from why's (poignant) Guide to Ruby.
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.
All that extra complexity is great for the economy.
I struggled to explain I would now have to spend 4 hours updating dependencies, maintaining a node js pipeline and dealing with typescript all because you couldn't handle adding a new fucking single form input to a form with only 3 existing inputs, which would have taken only 3 lines of code between the HTML and C#. The cake was this is an intranet app where the entire form only gets used a few times a year at best.
But Rails is hard to beat for CRUD apps.
I'm honestly surprised it didn't take off massively for internal enterprise CRUD stuff. It's by far the most productive stack I've ever used, the second closest being .NET w/ EntityFramework.
It was the darling of the early SaaS explosion of the early 2000s, and then just kind of died off in hype.
I like that it's opinionated, stops be from going down rabbit holes, and batteries included. There's nothing in the JS/TS framework of the day world that leaves me wondering "hmm, maybe I should stop using rails for this." It all seems worse, somehow, despite being more "modern."
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
There's not much money in working for a small saas unless you're the founder.
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".
Two things I think Perl always had a good reputation for was CPAN, providing interfaces to "everything", and a high degree of testing. I love that golang and rust both emphasize testing in modules/crates/packages. Writing perl CGI scripts I always had test-cases for the whole lifecycle, and that's something that isn't so common these days writing handlers in other languages.
Even the ones who studied it still fall into the trap of novelty for novelty sake. I'm guilty of that as well 20+ years ago at the start of my career, I believe it's one of those wisdom rites of passage someone needs to go through to value the lesson.
Boring old tech that works is pretty good, if it's not unmaintained, gets updates while keeping a stable core, has an ecosystem of good libraries and documentation, I'll always choose it over some new fangled thing from the past 2-5 years.
You need to feel the pain of depending on something that is taken away, or dies a slow but surely death, or creates massive headaches to upgrade, to value the stability of boring old tech.
I feel it's a cycle bound to be repeated by each generation.
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.
I don't buy it anymore
Type system support, and the tooling around that support, has gotten SO much more powerful in the last decade or so.
Lots of the warts also got burned off with better support for smart typing, auto vars, duck typing for inputs, etc.
That tooling covers a HUGE swath of bugs that I just don't have to worry nearly as much about, and it makes quick refactoring less painful and less risky.
Going back to Rails feels like stepping back into the dark ages. So many stupid repeated tests/specs for things that should just be in a type system. The tests are slower to write, cover less ground, and are much more brittle.
My tooling isn't as capable, my feedback loop is slower (hard to beat instant type hinting for errors/mismatches right in my editor as I type), and I feel like I'm working with a blindfold on.
---
Yes, parts of Rails are great, yes - if you know it already it's a very productive environment. But man do I absolutely hate the lack of interest in type systems from the majority of Rails devs.
It's hard to overstate how valuable it is to be able to change a data structure and have all 29 places you might have broken immediately presented to you with basically no effort on your end outside of some minor type work.
I will pick it every time over having to write 29 specs in rails to get even close to the same safety.
> - 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...
All the gains Ruby has made in the last few years are pretty incredible. I never picked it because of performance reasons but it's pretty nice that it's getting faster.
Either way though, Ruby FFI is super super easy. Just for fun, because of this thread, I spent a whole 2 minutes (lol) linking an Odin (my new low-level hobby language) library to Ruby. Literally all it took. Credit to Odin for having such easy export and Ruby for having such easy FFI.
Would you mind creating a gist of your steps?
package main
import "core:fmt"
@export
sayhi :: proc() {
fmt.println("Hello World")
}
Ruby code:
require 'ffi'
module MyLib
extend FFI::Library
ffi_lib "./main.so"
attach_function :sayhi, [], :void
end
MyLib.sayhi
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.
Just curious how you're integrating LLMs... Self hosting?
I've been using RubyLLM and find it pretty decent for my needs, it's also improving at a very rapid rate. But it does focus on the most common providers and tools...
It's not that tools don't exist in other languages. It's that Python has the most readily available tooling. That makes analysis and iteration a lot easier.
Dunno, when I started I learned Stata, but it seemed the big open-source thing was R. Python data stuff was in its infancy. R got huge, then Python got huge. Of course all the underlying libraries are C/C++ or Fortran. Everything does exist in Ruby as well.
But hey, I also just hate Python (find it super complicated to set up, their package managers are terrible, plus find the language inconsistent) so I avoid it at all costs. Would much rather Julia become the de-facto standard.
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
> The first 90% is easy/fast/cheap, it's the second 90% that's hard/slow/expensive
Since most of the generative approaches treat code as disposable, then the second (and subsequent) 90% approaches just throw it away and start over. It's like all the awesome parts about a rewrite, with all the awesome parts about "it was rewritten because no one understood it"
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?
2. The Rails guides (official) are great to learn the framework.
3. It's only relevant to learn the older versions of the framework if you're going to a company on the older versions. Realistically, 5, 6, 7, and 8 are all very similar and I would argue it's more important to start with the newest stuff and focus on upgrading apps the newest version than trying to learn the older versions (not for any particular reason, other than there have been meaningful improvements in later versions).
4. The source code, contrary to popular belief, is quite well-documented, and the official guides are also very well written. A lot of the "magic" is just DSL/plumbing that exists in the actual framework. I personally keep a copy of rails/rails locally so I can look at things when I want to, because it's really that readable.
On point 4 it does make you more productive for run of the mill CRUD work, but now that AI has gotten so good, I'm not actually sure that's a major benefit. I.e. it replaces configuration / boilerplate with magic, but AI can write boilerplate / pattern match really really well. I bet writing in Go saw a huge boost from AI.
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.
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'd say, don't fight this bias - choose the tools that resonate with you.
There are many things that ultimately come down to personal taste more than some sort of objective pros and cons list, as much as people will attempt to argue otherwise
So a huge part of getting people to move from an existing tool they know with a well established ecosystem to a new tool that perhaps doesn't have that yet is getting those things in place (and then getting people to want to use them). I can imagine that being able to boostrap part of that process could help with the adoption of new tools.
The counter argument is that the friction behind these things is actually a benefit, as languages are only useful when they're shared and it doesn't make sense to have a huge range of languages that all mostly function the same but are just different synatcically. So it's a feature that it takes time for newer languages to gain traction, because it's essentially being tested for suitability and usefulness by a slowly growing number of people, at first the innovators, early adopters and early majority on the curve and later on the ones that perhaps can't afford to spend time on something that might not gen enough traction to last.
On a related note, I'm curious to know what the impact of generative AI on language-interoperability will be. Every time I see a suggestion that WASM and Interface Types is the thing that will finally allow me to use that weird but useful Python library in my Rust project, I always feel like unless there's a performance consideration involved I'd really rather just have everything in the same language, so the idea of automated translation of libraries at the source level seems like it could be useful. No need for language interop when you can quickly put everything into the same language.
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.