I know other frameworks have had asynchronous IO support forever, but it's finally coming to Ruby that seems like it will stick around and be well supported.
My only concern is that none of his work is being picked up by Rails. As a matter of fact, it isn't just SW's work, the whole async story on ruby, it seems neither Fiber or Ractor has reached any mass adoption.
As a Rails dev from 2011-2018, having returned over the past year, it def seemed there was an exodus in or around 2015.
Part of it was due to the rise of SPA and Rails difficulty working with those (webpacker, anyone?), part due to poor perception of Rails 4, part due to newer options such as Elixir/Phoenix or Golang rising in popularity for backend work, part due to many of the leaders such as Yehuda Katz moving on.
Also watching from afar on HN, it seems like Rails 7 release was perceived as a sort of comeback, with quite a few articles posted in recent years praising the framework for a return to relevance.
Then I pray with all my heart that GitLab moves to it, because that's one of the major complaints I hear about folks who use their web interface. Even while I was visiting the site to look up whether their main repo had a .devcontainer folder in it, I could just watch all the stupid ajax-y shit spin endlessly in what is conceptually a static table (sure, it changes per commit, but they're not a stock ticker platform)
OT1H, I know, I know, "MRs welcome" but OTOH as a ruby outsider getting the dev environment up for contributing to them has been a lifelong struggle. Now that Rubymine has support for .devcontainer maybe it'll work better
I'm not saying GitLab is poorly designed, but a poorly designed website will be slow on the fastest of languages or frameworks. It's not necessarily a Rails or Ruby problem here.
I'm not saying you're wrong but this feeling seems to pop up whenever a major RoR version releases. Now maybe ror usage has been trending up but I'm not necessarily seeing it.
I totally suggest diving back in! I'm doing the same. Day job is all frontend, but messing around with Rails again in my own time is reminding me of a much more productive and interesting era of my career. I was lucky enough to be near-ish to Rails World this year, was surprised how many other attendees were in that exact same position.
I think there's a new and healthy rivalry between Ruby, Python, and JS for web backends!
- Ruby and Rails now has all of the things mentioned above and more. I do have concerns that Rails will evolve in directions where bundled frontends have less official support, with the continued centralization of 37signals/DHH [0] and their controversial removal of Typescript from Turbo [1] (and bundling in general for Hey), but it's such a large community that there will be continued momentum in all directions.
- Python used to be the choice if you expected to do both data processing/machine learning/NLP and web backends in a centralized codebase with a single language. And Django is still a world-class solution there, with gevent + asyncio + forthcoming developments on GIL-less Python all contributing towards making Django a highly performant and parallel framework. That said, with much of an app's data processing complexity often best offloaded towards LLM-powered solutions that have dedicated APIs, and both Ruby [2] and Node having bindings to https://pola.rs/ as an alternative to Pandas, it's no longer the only solution.
- And on the JS end, frameworks that enable full-stack batteries-included admin-out-of-the-box development like https://redwoodjs.com/ and https://www.prisma.io/nextjs + e.g. https://next-admin.js.org/ continue to evolve. Nowadays, if you're building a complex web application from scratch, Prisma provides all the escape hatches you'd need, so that you can build entirely in JS/TS and have the facilities you'd expect from Rails or Django.
I'm really excited that all three communities are continuing to push the boundaries of what's possible; it's amazing to see.
IMO the biggest problem with Ruby is still the docs. When you look at https://www.ruby-lang.org/en/documentation, you see a bunch of books - some of which are considerably out of date by now - and the official "API docs". For some mysterious reason, all the actual language features are also listed under API: https://docs.ruby-lang.org/en/3.3/syntax_rdoc.html. Worse yet, there's no proper table of contents - you get a kind of index on the left, but it's alphabetically sorted, and things on the same level are often unrelated. Compare to Python, where you have https://docs.python.org/3/reference/index.html that one can just read in order and end up with a very good understanding of the language.
Ruby dev for several years, I agree with this. It’s a frustrating point, especially after you learn the language and want to use the API docs as a reference. And I say that as a fan of the language.
If you compare, say, C++03 and C++14, it's also technically true that "there's only new syntax", but in practice this often means that hacks that used to be idiomatic before are frowned upon now.
I started learnig rails a couple of months ago. I took a ruby crash course and opened rails guides.
The thing discouraged me to go further was that many sections has work in progress label. I thought I might be looking at the beta docs, but no. I checked the same page down to multiple major version and the work in progress was label was still there.
Coming from Django/Laravel world, incomplete docs discouraged me to try rails.
Hi! The documentation team commissioned by the Rails Foundation is working on tackling and editing the guides one by one, and removing these WIP tags once a guide is complete.
We should see a huge reduction by the time the project wraps, but because Rails itself is constantly evolving, so to is the documentation, so you will continue to see them from time to time. Consider it a sign of growth, not stagnation.
I work on different projects that use with Rails and others that use a microservice-based architecture, and while the trend has been to encourage avoiding monolithic architectures like Rails, I can say that I highly appreciate what it provides at its core. I love that the Rails team continues to trudge forward to add value and improvements despite the trends.
> the trend has been to encourage avoiding monolithic architectures like Rails
I'd say's it's completely the opposite.
Yes, microservices might've been the trend in late 2010s, but after everyone got burned by it with unnecessary complexity (unless you're at "Google" scale), people just went back by being productive building modular "monolithic" architectures, and using "microservices" only when absolutely necessary.
We stopped making microscopic microservices but we still ship services. Services are deployable independently from each other, can be scaled independently from each other. A monolith that results in a single build artifact / executable or whose contents must all run in a single pod or application server is inherently harder for larger teams to work on. Deploying a small change means re-deploying your entire application. Scaling your authz system means scaling up your analytics data producers. Separating your code into services that run and deploy independently from each other means organizations can scale without creating headaches for developers.
> while the trend has been to encourage avoiding monolithic architectures like Rails
I'm of the opinion that this was always bad advice for most people most of the time. Achieving any real infrastructure cost savings this was is difficult, its easy for delivery speeds to suffer, and the debugging experience is terrible.
microservices, like graphql, have certainly fallen from grace by more senior engineers. i see mostly jrs advocate for it because that's what they were taught.
a senior engineer will try to keep the monolith for only as possible and only then explore a new tiny service.
To the contrary, it is often the "senior" engineers that refuse to learn new architectures, and only want to build in ways they already know and used in the past.
I still think, pound for pound, it’s hard to beat the productivity and stability of rails as a framework for new web projects. Welcome changes here, but most notably, this new major version update doesn’t appear to have any real breaking changes with the apps we’ve been running in production for years.
I don't use Rails, but those Solid Adapters look cool. I think people would be surprised how long a RDBMS good enough before moving to more specialized solutions. Just jumping to best of class solutions for cache, pub/sub, full-text search, vector search, document storage, etc. adds too much operational complexity if you can get by just using a single database.
Years ago I was working on a large Drupal site hosted on AWS with RDS MySQL and ElastiCache for caching. We noticed that ElastiCache was slower than we expected and switched the caching backend over to use the MySQL implementation in a simple KV table, and it was quite a bit faster than ElastiCache for most operations.
People really underestimate how good modern RDBMS are, especially when they have their query cache tuned properly, there's no reason to be slower than Memcache or Redis.
I had a Rails job and slipped back into node, and it's so sad. Node is in a sad state compared to Rails. They don't even know what a framework looks like.
It's the terrible standard library of JS that keeps me with Ruby. Rails makes it even better. Being able to write little things like 3.days.from_now to get a timestamp is great.
I missed the big Ruby on Rails fad because I was busy doing scientific computing at the time. But I picked up Rails 3 years ago for a job, and its fantastic. I do wish I picked it up 15 years ago though, I would rather use Rails than Spring, akka, node, or any of the other frameworks ive been using.
I have been doing Ruby on Rails for ~14 years but ~10 years ago I was confused and I picked up Nodejs thinking it is the future of software development.
It only took me a couple of months to realized what Ruby on Rails offers & the vibrant ecosystem it has. I quickly pivoted back to it and never looked back. I'm very happy with that decision.
Take that plunge and you will not regret it later.
I recently went with Laravel, but I really wish I found Django, Laravel, or Rails instead of Angular and React when I was getting started. I'm not a professional dev, but the code I have done at work is all Node. Really happy to see that Rails 8 shipped with an option for auth as well, when I did the Rails demo when evaluating it I was a bit shocked to find there wasn't a first-party solution for auth.
I use Node at one of my employers, and Rails at the other.
It is much easier to switch between them than I first expected. I can quite easily use the idiomatic patterns in either framework. But there are obviously very large differences in the two stacks. The most important that come to mind:
- Rails is much more "batteries included". No need to decide what ORM, queue, mailer, remote storage, etc you want to use for the new project. You just use the built in solution. And you place the files in a pre-defined location. That makes it really easy to onboard new people, because they are familiar with the file structure. On the other hand, for Node projects, you can mix and match your components, and use simpler structures for side projects, and more complex structures (including tools like Nx) for more complicated projects.
- The Rails ORM is much more powerful than the Node counterparts. I think it helps, that the ORM is built into Rails, so everyone contributes to the same product. For Node, it feels as if there are many ORMs that are 70% done, but don't cover important cases. One of them is fast but a bit buggy, one is slow but has the ability to deal with schema migrations, one is old and works well but does not support TypeScript.
- Documentation of Node frameworks, for example NestJS, seems to be updated quicker than the Rails counterparts. For Rails, especially when Turbo was released, there was a kind of vacuum regarding the documentation. The docs for Turbo did explain the basics, but it was very very difficult to get it working with the official docs. Once blog posts started to pop up, it became much easier. Projects like Nest seem to have much more detailed documentation for their components.
All in all, I do prefer Rails tbh. The DRY principle that the framework follows makes sure that you don't have to edit 8 files when adding a new database column. This makes development much faster and in my opinion less error prone.
Playing with a WebDev project in Node.js but jobs with Rails.
Node makes things like OAuth trivial with the mix of Express and Passport, something that took me two weeks in Rails. But man does Rails make Sequelize look childish by comparison.
I'm mainly a Go developer but I've picked up Rails when version 7 came out for all my hobby projects and it's just _fun_ to work with. I don't have to work with complicated frontend tooling and I just push to Dokku to deploy.
As a backend Go developer who had used Rails a lot many years ago, I recently had to do a full-stack project where I got to pick my own stack. I liked the idea of HTMX and also added a-h/templ into the mix. I feel like this setup allows me to be almost as productive as with Rails when doing things that Rails is good at, while enjoying the control and simplicity of the Go approach.
One thing with a larger code base is always the guess work with what object you're dealing with and what properties/methods it does support or does not support increases with the time as the code base grows.
This does not become easier with monkey patching and open classes + lots of meta programming.
I started with Rails during version 1.x and went up to 2.x with it, good fundamentals of Rails have not changed and are the same (inspired others to adopt such as ORM/convention over configuration etc) but lately, I ended up with Go instead for being at least some type system no matter how crude and having a single binary in the end to deploy.
Never have to worry about pip/gem/npm crashing on me. Mostly.
It comes batteries included so in theory I don't even have to think about it. I'm using the happy path of just making use of the included tailwind css setup where I know it'll work out of the box.
The idea of Rails 8 is to move away from trend following and try to reject some of the ideas that have become popular in the industry (like being afraid to touch a Linux server or implementing your own auth). Really though provoking stuff.
Popular ideas are exactly the problem in the industry. I’ve been really put off by what I believe is a lack of critical and original thinking in tech. Bad leadership within management, cult and fad following seems to abound.
I agree. Our industry is perhaps the most cargo-culty industry that I've ever worked in. And the sad part is, unfortunately everybody thinks that they are the paragon of original clear thinking.
I second this. I’m not a ruby dev and I watched the whole talk. It was excellent.
Goes on to show how for many applications overly priced platforms as a service aren’t really needed but incidental complexity masquerading as essential complexity is peddled as a way to make money.
This is part of the reason why I love the Rails community so much. It isn't afraid to break down the consensus and find its own path forward. Often with huge benefits.
>try to reject some of the ideas that have become popular in the industry
just my two cents, the web development has become akin to the fashion industry.
We've seen a steady stream of frameworks emerge, from traditional PHP and JavaScript to JavaScript-based development like ReactJS, AngularJS, and now WebAssembly while tried-and-true methods still work.
all the new frameworks bring benefits – but also introduce problems a few years later. The trends drive the IT industry, fueling a cycle of book sales, training camps, and consulting services that corporations buy into every few years.
It's DHH marketing style (it sez right there in his earlier book: pick a fight).
Back when Rails burst into the scene, he picked the EJB mountain to battle and positioned Rails vs EJB for as long as he could.
This is another battle in the Infrastructure world that he picked.
The timing was perfect too: Rails grew during economy crisis 2006-2009 (layoff, EJB complexity, web-app complexity, the rise of single-developer entrepreneur). Right now we're sort of in similar situation too: layoffs, infrastructure complexity, BigTech culture, FAANG-leetcode grind.
Readit News
- The pickaxe book, Programming Ruby, has a new edition this year covering Ruby 3.3
- The Rails Way is being updated for Rails 8 and is available in pre-release, and will have two companion books
- A new title, Rails Scales, is being published by PragProg and is available in pre-release now
- YJIT has made Ruby fast. Like, _FAST_
- Rails has a bunch of new features that cover the "missing middle" levels of success
- Ruby has a bunch of new and new-ish features like Data (immutable Struct), pattern matching, Fibers and Ractors, and more.
I had largely moved on from ruby into the world of front-end applications by 2013, but now I'm excited about the prospects of diving back in.
It's inspiring other's in the community to think of interesting applications, like using the HTML slot API to stream responses to HTML without JS. https://x.com/joeldrapper/status/1841984952407110037
I know other frameworks have had asynchronous IO support forever, but it's finally coming to Ruby that seems like it will stick around and be well supported.
Seriously, other projects can use its success as a reference for implementation.
And I say this as a front end dev.
Part of it was due to the rise of SPA and Rails difficulty working with those (webpacker, anyone?), part due to poor perception of Rails 4, part due to newer options such as Elixir/Phoenix or Golang rising in popularity for backend work, part due to many of the leaders such as Yehuda Katz moving on.
Also watching from afar on HN, it seems like Rails 7 release was perceived as a sort of comeback, with quite a few articles posted in recent years praising the framework for a return to relevance.
Then I pray with all my heart that GitLab moves to it, because that's one of the major complaints I hear about folks who use their web interface. Even while I was visiting the site to look up whether their main repo had a .devcontainer folder in it, I could just watch all the stupid ajax-y shit spin endlessly in what is conceptually a static table (sure, it changes per commit, but they're not a stock ticker platform)
OT1H, I know, I know, "MRs welcome" but OTOH as a ruby outsider getting the dev environment up for contributing to them has been a lifelong struggle. Now that Rubymine has support for .devcontainer maybe it'll work better
YJIT does make Ruby fast, but that doesn't mean it makes _Rails_ fast. (yet) At least dont expect multiple times improvements.
Hopefully in the future.
Curious, I tried to look for some benchmarks, which still seems to show Node often being 3-10x faster
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
https://bugs.ruby-lang.org/issues/16746
- Ruby and Rails now has all of the things mentioned above and more. I do have concerns that Rails will evolve in directions where bundled frontends have less official support, with the continued centralization of 37signals/DHH [0] and their controversial removal of Typescript from Turbo [1] (and bundling in general for Hey), but it's such a large community that there will be continued momentum in all directions.
- Python used to be the choice if you expected to do both data processing/machine learning/NLP and web backends in a centralized codebase with a single language. And Django is still a world-class solution there, with gevent + asyncio + forthcoming developments on GIL-less Python all contributing towards making Django a highly performant and parallel framework. That said, with much of an app's data processing complexity often best offloaded towards LLM-powered solutions that have dedicated APIs, and both Ruby [2] and Node having bindings to https://pola.rs/ as an alternative to Pandas, it's no longer the only solution.
- And on the JS end, frameworks that enable full-stack batteries-included admin-out-of-the-box development like https://redwoodjs.com/ and https://www.prisma.io/nextjs + e.g. https://next-admin.js.org/ continue to evolve. Nowadays, if you're building a complex web application from scratch, Prisma provides all the escape hatches you'd need, so that you can build entirely in JS/TS and have the facilities you'd expect from Rails or Django.
I'm really excited that all three communities are continuing to push the boundaries of what's possible; it's amazing to see.
[0] https://news.ycombinator.com/item?id=30600746 [1] https://news.ycombinator.com/item?id=37405565 [2] https://github.com/ankane/ruby-polars
Deleted Comment
Sadly, a lot of people still live in the Ruby 1.X era and thinks its slow.
https://web.archive.org/web/20230608024407/https://www.ruby-...
Btw I am contributing myself this year to the book ecosystem by writing Kamal Manual and Test Driving Rails.
I am sure more pure Ruby books will happen too by someone.
The thing discouraged me to go further was that many sections has work in progress label. I thought I might be looking at the beta docs, but no. I checked the same page down to multiple major version and the work in progress was label was still there.
Coming from Django/Laravel world, incomplete docs discouraged me to try rails.
We should see a huge reduction by the time the project wraps, but because Rails itself is constantly evolving, so to is the documentation, so you will continue to see them from time to time. Consider it a sign of growth, not stagnation.
I'd say's it's completely the opposite.
Yes, microservices might've been the trend in late 2010s, but after everyone got burned by it with unnecessary complexity (unless you're at "Google" scale), people just went back by being productive building modular "monolithic" architectures, and using "microservices" only when absolutely necessary.
The number of hi-tech companies that are in the middle-to-large scale have increased significantly from the first wave of Rails era.
Majority of hi-tech companies with listed stock have complexity more than "monolithic" architecture.
Sadly, if a company doesn't grow, they will get eaten by their competitors.
I'm of the opinion that this was always bad advice for most people most of the time. Achieving any real infrastructure cost savings this was is difficult, its easy for delivery speeds to suffer, and the debugging experience is terrible.
a senior engineer will try to keep the monolith for only as possible and only then explore a new tiny service.
People really underestimate how good modern RDBMS are, especially when they have their query cache tuned properly, there's no reason to be slower than Memcache or Redis.
It only took me a couple of months to realized what Ruby on Rails offers & the vibrant ecosystem it has. I quickly pivoted back to it and never looked back. I'm very happy with that decision.
Take that plunge and you will not regret it later.
Don't sell yourself short my friend.
People who know a fraction of what you know call themselves professionals and ask for raises.
Chin up!
Node at work, Rails on the side. Something like that. Feels like a lot to master, but not sure.
It is much easier to switch between them than I first expected. I can quite easily use the idiomatic patterns in either framework. But there are obviously very large differences in the two stacks. The most important that come to mind:
- Rails is much more "batteries included". No need to decide what ORM, queue, mailer, remote storage, etc you want to use for the new project. You just use the built in solution. And you place the files in a pre-defined location. That makes it really easy to onboard new people, because they are familiar with the file structure. On the other hand, for Node projects, you can mix and match your components, and use simpler structures for side projects, and more complex structures (including tools like Nx) for more complicated projects.
- The Rails ORM is much more powerful than the Node counterparts. I think it helps, that the ORM is built into Rails, so everyone contributes to the same product. For Node, it feels as if there are many ORMs that are 70% done, but don't cover important cases. One of them is fast but a bit buggy, one is slow but has the ability to deal with schema migrations, one is old and works well but does not support TypeScript.
- Documentation of Node frameworks, for example NestJS, seems to be updated quicker than the Rails counterparts. For Rails, especially when Turbo was released, there was a kind of vacuum regarding the documentation. The docs for Turbo did explain the basics, but it was very very difficult to get it working with the official docs. Once blog posts started to pop up, it became much easier. Projects like Nest seem to have much more detailed documentation for their components.
All in all, I do prefer Rails tbh. The DRY principle that the framework follows makes sure that you don't have to edit 8 files when adding a new database column. This makes development much faster and in my opinion less error prone.
Node makes things like OAuth trivial with the mix of Express and Passport, something that took me two weeks in Rails. But man does Rails make Sequelize look childish by comparison.
https://github.com/basecamp/thruster
Dead Comment
This does not become easier with monkey patching and open classes + lots of meta programming.
I started with Rails during version 1.x and went up to 2.x with it, good fundamentals of Rails have not changed and are the same (inspired others to adopt such as ORM/convention over configuration etc) but lately, I ended up with Go instead for being at least some type system no matter how crude and having a single binary in the end to deploy.
Never have to worry about pip/gem/npm crashing on me. Mostly.
No pipelines, no minification, no nonsense, just serving js and css directly.
Hey.com works like this, and they reported nothing but improvement.
The idea of Rails 8 is to move away from trend following and try to reject some of the ideas that have become popular in the industry (like being afraid to touch a Linux server or implementing your own auth). Really though provoking stuff.
htmx, Rails, and Laravel all point to better ways, and people are starting to be receptive.
Goes on to show how for many applications overly priced platforms as a service aren’t really needed but incidental complexity masquerading as essential complexity is peddled as a way to make money.
just my two cents, the web development has become akin to the fashion industry.
We've seen a steady stream of frameworks emerge, from traditional PHP and JavaScript to JavaScript-based development like ReactJS, AngularJS, and now WebAssembly while tried-and-true methods still work.
all the new frameworks bring benefits – but also introduce problems a few years later. The trends drive the IT industry, fueling a cycle of book sales, training camps, and consulting services that corporations buy into every few years.
React is 11 years old, AngularJS is 14 years ago, let it go already, gramps.
Back when Rails burst into the scene, he picked the EJB mountain to battle and positioned Rails vs EJB for as long as he could.
This is another battle in the Infrastructure world that he picked.
The timing was perfect too: Rails grew during economy crisis 2006-2009 (layoff, EJB complexity, web-app complexity, the rise of single-developer entrepreneur). Right now we're sort of in similar situation too: layoffs, infrastructure complexity, BigTech culture, FAANG-leetcode grind.
Tech is like a cycle :)
I think rappers invented starting a beef to shift records.
Also, how is he able to use private fields in the js example? Is he using any polyfilling?
It's their own E2E solution for deploying and running Docker apps in production. Solves SSL, proxy, zero downtime deploys, etc.
https://kamal-deploy.org/