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.
So first it's a bit annoying to read this when I busted my ass for several weeks to refactor Active Record to make it more compatible with the Fiber use case in 7.2.
But also there is very little benefit to it for the vast majority of Rails applications out there.
Unless you are doing micro-services or something like that, your typical Rails application isn't IO heavy enough to run more than 2 perhaps 3 threads before contending.
So the overwhelming majority of Rails applications wouldn't see any benefit from being served via falcon, quite the opposite.
Async is great to enable some use cases where people would have to reach to Node before, but Rails will never be a good solution for that, if you want to do some sort of light proxy or websocket notification thing, Rails isn't a good solution, you want something much lighter.
I will be curious to see what JRuby's fiber implementation is like in their upcoming version, currently I work on JRuby rails deployments with dozens of threads across hundreds of nodes. There's definitely some learning curves and tuning necessary when you have 40 threads in contention over a particular shared resource vs 3-5 on regular CRuby.
Yes. But just for the Action Cable parts, as in you'd deploy Action Cable standalone with falcon, and then keep Puma or whatever for the purely transactional requests.
If you don't, you'll notice that your Action Cable latency will be all over the place when a transaction request comes in.
It's acceptable for "hobby" use, but if you try to provide a good user experience with reasonable latency, you can't just collocate Action Cable and the rest of Rails in a single process.
Do you have any tutorial somewhere on how to use Falcon for this? I am getting some strange errors that would probably be covered in a basic tutorial already.
There's various PRs where Fiber adapters are making their way into the Rails stack. Rails 8 added a ton of support for Fibers, with the exception of ActionCable. There's a PR open for that, which I assume will land sometime soon.
Rails has been really slow to pick-up async/http-2. They don't know it yet, but Falcon and all async libraries Samuel is working on will probably be a huge them 1-2 years out when more people find out it means less infra has to be deployed to production environments. Right now folks are happy to deploy without Redis™ with the Solid stack, but a lot of that won't be needed if proper async support is baked into Rails.
There's been a lot of Fiber features being committed into the Ruby language that I barely understand, but have improved all of these async libraries over the past few years. That's finally starting to bear some fruit for people like myself who don't really understand all of those details, but understand the benefits.
It will happen, but these things tend to play out more slowly in Ruby, which is a feature or a bug depending on how you look at it.
This is so condescending... We perfectly know about the pros and cons of the fiber scheduler.
It's a very useful stack, but people, and you in particular, really need to stop selling it like it's the best thing since sliced bread. Async isn't a good fit for everything, and it's certainly not a good fit for the overwhelming majority of Rails applications.
I've heard from lots of folks in the Rails community that getting http/2 and streaming into Rails has been a slow and tedious process. I'm not saying it's going to be "a good fit for everything"—what I am saying is that it will be nice when we can run IO bound workloads in Rails without feeling like a fish out of water.
"it's certainly not a good fit for the overwhelming majority of Rails applications".
In my experience, most web applications are terminating HTTP connections from clients, then reaching out over a network to database servers, etc. to do work. This is very much IO-bound, so I'm not sure how this wouldn't be a good fit for most Rails applications.
> getting http/2 and streaming into Rails has been a slow and tedious process
Bringing http/2 all the way to the Rails process doesn't bring anything to the table. You're much better to terminate http2 or 3 with SSL at the LB.
> terminating HTTP connections from clients, then reaching out over a network to database servers, etc. to do work. This is very much IO-bound
It absolutely isn't unless your data access is really messed up (badly indexed queries or tons of N+1).
Even if you are just serializing the data you got from the DB down into JSON with little to no transformation, you'll likely end up spending more than 50% doing CPU work.
Look at all the reports of YJIT speeding up Rails applications by 15 to 30%. If Rails apps were truly IO bound like people claim, YJIT would have nothing to speedup.
Even if your app is 90% IO, you can slap Puma with 10 thread and will already suffer from contention. Async make sense when you'd need more than a dozen threads or so does. Before that it doesn't make a substantial difference. Like it would be great to use for Action Cable, but that's it.
> In my experience, most web applications are terminating HTTP connections from clients, then reaching out over a network to database servers, etc. to do work. This is very much IO-bound, so I'm not sure how this wouldn't be a good fit for most Rails applications.
Most rails applications are deployed using a multi-threaded application server such as Puma, a thread processes a single request and when it encounters IO (or calls out to a C function) the thread gives up its hold of the GVL and another thread can run. You can use 100% of your resources this way without the added complexity of parallelism within a single request.
Are there truly people out there that are terminating HTTP/2 at the application level? That's really quite surprising for anything serving production traffic.
I think the ActionCable PR is here: https://github.com/rails/rails/pull/50979 -- it seems like it's going well, but taking some time. I think that should be interesting for some use cases, but we'll have to see if/how that makes deployment/operations more complex. For example, if you're better off with the bulk of your app running w/ threads on Puma, would you run the ActionCable stuff w/ fibers on Falcon? Or maybe you just have an app that's doing mostly streaming of AI API responses or something?
Anyway, I'd be careful about over-promoting Falcon/Async, even as one of the relatively few people that's running in a large-ish production app. In my case, I'm doing a LOT of hanging waiting on API responses from weather data sources, and I want to transform the JSON and do some data point conversion in real time. So even in my case, I think it's better for me to switch (see https://github.com/socketry/async-examples for me doing some experiments) because I'm often waiting on API responses (in real time) that can take 1-2 seconds (!) but then I'm still doing some heavy CPU work reading and writing JSON blobs. I saw a pretty good speedup with YJIT, so I think I'm not entirely IO bound, if that makes sense.
I think it's great to have more options for those of us that love Ruby, so we don't need to switch to Node.js or something else for this kind of work. But I think it's likely that existing Rails apps (and typical CRUD Rails apps etc) will probably want to stick with a thread-based model. We'll see how it all shakes out over the next couple years, and I think you're right that it's exciting stuff. Between all the work on YJIT etc, and the possibilities for Node.js-type or Go type use-cases being possible/reasonable with Fibers, it's a great time for Ruby!
My assumption is that’s due to the use case benefits for it.
More concurrency is not always ideal, especially if you’re not in an environment that guarantees you won’t have negative impacts or runaways process (BEAM languages, etc).
Rails projects are typically so hardwired to use a background queue like Sidekiq that it becomes very natural to delegate most use cases to the queue.
Really depends on the job. But generally, yes the same applies to Sidekiq. I think there is a queue for Ruby called Sneakers that uses Fibers?
If you're making API calls out to external systems, you can use all of the concurrency that you want because the outside systems are doing all of the work.
If you're making queries to your database, depending on the efficiency of the query you could stress your database without any real benefit to improve the overall response time.
If you're doing memory intensive work on the same system then it can create a potential issue for the server and garbage collection.
If you're doing CPU intensive work, you risk starving other concurrent processes from using the CPU (infinite loops, etc).
Something like the BEAM is setup for this. Each process has it's own HEAP that's immediately reclaimed when the process ends without a global garbage collector. The BEAM scheduler actively intervenes switch which process is executing after a certain amount of CPU time, meaning that an infinite loop or other intensive process wouldn't negatively impact anything else...only itself. It's one of the reasons it typically doesn't perform as well in a straight line benchmark too.
Even on the BEAM you still have to be cautious of stressing the DB, but really you have to worry about that no matter what type of system you're on.
But wouldn't using a connection pool solve this problem of "stressing out the database"? I assumed a single connection from the pool would be considered "occupied" until we hear back from the database.
Or are you saying that processing lots of requests/tasks in Rails while waiting for the database would quickly eat up all the CPU? It seems like a good thing - "resource utilization" = servers should do things whenever possible rather than just waiting. Although now that I think about it you'd only want maximum resource utilization if your database is on a separate server.
With the database it depends on specific queries. Ideally, you can hammer it and it will be fine.
If you have inefficient queries, N+1 problems, competing locks, full table scans, temp tables being generated, etc then more concurrency will amplify the problem. Thats all I meant.
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.
Tried GoLang and also used Phoenix for a massive project which went well. But we had problems onboarding new folks into it and some junior and even senior engineers went bonkers trying to get their heads around FP and the elixir language in general. I would say it worked great for me, but the problems and the curve of learning for others in my team made it feel like Elixir creates that gap for teams in general.
Go is good, but again I only tried it long ago and can't comment it for what it is today. I loved Ruby but I find it hard to go back to it after my experience with Elixir and Typescript. I was hoping for Crystal to go to great lengths but it doesn't seem to be the case at all.
You do need to set some rule when onboarding people into an Elixir application. Not everything needs to be a GenServer, and please don't endlessly nest Enum.map calls.
I also noticed an elitism from other devs when it comes to Rails devs. I literally heard on multiple occasions "we don't hire Rails devs here!" followed by a laugh.
Of course it was tongue in cheek, if the candidate is amazing yes they're a hire.
But it spoke to a reputation that Rails devs had seemingly received. I think because prior to JS/Node, it was Rails that offered newbies the fastest path into web dev.
I don't believe this is the reason for any sort of exodus, but the negative perception may be partly a reason for devs choosing other frameworks.
Doubtful experienced devs moved to them. Attended many user groups and conferences during those years and both were seen as “lesser than”. Not unusual to see pot shots taken in presentation slides.
Elixir/Phoenix were embraced with excitement due to Jose’s connection to the community and the ruby like syntax.
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 have wondered about that, and I'd guess the thing you (and the sibling comments) pointing out about how GH seems to take an html-fragments approach versus GL opting for the more traditional(?) AJAX one probably does matter a great deal on the end user experience
Regrettably, since GH doesn't develop in the open, it's hard to have an apples-to-apples between the two in order to know if GH has some really, really tuned RoR setup, or it literally is just a matter of "don't be cute" when sprinkling every JS trope known to man upon your web ui and if GL one day cared about their page load times, they, too, could be quick without needing a RoR nor RVM upgrade
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.
In some ways its more about organization of humans doing the work. Breaking some piece of a monolith off into its own application, not micro-service, has advantages that you avoid having to deal more than a 2 pizza team size on an app. Sometimes the business grows and you go from startup idea one-app-does-everything implementations into needing more de-coupled, single business responsibility organizations of code.
I suppose places like Spotify or Github may have good practices around working on large monoliths but I would think that takes a lot of effort to get right and may have trade-offs.
It was always more of a team organization solution than a system architectural solution. Leaning into it too much on the latter created a lot of complications for the former.
Totally, I think there's a lot of retroactive justification for what's familiar whether it be microservice or monolith. They both have advantages and disadvantages -- we're at a point where deploying and running either is available on most clouds.
That said, I think interesting possibilities exist where the two approaches are blended. I work for a cloud [1] that supports a concept of "services" grouped within an app each of those services is a web server that can be configured to sleep [2] under specific conditions -- effectively serverless but without the loss of shared memory and all the efficiencies of running a more traditional web server.
The grouping of services also provides a way to spin off parts of an application while keeping it within the same deployment process.
Depends what you wanted from Microservices. If all you wanted was scale, then Rails ActiveJob solves that very effectively allowing you to scale your job-runners.
If you're looking for the "mindset" of microservices, where you store the data separately and impotently, then I believe Rails discourages that mindset.
I keep hearing this "microservices to allow scale", in which "scale" implies performance, as some counterargument against microservices.
Honest question, who ever seriously proposed microservices to improve performance? It doesn't take a lot of thought to figure out that microservices have overhead that will always put it in a disadvantage over a monolith in this regard.
The only "scale" that makes sense wrt microservices is that of the scale of teams, and manage-ability of the scale of features and codebase. They are primarily a solution to "too many people working in too many poorly bounded domains". But as a solution to performance problems? Is it really proposed as that?
This was seriously proposed by some. E.g. "scaling services independently"
Scaling services independently is usually a recipe for outages where something is at the wrong scale. Sometimes you want to separate workloads that don't fit the request response model well because they take too long or use too much CPU or RAM, but you don't need micro services to get that benefit.
I don't think anyone was claiming it would lower latency for typical requests except maybe indirectly through materializing views in event-driven architecture.
I think the steel man has been about scaling teams, but the discourse was not limited to that.
The idea of reserving some capacity for specific workloads make sense, but that's mostly a load balancer / job scheduler configuration thing. The latent capability to serve other workloads physically hanging out in the same binary is really unlikely to have a material impact, if you're not sending it any work.
It was proposed in the sense that Ruby, or python, or whatever webserver language you used (Perl, php, even JavaScript) was slow, single core, synchronous, database blocked, or whatever else made it “unscalable” and you built this tiny service that only focuses on your core bottlenecks like an api call that only returns coordinates of your map position on things like aws lambda.
Then for some reason some junior engineers thought that you could make everything an api call and you can make services in the most optimal language and glue them all together to have functional “scalable” apps.
And thus the horrors of being a web dev in 2016+ began.
Of course it didn’t help SPAs were encouraging backends to be decoupled from front ends and completely hidden in their implementation so the fact that “it was now possible” enticed backend devs to experiment with multiple api services.
Well, Ruby (on Rails) is slow, single core, synchronous, database blocked and hard to scale. But certainly almost everyone realises that's not a feature of it being a monolith, but comes from it's language/stack/paradigms (AR, template, dynamic, JIT etc)?
I have, certainly, replaced some endpoints in Rails apps with lambda's, rust, or even standalone sinatra services for performance reasons.
For example an endpoint that generated "default stable avatar pngs" for new users: Ruby just isn't cut for image generation and manipulation. Rewriting that in a stack that performed x100 in this use-case (we picked rust) took a lot of heat off the cluster of servers.
Or moving the oauth and registration to a separate rails app that served these pages - the only endpoints that did HTML. Allowing the "main" Rails app to remain leaner by not loading all of the templating, and other HTML middleware in memory when it would never be used.
In that sense, I guess, monolyths can have a performance disadvantage: they require the entire app to load stuff for that one endpoint or feature even if 99% of the requests and users never use that.
Like the "PDF generation for reports" we once had, that was rarely used but still loaded in every running thread that would never handle anything related to reports or PDFs. Extracting that to a separate "PDF report generation worker" freed GBs of memory on almost all servers.
Yes, this is the sensible and necessary side of microservices...
Now, take your auth logic and put it on a 3rd party, rewriting all of your auth to do so.
Now, make your database shared across multiple distribution platforms and 12 services (aws, cloud, heroku, tableau).
When one of your 15 services goes offline for temporary maintenance, for some reason your entire website goes down.
The 17th service you created has an ip address switch and is missing and the response to all urls is the default apache gateway page.
The 24th service upgraded from Node 12 and is now broken, while the 26th service built in Go doesn't compile on the specific linux variant of one of your devs.
Before you know it, you're just doing maintenance work because something is broken and it isn't your code, it's some random downtime or brittleness that is inherent in microservice architecture.
What you describe is common "management of complexity", or, really, lack thereof.
These problems are independent of "microservices" vs "monolith". They are independent of "using a framework" vs "no framework". They are independent of programming-language or hosting infra.
Managing complexity, in itself, is a daunting task. It's hard in a monolith, it's hard in microservices. Building a tangled big ball of spaghetti is rather common in e.g. Rails - it takes a lot of experience, discipline and dedication to avoid it.
Languages (type systems, checkers, primitives), frameworks, hosting infra, design patterns, architectures, all of these are tools to help manage the complexity. But it still starts with a dedication to manage it today, and still be able to do so in a decade.
Microservices don't inherently descend into an unmanageable tangle of tightly coupled, poorly bounded "services". Just as a monolith doesn't inherently descend into an unmanageable tangle of tightly coupled, poorly bounded "modules".
Image manipulation is the one thing I also run as a micro service whenever needed. I just set up imagor once and never need to manage that in the installation/images of all other apps. No extra memory for shelling out to libvips or imagemagick needed.
The PDF use case also sounds very promising low hanging fruit
That was actually excacly our angle of attack: see the routes, modules or jobs that were putting the most pressure on the servers.
Then copy the entire app over to separate servers, connected to the same db cluster. Have an app router direct everything except, say /reports/ to the old servers, and /reports/ itself to the copies on new servers.
Did the old servers reduce significant in load? Rip out the part there. Better? Now rewrite, cleanup, isolate or extract the, e.g. /reports/ part on the servers. Better?
Then, finally, disconnect the service from the shared DB (microservices sharing a DB is the worst idea ever.) and have it communicate either via a message bus, via REST calls or not communicate at all.
Scale in a sense where you can scale that one part of system independently when it is micro service.
You still can run into situation where adding a network call is small overhead over the optimization available where it has its own datababase running on its own VM where you can add more resources just for that specific thing.
Maybe you can rewrite that part in a language that fits use case better for only that service.
Modulith - you still program app usually as single repo project, but you take care about code level modularization so in any case you are able to simply extract separate (micro)service.
Let's use MVC for the sake of argument. A regular monolith has lots of models, lots of controllers, and lots of views. A modular monolith has several collections of models/controllers/views, which might be tightly coupled internally, but the collections as a whole exposes much smaller APIs to each other. You cannot just reach into an implementation detail of distantly related functionality, even if this functionality is "public" in the programming language package visibility sense (i.e. users repository is visible to users controller).
This is basically what's accomplished by publishing a Thrift/Proto/OpenAPI IDL from a collection of packages comprising a network service. The key insight is that the serialization and networking parts of this are superfluous, what you actually wanted was the visibility rules.
A modular monolith has a single executable which runs in different modes, typically depending on environment variables. So you can run three processes in the mode that handles web requests, five processes in the mode that processes events on a queue (e.g. Kafka), etc. Eight processes, running in two different modes, but it's all the same executable. That's the basic idea of a modular monolith.
By "plain monolith" I meant just any kind of monolith.
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.
Isn't that kinda circular? Generally speaking, companies only list their stock when they grow large. The vast majority of web dev is not happening in those kinds of companies.
It is not correct. This is the sentiment people who don't understand k8s often have, because of handwavy complexity blah blah blah. The predictable quote is always along the lines of "unless you're Google scale..." - which misses perhaps 80% of what microservices bring to the table.
Then they go off and build complicated monorepos that take 6 months to learn before you can effectively contribute.
All paradigms have trade offs. Engineering is about understanding those trade offs and using them where appropriate. Unfortunately too many people just jump on the "k8s is complicated" bandwagon (because it challenges most of the assumptions they've previously held in software development) and entirely write-off microservices without taking the time to learn what problems microservices solve.
People are well aware of what problems microservices solve. They are also aware of all the numerous problems they introduce, such as making debugging much more complicated, for starters.
Debugging IS more difficult. Observability is much harder, sometimes needlessly. When you're 4 languages deep and have to enable distributed tracing across a variety of brokers/protocols (http, sqs, grpc, queue in a database) you know the lord intended you to spend your time in a more useful way.
So you're describing a bunch of unnecessary things, and stating they make microservices more difficult to debug?
Nobody says you need http, sqs, grpc, and queue (message broker) all in the same system. Nor does anyone say you need to use 4 languages for these things, nor does anyone say you need to only enable observability when there's issues.
Bunch of handwavy "it's complicated" nonsense basically - demonstrating yet again most people don't really understand microservices.
A microservice can be as simple as studying it's inputs and outputs and nothing more. All of which can be observed via tracing, logging or whatever you prefer, either on a sampled-basis, only on errors, or all the time.
Microservices make you rethink almost all of your software engineering assumptions - and some people are just not in the right headspace to make the jump. The biggest change is viewing/treating your codebases like cattle more than pets. Automate everything, fail quickly, stop caring about crashes, keep services as small and focused as possible, stop worrying about multiple supported releases, etc.
It is very different, but that doesn't mean it needs to be complex.
That doesn't mean microservices are the solution to every problem. It does mean, however, it's a solution to more problems than some people are willing to admit and/or take the time to understand.
I give it to you that, we're it not for microservices, I wouldn't need as much of http, sqs, etc, as well requiring making sense out of all of it via tracing/metrics/logging...
I've worked enough with microservices and heard enough managers preaching the same "cattle not pets", "small focused services", and similar, enough to know that high turnover or several rounds of layoffs, unreasonably high cloud bills and clients frustrated with high latency, often caused by several services, is the inevitable outcome.
Microservices are distributed and distributed systems are inherently more complex than non-distributed ones.[0]
> A microservice can be as simple as studying it's inputs and outputs and nothing more. All of which can be observed via tracing, logging or whatever you prefer, either on a sampled-basis, only on errors, or all the time.
In a statically-typed monolith, function calls are typed, I can jump to the declaration site with a mouse click and if I pass the wrong type, the code won't compile. That's way easier than "you can observe the inputs and outputs" (and hope that your observations generalise sufficiently). And yes, there are solutions for this (contract tests, Avro schemas, etc.), but they are inherently more complicated (maybe the most interesting idea I've seen in this space is Unison[1], but that's not gonna gain a lot of traction anytime soon, I predict).
Of course, microservices have valid use cases, but they come at a significant cost. I don't understand how one can argue that that cost doesn't exist.
It is inevitably more complicated because there are more moving pieces to coordinate. This applies to all IPC, not just in this context. To some extent you can mitigate this with tooling that tries to hide the complexity, but that usually only works for simple cases.
> 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.
Senior engineers are more likely to be the ones who have seen how mindless adoption of fad-of-the-day translates to product quality, and are more likely to choose a solution that they have seen actually work, and for which they know the warts and how to handle them. That's a good thing - experienced engineers should be conservative when it comes to code that runs in prod. Customers are not guinea pigs.
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 agree that Ruby's standard libs are fantastic, but your example is from ActiveSupport, not the standard Ruby libraries. However, Ruby's well-thought-out object model is what makes libraries like ActiveSupport possible.
I've used Ruby long enough to have some gripes about it, but I've worked in a half-dozen languages as well, and I have yet to meet an object model that I like better. That combined with the standard library, and the affordances for functional data pipelining, are what keeps Ruby among my favorites.
It's even the most basic stuff. For example, as of today, there's no way to have an associative array in JS for which keys are composite types, because key equality is not customizable, and all objects use reference equality by default. For some cases you can stringify the key, but in the most general case (e.g. when you need to key on two object references), the only way to do that is to nest maps, which is slow, verbose, and error-prone.
(Tuples are coming to JS and will solve this particular issue, but it's embarrassing to have to deal with such stuff in 2024. Neither Python nor Ruby ever had this problem.)
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.
> 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.
One important aspect of this that I think isn't well-understood in the JS ecosystem is that existence of standard "blessed" solutions means that the rest of the ecosystem can be built around them, especially tooling. With JS and Node, every time there's a new fancy framework, you have to wait for IDEs to catch up to give you any kind of convenience above and beyond just typing code. I was just looking at test frameworks the other day, and the state of IDE integration (with stuff like e.g. Test Explorer in VSCode) is appalling even for well-established ones like Mocha. Ruby guys don't have to rewrite everything every two years, so their tools tend to be much more polished in that regard.
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.
The equivalent to passport in ruby is called omniauth. Having used both, don't really find a huge upside in the former compared to the latter, just different APIs.
I agree, and I'd hazard a guess that part of my slow-down was not knowing Ruby very well when starting. But the lack of intellisense made it difficult to grok, and the Rails libraries always feel more "magical" to me than the Node ecosystem.
IDE support (including code completion) for Ruby has been around for a while. RubyMine most notably, but AFAIK VSCode is pretty decent at it as well these days.
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.
BTW I wouldn't consider those to be "free" features. #NOBUILD allows assets to live much much longer in cache. with minification + whatevah, everytime you change something in a js file you invalidate the whole bundle, which means the client will have to fetch megabytes of javascript, potentially very frequently. So you need to see for your self whether the savings from minification outweigh the savings of caching.
Bundling is also something that we no longer need to do since the introduction of HTTP2. I would even consider it an anti-pattern these days, since it means you're sending the client much more data than they actually need.
Tree shaking is definitely very important for something like tailwind though.
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.
Oh cool, I’ll have to see if there are any near me. Definitely interested in online options too, if anybody has suggestions. And not just for Rails but Ruby in general would be nice too.
>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.
Kamal, Thruster, removing TypeScript from Rails without notice, moving into Webpack and back out again without a reasonable upgrade path, pushing Hotwire over real frontends.
I've been working with RoR since back in 2008 (Rails 2.1 yay!).
I'm still working with RoR.
It's still an incredibly quick, powerful, flexible, versatile framework. I'm able to build pretty large and complex apps all by myself, quite quickly, without fuss.
I'm looking forward to the deployment improvements since that was one of the shortcomings that was still around. Kamal v1 didn't really do it for me (currently using Dokku instead). Maybe Kamal 2 is it.
I was already pretty happy with Kamal 1 but Kamal 2 will probably do it for way more people. The most requested feature was running multiple apps so I wrote a post on how that looks like if anyone is curious[0].
Anybody have any opinions on moving away from Redis for cables/caching/jobs?
I supposed it'd be nice to have one less thing to manage, but I'm wondering if there are any obvious gotchas to moving these features over to sqlite and postgresql.
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.
DHH mentioned 10TB of cache and only 0.5ms increase in latency difference between Redis and SQLite. I wish other could test it out and have some other figures to point to. But if the stated case were true then I think sacrifice 0.5ms for 10 to 20x more cached resources sounds like a very good deal to me.
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.
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.
Regarding Hotwire Native: I tried Strada a few months ago, but I never got it to work. Hotwire Native was running within 10 minutes on each platform. The docs are miles ahead of the Strada docs imo.
Totally makes sense not to jump in early to make sure kinks are worked out, but it is worth noting that Solid Cache was code extracted from BaseCamp and HEY, so it has seen production at scale for a while now.
People just don't talk about Ruby anymore. For those who don't do webdev, has it just stabilised and people take it for granted now, or was it always hype and people have long since moved on?
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)`.
It speaks more about the unfortunate state of practice in the team in question. C# itself is of similar terseness when compared to Ruby, with 10x to 20x better performance so even when written in a bulkier way, it becomes less relevant as you are not going to hold, say, C or C++ against similar criticism in such context. Oh, also no method not found thing too. C# has much greater likelihood of not having defects when you do deploy it.
It's not only that RoR comes with a complete toolset -- it allows you to create your own libraries that extend the capabilities of the framework while keeping the developer experience terse enough through metaprogramming (compare the sample code in the README with the file acts-as-taggable-on/lib/acts-as-taggable-on/taggable.rb, where you can see how the library is opening the classes in runtime through the class_eval technique.
I'm sure something similar can be achieved in C# but not so sure about the elegance of the result.
I read through the description. Funnily enough, it's a second time I ask a question "what does Ruby have?" and the response provides something very specific to Ruby that does not idiomatically translate to other languages in a way that someone in polyglot environment would immediately understand a need for.
Statically typed languages usually have other, better ways, to associate metadata with the types, if necessary. Or avoid having such a requirement at all.
> For instance, in a social network, a user might have tags that are called skills, interests, sports, and more. There is no real way to differentiate between tags and so an implementation of this type is not possible with acts as taggable on steroids.
Isn't that's just having a property/field on a struct/class/type/object that contains the list of tags? Active Records seem to be effectively EF Core's tracked entities but with seemingly more "magic" under the hood (something that ORMs are often criticized for, including catching undeserved strays by EFC).
In general, I remain very negative towards Ruby and Ruby on Rails because most feedback that I hear leaves an impression of "so it has some of the advantages similar to top modern web frameworks in C# and Java/Kotlin but with a huge bag of breakage risk with codebase growth, a need to extensively cover code with tests and static analysis to cover for mistakes that are impossible in statically typed languages, and one tenth of performance on a sunny day".
Now, I don't think it's a bad choice in a vacuum, but it's important to consider the overall experience and practices used in a language A vs B, and whether either is used correctly.
As someone who started his career writing Ruby (but has since migrated to statically typed languages), I agree with your criticism. One big problem I had with the Rails community was the overemphasis on libraries/frameworks that make the code superficially look nice ("just put this dependency in your Gemfile, and it will automagically work") but aren't actually well-designed enough to be composable. The moment you're gonna have to do something out of the happy path, you're often out of luck.
The tagging problem in particular isn't such a hard problem that you' should need to pull in an extra dependency just for that. It's basically just a nested set of hash maps, the "hardest" part about it is the persistence - and I do believe it's worth spending maybe 2 hours on a proper DB schema in exchange for having code you own and understand.
There are other libraries in the Ruby ecosystem that take different approaches (dry.rb for example, which IMHO, strikes a better balance between the expressivity of Ruby and solid design), but they're not all that popular.
> Isn't that's just having a property/field on a struct/class/type/object that contains the list of tags?
I have never used the library, but it seems you get a lot more with just 2-3 lines of configuration (e.g. for a tag context named „interests“):
- The ability to find the n most or least used tags with a single method call
- The ability to track which user tagged a record
- The ability to find records with the same tags
- Calculation of tag statistics for a tag cloud
Now, all that would certainly be possible with EF. But many libraries for Rails give developers a very simple way to configure a feature, and deliver very expressive methods to use the feature. Which is an important property imo, since it often makes obvious what the code does, even for newcomers.
This is probably an effect from Ruby itself, where the standard library is quite expansive and has many often-used patterns built in. For example, calculating an arrays maximum value is just
arr = [1,2,3,4]
arr.max
Meanwhile, in JS:
arr = [1,2,3,4]
let max = arr[0];
for (let i = 1; i < arr.length; i++) {
if (arr[i] > max) max = arr[i];
}
And to address the README of the above library: I think it is a bit confusing because it starts with a comparison with another library, expecting readers to already know how tagging worked there.
> - The ability to find the n most or least used tags with a single method call - The ability to track which user tagged a record - The ability to find records with the same tags - Calculation of tag statistics for a tag cloud
What's the chance that this is the exact set of features that you're gonna need and not a slightly different set of features? E.g. maybe your users are part of teams and you need to know which tags were set by a given team? Or maybe your tags are hierarchical? Will the library be flexible enough to accommodate that?
It just seems that this library makes a lot of assumptions about the business logic of your application - but that can change at any point and then you're possibly stuck with a library that you have to weirdly workaround, or rip out entirely.
I would understand that tradeoff if the library solved an actually complex use case, but every competent developer should know how to implement these use cases from scratch in a relatively short amount of time, and while it undoubtedly takes longer than just adding 2-3 lines of config, what you get in return is code that you own and understand and can modify in whatever way you want.
The following is probably going to be a closer comparison:
let arr = [1, 2, 3, 4];
let max = arr.reduce((a, b) => Math.max(a, b));
Or C# and Rust (which will be >100x faster at finding max value[0][1]):
var arr = new[] { 1, 2, 3, 4 };
var max = arr.Max();
let arr = [1, 2, 3, 5];
let max = arr.iter().max();
Ruby does nail the minimalism in this code golfing example, but it does not offers uniquely high productivity to the end user, which is a frequently brought up point in defense of interpreted languages whenever their shortcomings are mentioned. Lacking static typing, Ruby users have to resort on e.g. Sorbet, which is a worse experience and numerous comments on HN seem to provide negative feedback on it.
I do actually hate to mention performance every time, but it's difficult to not do so when apples-to-apples comparison can be made. Compiled statically typed languages with GC offer similar or better (because the code is verified by compiler, not Sorbet) productivity without any of the drawbacks that come with Ruby.
This is to illustrate the point about the languages that do come with rich standard library, that also happen to go to great lengths at ensuring that shortest way to express something is also the fastest whenever possible.
It is true and you have to lack technical knowledge to downvote this.
In regular "line of business" code this difference might be a bit difficult to see in between the calls waiting for DB and third-party dependencies, so I went with more conservative numbers. On the more complex code this difference will be totally observable.
No question; I can write far more performant C# code than I can Ruby.
For this set of teams, at least, their code wasn’t very performant because it took 3 months to get from Jira ticket to production. They were always getting themselves tied into knots about how to handle rollbacks across their nine microservices required to change a birthday.
Meanwhile, I’m in my corner with my nice little monolith that could read data from their database easier than they could read it.
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.
I'm firmly in the static typing camp myself, but at the same time I think it's good that there's still a language that is unabashedly dynamically typed. Looking at Python, when you take a language that was originally designed around dynamic typing and then bolt static typing on top, the result is just awkward all around, and ends up being the worst of both worlds.
> "just write better code" to avoid these pitfalls
A lot of issues in and with Rails code leans heavily on this idea. It often comes in other flavors like "You can write rails apps that perform really well" or "Its perfectly doable to write a clean easy maintainable codebase in rails".
And is apparent in the "Provide sharp knives" doctrine as "And by capable, I mean knowledgeable enough to know when and how, accordingly to their context, they should use the different and sometimes dangerous tools in the drawers."
I really dislike this approach. I don't want something that is full of foot-guns and therefore requires me to recognise them when I lack all information to do so.
I've written terrible Rails apps, exactly because it allowed me to so, and I didn't know they would become terrible, until they were. I now recognise the (design) patterns that are foot-guns, I now know the tell-tales that show me where the sharp knives are dangerously placed. But then I get dropped into a Rails codebase that has seen 20+ developers coming and going over a decade, as the 21st developer, and I see it filled with these footguns and dangerously wielded "sharp knives". Often there's a lot of history apparent from these previous devs who saw this too and fixed some of it. But the overall state is still abysmal.
Sure, it's all these devs that made it abysmal. But the ecosystem, the framework and the language allowed, and sometimes even encouraged them to make it that.
The N+1 queries issue has been addressed in the latest ActiveRecord versions. If there's an N+1, you can set ActiveRecord to raise an error instead of making the N+1 query. Bullet gem, for years now, has also been able to catch the N+1 queries and let you choose how you want to act upon that.
It's true that monkey patching is a problem. I hear you. It's more and more problem of the past though. People realized it's too sharp of a knife and stopped doing that.
Rails has strict_loading now which eliminates the n+1 issue. Which kinda supports your position that tooling plays a large role. I was always very aware of the issue but framework support makes it 10x easier
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.
I've built a lot of niche applications in Ruby, but a few years ago I switched most of my toy programs to python, because it's easier to find other devs who can meaningfully contribute if I write in python.
At work I have been using Ruby for longer than rails has existed. In those days there were lots of neat uses for Ruby (one of the most interesting being at NASA), but none of us knew if it would ever catch on. We didn't care -- Ruby made programming _fun_, and we were happy to use it even if no one else ever did.
It was partly the language that made Ruby fun but also the community. And it's out of this community that projects like chef, puppet, shoes, etc. were born. Matz has called Ruby human- oriented programming, and I can think of like that is human- oriented than community.
Completely agree and yes, Python (and Typescript) get called on more in my current role too, for the same reasons. It's a shame as I really do love Ruby.
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.
The RoR hype started to wane long before React. You're really missing a huge part of our industry:
- While most 2nd or 3rd tier tech companies don't need Google scale infrastructure, SOA in Java/C# and then Go is incredibly prevalent. Many teams never had a reason to even look at RoR and its considerably worse language and runtime.
- Good ideas from RoR were copied by pretty much every ecosystem; again, most people never wanted Ruby in the first place.
you might mean shopify, not spotify. I think spotify is python/go, whereas shopify was started by a rails core contributor and probably has the biggest rails deployment in the world
>which worked for them at 500+ engineers, but made no sense for smaller companies
The number of hi-tech companies that grew from 37signals size to Uber size have also increased due to various reasons: SaaS becoming more and more accepted, WallStreet loves SaaS, and in general just more investment money in the market.
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.
I'd argue that newer frameworks offer lot more (and are lot more complicated) than people imagine them to be.
The other day, I was exploring Next.js and the number of features, possibilities were astonishing to me as someone that's pretty anti React. I do Svelte[kit] but it isn't there at all where NextJS is especially when paired with Drizzle and auth.js topped with Shadcn/Material UI/Ant Design, a skilled craftsman can crank out apps as fast as it would be for a Rails developer if not any faster.
Unfortunately, the cognitive load that comes in JS ecosystem is mainly at three levels:
- Understanding the packaging (npm, node_modues, CJS/MJS)
- Understanding the bundlers (webpack/vite/Rollup)
- Understanding the transpilers (Typescript, Babel, Less and Tailwind lately)
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.
It's a demographics kind of thing. People simply got older. I'm too old for it, actually. Java was being hyped before Ruby caught on (which is around the time Rails became a thing). So that's what I was focusing on at the time.
Both languages emerged in the early to mid nineties (together with Python and a few other things). But Rails was much later than that. Now the demographic of the typical Ruby/Rails developer that got into Ruby about 20 years ago straight out of college is a forty something. Still relevant but a clear minority relative to the mass of developers that came after that grew up on things like Go, Rust, Node.js, etc. And of course Python made a comeback because of AI. So, you now see a lot of relatively young people doing a lot of stuff in Python that wouldn't typically be exposed to any Ruby.
I always looked at python and ruby as similarly capable scripting languages. With python a bit more oriented towards people who were simply looking to get shit done perhaps and ruby more geared towards computer science types obsessing about things like meta programming. A lot of that crowd moved on to other languages.
Ruby so far hasn't had a comeback movement like Python. Lots of people still use it of course but it's not an obvious choice to people that haven't used it before. All the AI stuff sort of flew by it. People do a lot of stuff client side these days which makes view oriented frameworks like Rails less relevant. Though with the server side rendering come back there is still some relevance of course. But that's more of a performance optimization that came out of the node.js community. And of course Rails inspired a lot of other frameworks for different languages so its unique selling point kind of went away.
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.
Authentication has been a scary topic, I've been taught to never try to roll my own auth system and use a third party because they've done all the mistakes, which I believe is true to this day. I've stuck with Device because it does all the work, I don't know what I would do without Device, but it has also struck me "what if Device gets abandoned or stops existing, what do I do then?".
But now, with the built-in authentication in Rails, they've made it almost like lego which removes the fear for me, this is such a neat and exciting feature.
I'm curious what the state of Sorbet + Rails is these days. I've been out of the ruby game for a little while now.
Last I recall: sorbet itself is quite good once it is well established in a project, but adding type checking to a project (especially a Rails project) is a lot of work.
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`).
AFAIU sorbet is still being developed actively enough at Stripe, but I think there's also ongoing work at Shopify to integrate the Prism parser APIs which will be available in Ruby 3.4 this December
Personally, the argument for strong types is when you’re writing critical foreseeably permanent architecture. It’s an extra layer of security and explanation.
Some really great ideas came out of Rails 1 and 2. After that Rails became more of a business, but good ideas still came out of the ecosystem and germinated (in my view more successfully) in the fertile soil of node / js, as well as sinatra -> flask / express, etc.
But Rails' core value prop (doing a lot with strongly opinionated structure) is still useful to a lot of people.
My complaint was always that version upgrades in rails were too costly -- teams would spend months -- and it wasn't usually clear whether upgrading was worthwhile. Also the business aspect led to a lot of ephemeral (very hot and then soon unmaintained) patterns/libraries.
Rails 8 makes me want to look again and see how the system overall has matured.
> 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)
I have already upgraded to Rails 8 and am currently writing a guide on how to use Propshaft (because I was unable to find important infos). It‘s far from ready, but I plan to include a wizard that allows you to select your needs and it spits out the combination of jsbuild/cssbuild/importmaps/dartsass that you need.
In short: if your application only needs distribution-ready JS and CSS (from libraries like Bootstrap, Splide or Lightbox2) you only need importmaps-rails.
If you use SASS, you need dartsass-rails. And if you need to compile TS (with esbuild or webpack) you need jsbundling-rails.
Especially the first case got a lot easier with Propshaft.
Not to sound harsh or anything, this is a genuine question: what is Ruby used for nowadays? I am not talking about projects that are using Ruby since a long time but...what is Ruby used for as a go-to tool nowadays?
I find that I have a love/hate relationship with Rails. Love the framework, not so much the language, particularly how it doesn't have static typing. Really easy to write, but hard to refactor in my opinion.
I've been looking for a framework as good as rails for typescript, but haven't found anything to that level. The closest I've seen so far have been:
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
I tried to get started with Rails a few times, it never took. Node was much simpler to wrap my head around. I'm looking for simplicity and Rails is not it.
If you just need to host a static page, then sure something like Express is a much better fit. But most web applications have at least some if not all of the following:
- Auth, sessions, secure cookie handling, etc.
- DB interaction
- View templates, layouts, etc.
- SPA-like interactivity
- Form handling & validation
- File uploads
- Asset handling
- Emails
- Background jobs
- Security (CSRF, XSS, SQL injection, etc.)
- Logging
- Internationalization
- Testing
- Real-time functionality
With Node/Express, you're either searching for other people's libraries to use and integrate, which aren't guaranteed to synergize, or writing it yourself. You have all of that baked into Rails, tucked away neatly so you only have to write and focus on what matters. You also have an opinionated architecture so you know exactly where all the custom business logic should go.
I think if you have extremely simple requirements, or you're at a stage where you want to learn all these things by doing it yourself, it would make sense not to use Rails. But if you want to focus on delivering value ASAP, Rails (or similar frameworks like Django) are for sure the way to go.
I know exactly what you experienced, jumping straight into Rails without knowing how to tame the beast is not worth it. What helped me get started and understand the concept was to follow their guide. Not kidding, it's that good.
> 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.
Nothing is pushed. You can upgrade your Rails 7 application to Rails 8 today and no Solid* nor Kamal nor Thruster will be used in your app. It's there for you to use it. If you don't want to use it, don't. They released these new tools and, if you want to use something else, you can. That's the whole idea of Rails.
I really want to try Rails, but the main selling points to me were the fast scaffolding and opinionated structure. With the advent of AI editors, are these points still relevant? Last I tried, CursorAI struggled with Ruby due to the lack of types. It seems like nowadays you can be nearly as productive with Node + Typescript + Cursor.
edit: care to explain the downvotes for asking a question?
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.)
Nice, so Rails does work well with Cursor? I'll give it a try then. Like you said, maybe it just struggles on random Ruby code but not Rails which has a ton of existing examples to go off of.
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 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.
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?
> Do you think there is no criteria worth considering besides the size of the hiring pool? What if 2 hiring pool are sufficiently big, do you still pick the bigger one every time?
It is not just a hiring pool.
Look at various third-party SASS tools, they see Ruby as a second-grade language to support.
That's not at all my experience. There's a one-line integration between almost everything under the sun and Rails (business/traffic analytics, performance/profilers, error notifications, logging, object storage integration, I could probably go on). Many other frameworks don't even have the general capability of doing one-line integrations.
You're right. Those shouldn't be completely ignored. They probably shouldn't be the only argument to make tech decisions upon.
Did you ever build any webapp in Ruby on Rails? You should check it out!
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 :)
Rails 8 can make you a one-person framework and a successful SaaS solo-owner. Don't really care about the declining market share imo, I love and embrace it despite its shortcomings.
- 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.