I'm optimistic about Ruby's async story with the work Samuel Williams has been doing. https://github.com/socketry/falcon is the tip of the iceberg, which is built on top of https://github.com/socketry/protocol-http2 and a not of other repos at https://github.com/socketry.

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.

I would argue - its not a comeback, it was always the "king" of web dev.

Seriously, other projects can use its success as a reference for implementation.

And I say this as a front end dev.

> - YJIT has made Ruby fast. Like, _FAST_

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

Also: Endless Ruby!

https://bugs.ruby-lang.org/issues/16746

Interesting that both ruby and python are on the jit path. less is more.

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.

[0] https://news.ycombinator.com/item?id=30600746 [1] https://news.ycombinator.com/item?id=37405565 [2] https://github.com/ankane/ruby-polars

Do you have any benchmarks to share on YJIT?

those old books are still good though. There's only new syntax for latest ruby versions.

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.

> 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.

> 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.

It's never too late! The Rails community is very welcoming.

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 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 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.

If you do node professionally, you should be able to pick up Ruby on Rails in a weekend.

Curious if anyone is out there doing both effectively.

Node at work, Rails on the side. Something like that. Feels like a lot to master, but not sure.

No reason you can’t start now!

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.

All the Solid Adapters but they couldn't name one as Solid Snake. Huge waste of opportunity. Hopefully more to come in 8.1

What do you use for frontend tooling then? Somehow you have to compile scss and do some mild js bundling or so?

That new proxy they've developer "thruster" is written in go

https://github.com/basecamp/thruster

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.

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 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.

Tech is like a cycle :)

His compagny seems to like re-inventing the wheel with vastly inferior solutions though.

For caching specifically solid_cache works better for long lived and larger caches than does Redis. If you need short lived and smaller caches Redis will be more performant for you.

That said you can probably get away with caching way more with solid_cache and it's highly dependent on what your use cases are.

Also a thing to note that your DB backing solid_cache might also be using RAM efficiently, giving you a lot of benefits that Redis did.

For new projects I'll be using solid_cache first and adding Redis only on an as-need basis. The cost of Redis is orders of magnitude higher than a DB backed cache.

I had a bad experience with Action Cable + Redis (extremely high memory overhead, tons of dead redis connections), so it's a bit "fool me once" with regard to action cables.

The main argument for caching in the DB (the slight increase in latency going from in-memory->DB-in-memroy is more than countered by the DB's cheapness of cache space allowing you to have tons more cache) is one of those brilliant ideas that I would like to try at some point.

Solid job - i just am 100% happy with Sidekiq at this point, I don't understand why I'd switch and introduce potential instability/issues.

I have used both with rails. (Cable is still going through Redis tho).

Solid cache is perfect for my use case since page caches doesn't change as often, so taking a smaller memory footprint on the server farm is a win.

My take is to measure your cache hit percentage. This will allow anyone to understand their cache eviction rates. If you have high eviction rates maybe using a btree is not the way to go and redis is probably better

I havent used them, and we are not moving to them on our existing app but I can super-appreciate the fact that by default redis is more of a down-the-road decision now. No reason to get into the complexity (+ additional hosting cost) of adding another service into the mix until you choose to later on.

I'm sticking with redis purely because it's battle tested and I'm not endowed with enough talent nor time to work through kinks in Solid.

On Rails homepage, it says from “Hello World” to IPO. The idea is that Rails should help you maintain a lean stack by default. You can stick with Postgres for pretty much everything: caching, background jobs, search, WebSockets, you name it.

But, as your app grows, you can swap things out. Redis or Elasticsearch are solid choices if you need them. DHH mentioned that as well, at scale, everyone does things differently anyway. But you do have the option to keep it simple, by default.

For me personally, Rails 8 is great. My new project only need Postgres and that's it. I don't need Redis, multiple gems for background jobs or cache anymore. Able to avoid the chaotic JS ecosystem for frontend. Hopefully it will be easy to setup Hotwire Native too. It really streamlined things, and letting me focus on building features instead.

That said, for my production apps in existing companies, I’m sticking with what’s already working: Sidekiq, Redis, Elasticsearch. If it ain’t broke, why fix it? Will probably revisit this decision again in the future. Too early to tell for now.

I've had good experiences using postgres for background jobs.

I've worked on many Rails apps that are still out there in critical spots. My gut feel is it has stabilized. The hype was well-founded; it allows dev velocity that I still haven't seen in any other environment.

I once worked on the integration of an existing Rails app into an existing C# webapp (both living side-by-side, kind of a split-application thing, but seamless to the end user). It was almost hilarious how many LOC the C# teams (!) were having to write for every LOC I (alone) was writing in Rails. Looking through their diffs, it seemed like they were reinventing fire compared to me writing `render :success if SomeModel.update(model_params)`.

Both Ruby and Rails have continued to improve year over year and are better today than they have ever been.

Still a bunch of stuff that runs on ruby that isn't webdev, https://github.com/theforeman/foreman is a big one I can think of. Ruby's quite nice for sysadmin tasks, puppet, chef etc all in ruby iirc.

Rails usage is certainly dropping off a bit. The competition is improving.

I personally got tired of the monkey patching, ActiveRecord's proclivity towards n+1 queries, and complete lack of types / static analysis, among other things. Having to keep a mental model of the types of the entire project, and having to write tests around types takes up a significant amount of my headspace, energy, and time. The older a project gets, the more of a headache these things become. There is an element of "just write better code" to avoid these pitfalls, and that works to an extent, but the older I get the more I realize that the tooling does play a large role in the outcome.

People never fully adopted Ruby for Ruby sake.

People adopted Ruby because of Rails.

Another more adopted Ruby software are probably fluentD and maybe Jekyll. The rest kind of comes and goes.

Majority sys-admin toolings have always been dominated by Python and with k8s hype, some of the toolings have been geared towards k8s automation written in Golang.

In general, sys-admin toolings are a mixed bunch: perl, shell, python, ruby

Rails went through a down period 2014-2020 due to several reasons:

1. React burst on the scene in 2014

2. the hyperscale FANG companies were dominating the architecture meta with microservices, tooling etc, which worked for them at 500+ engineers, but made no sense for smaller companies.

3. there was a growing perception that "Rails doesn't scale" as selection bias kicked in - companies that successfully used rails to grow their companies, then were big enough to justify migrating off to microservices, or whatever.

4. Basecamp got caught up in the DEI battles and got a ton of bad press at the height of it.

5. Ruby was legitimately seen as slow.

The big companies that stuck with Rails (GH, Shopify, Gitlab, etc, etc) did a ton of work to fix Ruby perf, and it shows. Shopify in particular deserves an enormous amount of credit for keeping Ruby and Rails going. Their continued existence proves that Rails does, in fact, scale.

Also the meta - tech-architecture and otherwise - seems to be turning back to DHH's favor, make of that what you will.

Speaking from my own experience at work, for non-webdev, if the project is something I'll want to share with other people, there is a great incentive in just using Python. I can't seem to get people to be interested at all in my tools if they're in Ruby. When I write stuff in Python, people naturally read, use and contribute.

It's stable and mature.

Maybe you don't hear the constant clickity-clack of endless change as a result. Also true that Ruby's most popular in writing web apps and services, where it and Rails continue to shine.

webdev FWIW is a ginormous part of this little internet thing. You know, those Web-based applications and services that run the entire global economy and human society, such as it is.

How would you define "hype"?

Agreed, this should be the main link instead of giving AppSignal free publicity. The original is very much a light reworking of the original. It has the same content order and everything.

yeah, OP feels like a gpt rewrite of this post by DHH

We use it extensively in our codebase. We started without any types, and added Sorbet later. It's similar to Typescript as that you can gradually sparkle your code with types, building up the typing coverage over time.

I just completed a big refactoring. We have a good suite of tests. But Sorbet has provided an added layer of confidence. Especially when it comes to the treatment of null values. Sorbet will raise an error if you try to call a method on an object that may be null. So it forces you to think through: what should happen if the object is null?

So the tests combined with Sorbet typechecking made that we could just almost blindly deploy refactoring after refactoring, with only a handful of bugs for several 1000s of lines of code changed.

We use sorbet pretty extensively. Overall it's been a net positive, but if you're coming from something like typescript, IMO it's far, far behind in terms of usability.

You can get pretty good value from things like intellisense in your editor, knowing that the constant you're referencing or method you're calling exists etc, but most libraries have no typings in sorbet-typed (beyond `T.untyped`).

The last post on Sorbet's blog was from 2022 https://sorbet.org/blog/, so I'm not sure how actively it's being developed. (compare that to typescript where you have a post every month https://devblogs.microsoft.com/typescript/)

Considering how anti-types dhh is, there is not going to be any official support for this anytime soon.

In his most recent interviews the philosophy can be summarised as "if you love types, good for you, but rails isn't for you"

> led to a lot of ephemeral (very hot and then soon unmaintained) patterns/libraries

For hard core web enthusiasts it makes sense to keep toward the cutting edge, but for boring old sites you just want have them run well and not have to worry about swapping out x for y every few months.

I look forward to swapping out sprockets but I know there'll be teething issues. Same for built in authentication, so I won't be swapping out devise any time soon, probably ever. Same with redis for solid (won't be changing any time soon).

Absolutely love the continued work on rails, but it doesn't mean I'll necessarily those new features, which is totally cool - rails doesn't force you to.

With so much mix-and-match it can get confusing though. When I see a tutorial using importmaps I get confused because I only know esbuild. Now there's propshaft. Similarly with asset pipeline, I sometimes struggle with sprockets, now there's something new to learn and all its interactions with other pieces. (mostly paths and debugging is what I have trouble with, i'm no JS wizard [or ruby wizard for that matter]).

(I just want to spend 95+% of my time making things that solve real problems, not tinkering with and finessing pieces of the framework)

Upgrading from 1-4 was difficult but since 4 it has been really easy. Often times nothing much to do from one version to the next.

https://stackoverflow.com/questions/2690544/what-is-the-diff...

I've been a rails dev for over a decade... love the framework and the language. About a year ago we started a client project where they had a fractional CTO that wanted to do the API & UI in typescript and so we settled on Nest.JS... tl;dr Nest is about as good of and opinionated of a framework as I've seen in Node land, but it definitely has it's edges:

- ORM: Like another commenter said, the ORM landscape in the node/typescript world is lacking. Every project feels like it's 70% complete and while you can find a project for each feature you want, you can't find one project with all of them. Ended up with TypeORM which has been very meh. - AuthZ: We went with casl which has a very similar feel to cancancan but lacks many of the important features for implementing more complex authz patterns like "you can edit this if you are in the group that owns this item" - Testing: Using Jest but the DSL and setup/teardown is way more complicated than rspec. - Flexibility. Patterns like single table inheritance and polymorphic relationships are poorly supported/fully lacking in typeorm and this bit us. - Learning curve: the DI system in Nest had a long learning curve, and having to sift through half a dozen or more options for each critical package (ORM, AuthN, AuthZ, etc) instead of having 1 or 2 clear choices made getting the project off the ground much much slower than anticipated. This can also just be chalked up to being green to the Node API landscape. - Adding to the learning curve, you have to be much more thoughtful about your code organization and architecture. We have an issue where we've introduced circular coupling through db-level repositories that is very hard to untangle. Rails gives you a great standard to work from that will take you a long ways

All in all it wasn't a terrible experience but the complexity of the domain lead to some challenges that we could have probably solve more elegantly and quickly in Rails. Even after a year of working the in project, I'd say my velocity for medium/simple tasks is still only 80% of what it is in Rails. Definitely lower when more complicated features are involved

This will answer your question: https://github.com/rails/rails/pull/52335#issuecomment-22395...

> I think there can be some overlap between rake tasks and one-off scripts and opinions may vary. In the related discussion Okura Masafumi mentions that rake tasks are one way but they can be executed multiple times, and I tend to agree, leaving rake tasks for code that is intended to be run multiple times.

> So script/ can hold one-off scripts, for example Basecamp uses script/migrate which I am guessing they use for updating data, and we had a similar folder at my previous company.

> But script/ is not only for one-off scripts, it can hold more general scripts too, for example rails generate benchmark already generates benchmarks in script/benchmarks, and at my previous company we had script/ops which had a bunch of shell scripts and ruby scripts for various ops-related things.

So really not so clear description. It caters to those who feel like they have a script that doesn't really fit in the Rake file.

I really don't understand the NIH that the Rails team is bringing in with Kamal and Thruster. Not everything that HEY uses has to be pushed onto folks at other companies.

It didn't invent this corp-chipper style. It just read all of it.

Very much. I still heavily use rails generators as the defaults do quite a bit already. Generates nice forms, models, migrations, jobs, scripts, and test files. It doesn't feel much, like it's just generating a bunch of files with basic defaults in the right folder, but when you do that quite a bit overtime, you appreciate how little you have to think about those things.

I hear you. I use Cursor editor. I work with all of these technologies: Ruby on Rails, React, Next.js, Django, vanilla JS, jQuery, HTML/CSS, Tailwind...depending on the project.

I just spent the past week working on a hackathon where I built the project using a Node.js closed-source platform that uses Fastify edge functions and Cursor's autocomplete was terrible. Much worse than what I'm used to when Cursor makes autocompletion for Ruby/Rails code. JS libraries come and go every day. This makes it difficult for Cursor team to update their LLMs to provide good autocompletion. On the other hand, Ruby and Ruby on Rails have seen very few radical syntax changes. The syntax and majority of the API has remained the same.

Ruby on Rails is so much more than just fast scaffolding. The code I've written a decade ago in Ruby on Rails, I can still pick it up today and understand the project. I can also pick up anyone else's project and figure out the intricacies of it much faster than I'd ever be able to do in say Next.js or Express project. Express feels like writing assembly (no hard feelings).

I've, unfortunately, recently started working on a project that's written in Django. I thought Django is just Ruby on Rails for Python. Boy was I wrong... But that's a story for another time.

IMO Ruby on Rails is an absolute king! However, I'm looking forward for a day when I'll be able to use one language on both frontend and backend, while having the same simplicity and functionality as Ruby on Rails. (I'm looking forward for Ruby on Rails JavaScript successor, but it's just not there yet.)

I asked Claude some questions about rails and I thought it was helping, but then I switched to working through the Blog example walkthrough on the rails website.

Understanding the "why" and all the default conventions really makes you get what's going on.

I guess my thought is, understanding an app is still important, and rails helps you understand easily.

Correction: you mean 2014, not 2024.

Do you think there is no criteria worth considering besides the size of the hiring pool? What if 2 hiring pools are sufficiently big, do you still pick the bigger one every time?

one could also argue that making tech decisions based on popularity charts is questionable

Rising from #10 to #5 seems to imply that a lot of people are making 'questionable' decisions. As an active senior RoR dev since like 2014ish seeing that makes my heart atwitter :)