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.
> "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.
> 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.
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.
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.
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.
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.
> 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!).
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.
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.
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.
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
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.
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.
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.
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.
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.
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 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 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.
> 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?
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.
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.
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.
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.
* 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.
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 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.
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 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?"
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.
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.
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.
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 :)
Readit News
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!
> "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...
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.
What an insane statement. "Knowledge is bad for you, dummy"?
I think it's more appropriate to call those Rack application servers, Rack being the Ruby CGI Rails implements.
It's a minor nitpick.
> 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...
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.
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!).
It's definitely better but I can definitely see why you'd still choose rails these days.
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.
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.
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.
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.
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.
https://www.techempower.com/benchmarks/#section=data-r23&f=z...
Ranging from 1.5-3.5x faster.
I programmed professionally in C, C++, C#, Deplhi, and a few other languages well before I had even heard of Ruby.
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'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.
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)
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.
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?
Whilst you can use Phoenix without LiveView, this is becoming increasingly difficult as the Phoenix developers have clearly decided that LiveView is The Way.
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.
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.
I would guess running RoR today is 100x cheaper than 10 years before. And will continue to improve as we get ZJIT or running on top of JRuby.
* Python won in data science/analytics and AI/machine learning
* Python also seems to be the high level language used most in academia for non CS engineering (and CS too)
Rails continues to be relatively popular in early stage companies. Plenty of well known companies started with Rails in the last 10+ years and it continues on as part of their stack.
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).
Deleted Comment
Gonna name names? :)
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?
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?"
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.
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.
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
Also, technology choices for B2B web apps is rarely going to be a sole factor in determining success or failure of any business. As much as this community likes to compare performance metrics, benchmarks, frameworks and everyone has personal tastes on what is "good", all of those discussions are mostly irrelevant. Picking something the team is comfortable with and has depth of knowledge in is a good practice.
So just pick Rails and move on with solving business problems :)
I generally don’t use AI during Rails stuff, other than as a hint for a Google search or a docs lookup.
Are you having a different experience?
1. Shoddy output with Ruby and Rails knowledge. In general, I would consider myself pretty advanced with “prompt engineering”.