Fast, cheap, good - pick two. Seems like a non-profit fund paid probably tens of thousands of dollars for this RoR audit. Can you raise the same amount to audit Django or convince a fund to spend money they already raised? If so, great!
> Due to the size of Ruby on Rails, it will not be possible to cover all the tests and tasks in the following test plan. The tests performed will be covered in the final report along with suggestions on what to focus on in future audits.
I feel like these sorts of audits are usually performed on individual applications rather than "mature" already widely used frameworks. I've got the sense that they are meant to give confidence that the developers knew what they were doing (since they focus on typical vulnerabilities that good developers should know about), rather than proving anything about the code base. Still better than nothing.
[0] Section 3.7, https://ostif.org/wp-content/uploads/2025/06/X41-Rails-Audit...
I think it's more appropriate to call those Rack application servers, Rack being the Ruby CGI Rails implements.
It's a minor nitpick.
A rumor perpetuated by exactly one company - Twitter. I know because I was there when it happened and helped dismantle the original monolith.
Rails scales just fine for 99%+ of business cases. If you're doing a sustained 5k writes per second with bursts up to 100k...sure maybe you need something more specialized.
Even the slowest web frameworks running on modern hardware take some quite substantial load before they're a problem. It's good when choosing a framework to consider if you're doing stuff where that might be a problem, but it's also good not to overestimate the performance needs for your site.
Doing things that don't scale is a proven strategy at the beginning, pg even has a post about it
Plenty of newer startups use Rails. At least several pretty much every YC batch. You just need to pay attention.
There are others you can use if you like.
Ruby should take lessons from Python and TS on how to make proper gradual typing.
That retain Sorbet’s fast static checker and its runtime checks which Typescript compiled to JS lacks.
> a failure to type all the things and make it work
Everything is typed in Ruby.
Elixir is more performant, has compiler safety guarantees that are only getting better as types are introduced, is actually designed from the ground up for web dev (being based on the Erlang VM), and... it's just way more fun (subjective I know). Elixir is what I always wished Ruby was, and I couldn't be more excited about the coming type inference.
Programming with Elixir makes me feel like Ruby is a previous generation language, much like Ruby made me feel that way about Cobol or Fortran, it really is that stark.
I like Ruby, and I feel it has significantly prettier syntax, to me, than Elixir. So that’s a big reason why I also like rails.
also activerecord doing "trust me bro" things behind the scenes (like pluralization) drove me up the wall.
to be fair ecto does a small bit of this too, but at least it doesn't change spellings (so you can global search an identifier).
It's definitely better but I can definitely see why you'd still choose rails these days.
Given how rarely this comes up it feels like a tolerable problem that will only diminish as Elixir adoption continues to increase; I am aware of many rail shops that are slowly and quietly switching everything to Elixir, and it feels like that snowball continues to pick up pace as Elixir improves and those libraries are created.
Nit: this makes it sounds like the BEAM was designed for web dev, which it was not. Erlang came out of Ericsson and was built for telecoms (OTP stands for Open Telecom Platform), which is where its unique set of trade-offs comes from. Many of those trade-offs make a ton of sense for web but that's not because it was designed for web, it's because there's overlap between the fields.
One way to see the difference between telecoms and web is to ask yourself when was the last time that you were working on a project with an availability SLA of 9 nines (1/3 of a second of downtime per year) or even 6 nines (32s per year). Some web dev has that, but most doesn't come close, and if that's not you then Erlang wasn't built for you (though you may still find you like it for other reasons!).
Whatsapp and telecoms have a lot in common, so no one questions that they benefited a ton from the BEAM.
Airbnb, though? The main similarity is that they both send large quantities of signal over wires.
Again, none of this is to stop you from liking the BEAM, but when we're talking about professional software engineering it pays to be explicit about what the design constraints were for the products that you're using so that you can make sure that your own design constraints are not in conflict with theirs.
since BEAM gives you smart disconnection handling, web stuff built in elixir gives you the ability to build on client-server distributed without too much headache and with good defaults.
but look, if you want a concrete example of why this sucks. how much do you hate it when you push changes to your PR on github and the CI checks on browser tab are still not updated with the new CI that has been triggered? you've got to refresh first.
if they had built github in elixir instead of ruby would almost certainly have this sync isdur solved. in maybe two or three lines of code.
I'm not cautioning against making the calculated decision that realtime is a core requirement and choosing the BEAM accordingly. I'm cautioning against positioning the BEAM as being designed for web use cases in general, which it's not.
Many projects, including GitHub, do not need that kind of immediate reactivity and would not have benefited enough from the BEAM to be worth the trade-offs involved. A single example of a UX flow that could be made slightly better by rearchitecting for realtime isn't sufficient reason to justify an entirely different architecture. Engineering is about trade-offs, and too often in our field we fall for "when all you have is a hammer". Realtime architectures are one tool in a toolbox, and they aren't even the most frequently needed tool.
what price? learning a new language that is designed to be learned from the one you already know with fewer footguns? ok fine.
but you make it seem like going to elixir is some kind of heavy lift or requires a devops team or something. the lift is low: for example i run a bespoke elixir app in my home on my local network for co2 monitoring.
and for that purpose (maybe 300 lines of code? yes, i do want reactivity. wrangling longpoll for that does not sound fun to me.
* A much smaller ecosystem of libraries to draw from.
* Much weaker editor tooling than with more established languages.
* An entirely different paradigm for deployments, monitoring, and everything else that falls under "operations" that may be incompatible with the existing infrastructure in the organization.
* When something does go wrong, using a weird stack means you have less institutional knowledge to lean on and fewer resources from people who've been doing the same thing as you.
* A whole new set of foot guns to dodge and UX problems to solve related to what happens when someone's connection is poor. This has come up repeatedly in discussions of Phoenix LiveView—what you get in reactivity comes at the expense of having to work harder to engineer for spotty connections than you would with a request/response model.
* More difficulty hiring people, and an increased tendency when hiring for selecting people who are really just obsessed with a particular tool and unwilling to see when the situation calls for something else.
There are many more, these are just the ones I can think of without having a concrete application with concrete requirements to analyze. In the end for most apps reactivity is so much a "nice to have" that it's hardly worth sacrificing the stability and predictability of the established option for moderately better support for that one aspect of UX, especially given that you can always add reactivity later if you need to at a slightly higher cost than it would have come at with Erlang.
If reactivity is a core requirement, that's a different story. If it's polish, don't choose your architecture around it.
https://www.techempower.com/benchmarks/#section=data-r23&f=z...
Ranging from 1.5-3.5x faster.
I thought to include other implementation from Ruby and Elixir. Rails has always been doing much more and on the heavier side of things. There are also many test that simply by switching server to iodine brings the performance to Elixir / Phoenix level.
IMO TechEmpower lost all credibility long time ago after it was demonstrated they do nothing against heavily gamed benchmarks where people literally do basic string matching against regexes instead of doing proper HTTP parsing. Some even relied on characters being at exact positions.
Add to this how slow they were to adopt normal production application code changes to Elixir apps where it was proven that the author of the benchmark had no idea how to code an Elixir/Phoenix app and yeah, it does not look good for TechEmpower.
All that being said, use what you like (some even expressed the confusing stance of "I like Ruby's syntax more" which, need I even comment how unprofessional that is?). But to claim Elixir is just some mere 2x times faster than Ruby is misguided. My real production experience from the last 10 years says this is bull.
I simply cannot respect that.
Having a preference though? Yeah, absolutely fine. We all do.
Add in problems finding developers skilled in Elixir and Phoenix and the small available libraries.
Of course, you also have that to some degree in Rails but it is much less pronounced.
Is this actually a problem you see? I'm going on 15 years in the industry and haven't seen any issues training people up on a new language in just a couple months.
If you need an expert in some library or language to make meaningful business progress I feel like that says more about whatever tool or language you're using, and I simply don't see that with phoenix or elixir in the years I've worked with it.
I think that this is one of the reasons networking is becoming more and more important, because it lets a candidate demonstrate their generally-applicable development skills to a fellow engineer who is capable of making qualitative engineering judgements.
Some years ago the largest company using Elixir in the US, or at least on the west coast, abandoned Elixir because they couldn't find enough developers.
Yes. The adoption is poor despite the loud voices.
Since the last 12-15 months, every Elixir job posted gets literal hundreds of applications. Just saying.
Try to create a way for people to upload documents like images and PDFs and documents. Okay easy enough on both platforms and I want you to generate a preview for each of those files so that people can easily find those files. Now I want you to add pagination. Now I want you to add column sorting so that people can sort by file size or by name or by upload date. Finally I want you to add a search field. Going by the way all of this stuff needs to live in the URL so that you can bookmark all the different you know choices you've made.
The stuff is pretty trivial and rails but in elixir you would have to bake it all yourself very boring code that doesn't really matter. This is why I chose to build my startups admin dashboard in rails despite our main production API being an elixir.
In terms of successors there’s maybe Julia, or otherwise you’d have to use Python or Matlab/Octave, with all that going to a scripting language entails. In any case it doesn’t really feel like there’s been a replacement.
In the beginning when Ruby on Rails said hello to me, I instantly fell in love with it and the simplicity and the natural semantics that flow with it. It was absurdly easy to write new features and ship them to production. As the codebase grew and the team grew we started running into situations where APIs broke, or to trace the workflow of things in terms of finding where methods came from, finding parent modules of modules, and finding their parents, configuration, and I started to note a general lack of IDE autocomplete and type-safety.
Then after a few years I jumped ship to Elixir and if felt like a breath of clean air when I had to learn FP. Everything was simple enough to understand. Performance knocks Elixir, Node, Python and any other interpreted stack out of the water. The Phoenix framework was, and is said to be thoughtfully designed and although there was no IDE support, we still had Elixir LS which was great enough to provide realtime guidance, linting and type safety during compile time. I was able to ship a very large app into production and it was bulletproof. The problem with Elixir was our other engineers struggled to shift away from Node, or any other stacks they already knew. They found the entire FP world to be weird. Hell, I found it weird too at times. Simple mutations of maps and arrays, that would be trivial in Ruby ended up being so complex in Elixir. In the end it felt like my team was not on the same page. I guess Elixir would be great if you ran a 3-person team or something, but since we were not, we got back to Ruby. In today's world though, I am largely looking at Go, for a backend system. IDE support is up there with Java, and the ecosystem is old and mature enough to find any package that you look for. Performance is C-like and learning curve is lean.
Just my 2c with all these platforms.
At this point, I putting together teams and getting new developers into Ruby on Rails. I'm also seeing companies move back to full stack RoR after the luster of React has worn off. Also, modern RoR can get you so far now with a fraction of the dual framework headaches of a RoR backend/JS frontend.
Any MVC framework with HTMX, JQuery (yes)/Hotwire/Stimulus/Turbo, etc. puts the productivity and deployment speed of the front-end setup above to extreme shame.
I did maybe 5 years of Phoenix for a customer of mine and went back to Rails for another customer. It's good enough and overall Rails is easier to deploy IMHO. Capistrano vs I don't remember what.
Whilst you can use Phoenix without LiveView, this is becoming increasingly difficult as the Phoenix developers have clearly decided that LiveView is The Way.
It's just so hard sometimes to wrap your head around the abstractions, even though they are shallow + things are changing fast. I feel like my django-ish mental modal of web applications is also getting in the way a lot.
It would probably help, if I could spend more time with less interruptions on it. But I have to say that I expected to get into it a lot quicker since it's praised so much for it's dev experience.
Despite the popularity, node never caught up with rails in terms of features and productivity. I was part of a replatforming from rails to node some 10 years ago. So many things we had to just rewrite because there was no option at the time in node. The team lead that made the decision left half-way through the project. Second worst thing to happen to me in my career, after covid of course.
The only thing I would ever want from js is destructuring assignment. There's rightward assignment in ruby now but it's pretty clunky.
> became Java
Best laugh I've had all week.
I would guess running RoR today is 100x cheaper than 10 years before. And will continue to improve as we get ZJIT or running on top of JRuby.
* Python won in data science/analytics and AI/machine learning
* Python also seems to be the high level language used most in academia for non CS engineering (and CS too)
Rails continues to be relatively popular in early stage companies. Plenty of well known companies started with Rails in the last 10+ years and it continues on as part of their stack.
New things are "simple", and old things are inevitably complex, which always attracts the new generation of inexperienced coders (I include myself in this). This continues until all of the complexity of the domain are captured in the "new" thing, and the cycle begins again. Rails is vastly more sophisticated than when I started using it in ~2007, when things like CSRF attack mitigation weren't even built in. So it's a better framework now, but you have to understand a lot more to get started.
Also, from ~2012 until recently, bootcamps have been pumping out new programmers who only know Javascript because it was possible to do a full-stack web app with JS, and the bootcamps would rather not teach another language.
Also, technology choices for B2B web apps is rarely going to be a sole factor in determining success or failure of any business. As much as this community likes to compare performance metrics, benchmarks, frameworks and everyone has personal tastes on what is "good", all of those discussions are mostly irrelevant. Picking something the team is comfortable with and has depth of knowledge in is a good practice.
So just pick Rails and move on with solving business problems :)
I generally don’t use AI during Rails stuff, other than as a hint for a Google search or a docs lookup.
Are you having a different experience?
1. Shoddy output with Ruby and Rails knowledge. In general, I would consider myself pretty advanced with “prompt engineering”.
I find if you get too lengthy with tasks or too advanced AI goes off the rails so to speak, sorry for the pun.
To me it is better now, but not as good as certain languages. Since that I'm using Go as well, I do notice Claude Code perform better with Go.
> it’s about your taste and philosophy.
Personally, method_missing goes against both of mine. It makes programs harder to reason about, more difficult to debug, and nearly impossible to `grep`. That said, I understand that this kind of flexibility is what some people like. I just don’t.
Can you expand on what you’re saying here or why you’re raising this is as an issue with ruby the language or rails the library?
This is one of those things that sounds like it'd be a problem but it really isn't
After 10 years working with Java. Now I dont wanna go back anymore.
It is about your taste and philosophy. I dont think it related skill issue.
The ecosystem, toolchain and all do a lot. It is really missed when I do other languages, and I wish to find the same way of developing elsewhere. I currently do C for embedded in an horrible IDE, and I want to bang my head against the table each time I had to click on something on the interface.
(btw Python is a nightmare for me)
I'm also an expert in C, Go and JavaScript. Ruby is an excellent language and the smalltalk paradigm has some real strengths especially for duck typed systems. The only reason I don't use it more often is because it is slow for the type of work I'm doing recently.
It was amazing for web work and it's fantastic for writing small little utility scripts.
A open distaste for things does not make you sophisticated or smart. You're not in any category of high repute when you do this.
I started from a background of heavy C++ use, including a lot of template metaprogramming. Convincing me to even give Ruby a chance took a lot, but once I'd tried it I abandoned C++ pretty much immediately, and don't miss it.
I mean if you look at one file the code seems fairly clean and well written, but if you try and figure out e.g. where a function is called from... well good fucking luck! There's no static typing to help you, and even worse it seems like almost everything is "magically" connected. Like you'll have a function called `foo_bar()` and if you grep for that you get zero results. In the end you'll find that in the `Foo` class there's a list of strings including `BAR` and it constructs the identifier from those.
Absolute nightmare. But people do seem to love Rails... so why?
The web frameworks we're talking are Rails, Django, Laravel & Spring.
- SvelteKit
- RedwoodJS
- Wasp
There are more options but I think they’d cause more “well, actually” comments than I could bear. :-)
Some friends just notified us that this is trending.
Let me know if you have any questions/comments/feedback about the work! It was a great project, I wish we had more budget so that we could spend some time with ruzzy and the C extensions as there's probably some things to be unearthed there with ASAN and UBSAN.
As for the comments on Spring/Elixir/Django/Phoenix, they're on our wish list every year but we're always limited by funding. It's about what the communities, foundations, and agencies can and will support. We are always working toward getting larger grants where we can work fully independently on whatever we want, but so far that hasn't materialized.
We'll keep trying!
ksec•8h ago
[1] https://www.x41-dsec.de/static/reports/X41-Rails-Audit-Final...
technion•7h ago