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.
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.
I found that with CGI::Application, and similar Perl modules you get the facilities of the modern stuff, as well as the portability and simplicity of a simple index.cgi script.
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.
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.
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?
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.
> PHP typically required a web-server, system administration which is old fashioned
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).
Postgres didn't really become the darling of SQL databases until rather recently.. i'd say the last 5-10 years. It was a clunky DB back in the day compared to MySQL.
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.
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.
I prefer Ruby because of it's flexible meta-programming capabilities, like I would easily draft my own DSL if I have an idea of how I want the syntax to look like. This is such a powerful and underrated feature of Ruby in my opinion
Funny, I don't like Ruby because it has easy access to metaprogramming. It's powerful, yes, but in my experience it's a powerful footgun that makes the code very difficult to understand and debug 6 months down the line.
And if you have a bunch of "clever" programmers working on the codebase, the horror...
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.
SPAs are one of those things that few apps truly need. And honestly, these days, if I thought I truly needed an SPA I'd probably just write it in a compiled language that spits out WASM.
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."
It's difficult for enterprise to bet against C# or Java and I kind of get it. Following the crowd is a form of hedging your own career, if things go south you won't get fired for it, but if you bet on an obscure language and framework with no support you will.
God, I had to deal with a junior we hired that wanted and attempt to SPA all the forms on a intranet application form.
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.
> - 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.
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.
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.
Ruby guys have made an attempt to introduce type system few years ago, but they found it nearly impossible to infer types from metaprogrammed code - which makes sense. So they came with the suggestion that you write types for dynamically generated methods yourself. Comeon!
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
True. Ruby JIT has increased performance for some tasks you'd drop down to C for back in the day...
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.
Key is the "@export" statement. Then build Linux dynamic library by doing "odin build main.odin -file -build-mode:shared". -file flag is since I'm just building a single Odin file, didn't set up a project structure or anything. -build-mode:shared is pretty obvious, there's separate build mode flags for Windows or Mac platforms (called "dll" and "dynamic" I think).
That's literally all there is to it. Odin lib is a single file. Ruby code is a single file. Don't even need a project setup since Odin can compile single files into programs or libraries and Ruby can of course link to a shared lib that's anywhere.
> 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.
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...
Basically, the entire data and language processing world works in Python.
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.
> Basically, the entire data and language processing world works in Python.
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.
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.
We actually already have one of those, and it still fits just for a different reason:
> 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"
I always heard it as "The first 90% of the work takes the first 90% of the time, the remaining 10% of the work takes the other 90% of the time." But yeah.
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.
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.
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.
I found that with CGI::Application, and similar Perl modules you get the facilities of the modern stuff, as well as the portability and simplicity of a simple index.cgi script.
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.
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.
> PHP typically required a web-server, system administration which is old fashioned
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).
Postgres didn't really become the darling of SQL databases until rather recently.. i'd say the last 5-10 years. It was a clunky DB back in the day compared to MySQL.
It was clunky because it actually enforced rules.
> When Ruby made western presence it was clunky.
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.
How is it possible that we have this many programming languages and every single one is worse than the other?
Perhaps because:
"There are only two kinds of languages: the ones people complain about and the ones nobody uses" -- Bjarne Stroustrup
My theory is that this world is actually some other world's hell.
By western world do you mean California? Because in Austin rails was huge and I was a lonely Django fan
> 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.
Surely language preference factors in somewhere. Python is opinionated and not everybody’s cup of tea.
I prefer Ruby because of it's flexible meta-programming capabilities, like I would easily draft my own DSL if I have an idea of how I want the syntax to look like. This is such a powerful and underrated feature of Ruby in my opinion
Funny, I don't like Ruby because it has easy access to metaprogramming. It's powerful, yes, but in my experience it's a powerful footgun that makes the code very difficult to understand and debug 6 months down the line. And if you have a bunch of "clever" programmers working on the codebase, the horror...
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.
Agreed!
Rails has bad spa suppott.
SPAs are one of those things that few apps truly need. And honestly, these days, if I thought I truly needed an SPA I'd probably just write it in a compiled language that spits out WASM.
But Rails is hard to beat for CRUD apps.
> 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."
It's difficult for enterprise to bet against C# or Java and I kind of get it. Following the crowd is a form of hedging your own career, if things go south you won't get fired for it, but if you bet on an obscure language and framework with no support you will.
Is that a bug.. or a feature? Probably the latter
U know, nothing beats SPA right ?
…In keeping lots of people employed.
All that extra complexity is great for the economy.
God, I had to deal with a junior we hired that wanted and attempt to SPA all the forms on a intranet application form.
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.
That shouldn't even be web application you should have some kind of off-the-shelf CMS already in use that you can rely on for forms like that.
There is the API only mode :-)
It has bad support for anything that isn’t html.
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.
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.
> [Ruby is] Toyota Camry of languages
This is such a good statement and describes it very well, I'll actually use it!
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.
Ruby guys have made an attempt to introduce type system few years ago, but they found it nearly impossible to infer types from metaprogrammed code - which makes sense. So they came with the suggestion that you write types for dynamically generated methods yourself. Comeon!
> - 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
True. Ruby JIT has increased performance for some tasks you'd drop down to C for back in the day...
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.
> I spent a whole 2 minutes (lol) linking an Odin (my new low-level hobby language) library to Ruby.
Would you mind creating a gist of your steps?
Odin code:
Key is the "@export" statement. Then build Linux dynamic library by doing "odin build main.odin -file -build-mode:shared". -file flag is since I'm just building a single Odin file, didn't set up a project structure or anything. -build-mode:shared is pretty obvious, there's separate build mode flags for Windows or Mac platforms (called "dll" and "dynamic" I think).Ruby code:
That's literally all there is to it. Odin lib is a single file. Ruby code is a single file. Don't even need a project setup since Odin can compile single files into programs or libraries and Ruby can of course link to a shared lib that's anywhere.Thank you so much, that was way easier than what I expected, amazing!
> 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.
> Python is best for working with LLMs
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...
Basically, the entire data and language processing world works in Python.
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.
> Basically, the entire data and language processing world works in Python.
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.
> 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
That's an exaggeration. This can be true in certain cases, but it is not a general rule. YJIT is still orders of magnitude slower than C.
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
Even with AI?
In that case, it'll only take 8 years.
We need a new 80/20 rule. I propose a 90/0. You get 90% done quickly and the other 0% over the next few years .
We actually already have one of those, and it still fits just for a different reason:
> 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"
I always heard it as "The first 90% of the work takes the first 90% of the time, the remaining 10% of the work takes the other 90% of the time." But yeah.
Ha! I've never heard of that one
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++.
Really depends on the org you're in and what ecosystems you need to work with. Almost everything we write is Go based at Microsoft in my org.
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.
Food for thought, thanks!
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.
Appreciate the info, thanks.
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.