back
91 comments
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.

Django too.!! Haha
I considered Django pretty seriously and worked through most of the excellent Mozilla tutorial.

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.

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.
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".

> Most developer have never studied any CS history and are quite young

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.

I'm old enough to have been using Perl with CGI in the waning years of the old millennium. I loved it then, but it's not just hype cycles that caused people to move on to different solutions: Modern stuff is better in a bunch of very real ways.
if you like perl+CGI, then i suggest you take a look at https://harcstack.org
I love this
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.
The money is in working for a FAANG. So that's what Devs trains for.

There's not much money in working for a small saas unless you're the founder.

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
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?

A truly modern language is Rust.

PHP typically required a web-server, system administration which is old fashioned. No one wants to do that which is fine as it keeps me employed.

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.

> A 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.

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 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 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.
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.

Agreed!
Rails has bad spa suppott.
because they are not javascript??? you realise that ruby and php still need to interact to JS in the end

so why not use JS directly or build on top of that???? that's what people do

> - 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 think it's the Toyota Camry of languages. No, it's not the cool thing and won't turn heads or get you compliments.

But it'll take you very, very far for a very, very long time.

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.

I don't buy it anymore

This is where I landed too.

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.

> - 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.

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...

Many times with JIT you don't even need to drop to a more performant language. You can actually get some speed gains by moving C library code back to Ruby so you don't have to pay the translation costs
> 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.

> So just build in Ruby and when you hit a bottleneck, rewrite that bottleneck in C or Rust

Nowadays, yjit is so good that there is no real reason to use c extensions

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.

Re: GitHub.

IF they do a rewrite, that should buy us at least 5 years, based on my experience with large-scale rewrites lol

Re: ZJIT: all development is happening in the open in the zjit folder of the ruby/ruby repo. You can follow along!
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.
Some questions for those with RoR experience…

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?

It's not hard to learn just takes time. Easiest route is to find a job that wants experienced programmers but doesn't care if you have rails experience, there's plenty. Second best route is to just build something with it. For context, personally I hate it 3.5 years in, but I can see why people like it. I would learn it because you have colleagues that use it, or there's companies you like that require it. Most people that think it's a silver bullet are just hopping from something they don't like; you'll find just as many people doing the opposite if you ask around.

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.

1. Your subjective experience learning a new language is going to be up to you and how many languages you know. Ruby feels great from Java and C# to me, but maybe it won't for you.

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.

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.

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 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.

I think this is true about many different aspects of programming languages

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

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.
So much of what goes into a language choice involves things that aren't the language itself but the ecosystem around it. Documentation, standard library, third-party libraries, build and deploying tooling, and so on.

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.

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.

Love rails, hate ruby. Hope one day DHH moves it to clojure or gleam.