falcon VS FrameworkBenchmarks

Could you command on any projects within Shopify that are helping Ruby's concurrency story? I'm aware of Ractors (https://docs.ruby-lang.org/en/master/ractor_md.html) and Fibers, but it's unclear to how feasible these primitives currently are to build the necessary abstractions on top of them that would make Rails more concurrent.

https://github.com/socketry/falcon is an interesting project, but again, it's not clear how difficult it would be deploying a Rails app on top of this.

There's a lot of really great projects happening and plenty to be hopeful about, but when that stuff will land or the changes the rest of the community and ecosystem should think about making still isn't clear.

HOWEVER HAD, not all of these problems (in Java) are due to some corporation going bulldozer-mode. Several problems seem to come primarily from bad technical decisions. The import-situation annoys me in Java. I think it is really bad that I can not easily require add-ons or files, without being forced into a specific, nonsensical directory structure. In ruby I just do require, or load (I could do require_relative but this is a pretty pointless addition; It even leads to bugs such as the author of https://github.com/socketry/falcon assuming that everyone uses a hardcoded filesystem, so code such as https://github.com/socketry/falcon/blob/main/bin/falcon at: require_relative '../lib/falcon/command' not working unless the assumption that the directory BELOW the bin/ one must contain a lib/ which is not always the case. I am not sure he understood the problem domain though. If he would have simply used require instead, that would not be an issue, but no, he thinks one has to use hardcoded path assumptions into require_relative, which means it'll break when you relocatethe bin/ executable file there. It's trivial to fix of course, just replace the require_relative with require, but I think he did not understand the explanation so ...)

This doesn't have much to do with Rails, more with the web server that serves the Rails app. Take a look at Falcon.

You can use the Async gem and the Falcon web server to take advantage of this capability. And starting in Ruby 3.0, async I/O is even more automatic because inside the Ruby runtime, all socket operations will automatically yield the current fiber by default. It’s fully transparent to the developer. Your I/O calls appear to be blocking so they are easy to understand, consistent with Ruby’s “programmer happiness” philosophy.

There seem to a lot of ruby pieces falling into place for Rails 7.

The Achilles Heel of Hotwire apps has previously been the low number of supported websocket connections and high memory usage when using ActionCable and Puma but I have high hopes that Falcon[1] will take care of that.

That along with Github's View Components[2] and Tailwind make me really please with the way Rails is heading right now.

1. https://github.com/socketry/falcon

2. https://github.com/github/view_component

This is all new to me as well, but the project mentioned the Falcon web server(https://github.com/socketry/falcon).

The documentation for Falcon mentions using it with rails: https://socketry.github.io/falcon/guides/rails-integration/i...

I imagine something more "native" to rails will happen eventually though. But would need to be after this makes its way into core ruby(which has not happened yet apparently).

Welcome back.

It's still the best choice in the Ruby world, well maintained, responsive and new features added. Shopify and github use it, you might want to look at the Rails 6 annoucements what these companies added for scalability features. There've been changes to the asset pipeline since version 3 but you'll still recognize it. You can run Rails as API-only and there's subprojects/tutorials for combining a frontend-heavy React,Vue with a Rails backend. You can still ignore the webpack based asset setup unless you use React,Vue I think. Ruby-3 works fine though I'm still waiting for some less-maintained gems to finally merge PRs, maybe you want to use Ruby-2.7 first.

I use https://puma.io/ , that scales well enough for me. https://github.com/socketry/falcon#readme is faster with build-in HTTP/2 support but harder to setup in my opinion, e.g. requires SSL certificate even on localhost.

Neat. Thanks for sharing!

Interestingly, may-minihttp is faring very well in the TechEmpower benchmark [1], for whatever those benchmarks are worth. The code is also surprisingly straightforward [2].

[1] https://www.techempower.com/benchmarks/

[2] https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

ntex was formed after a schism in actix-web and Rust safety/unsafety, with ntex allowing more unsafe code for better performance.

ntex is at the top of the TechEmpower benchmarks, although those benchmarks are not apples-to-apples since each uses its own tricks: https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...

Ruby is slow. Very slow. How much you may ask? https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s... fastest Ruby entry is at 272th place. Sure, top entries tend to have questionable benchmark-golfing implementations, but it gives you a good primer on the overhead imposed by Ruby.

It is also not early 00s anymore, when you pick an interpreted language, you are not getting "better productivity and tooling". In fact, most interpreted languages lag behind other major languages significantly in the form of JS/TS, Python and Ruby suffering from different woes when it comes to package management and publishing. I would say only TS/JS manages to stand apart with being tolerable, and Python sometimes too by a virtue of its popularity and the amount of information out there whenever you need to troubleshoot.

If you liked Go but felt it being a too verbose to your liking, give .NET a try. I am advocating for it here on HN mostly for fun but it is, in fact, highly underappreciated, considered unsexy and boring while it's anything but after a complete change of trajectory in the last 3-5 years. It is actually the* stack people secretly want but simply don't know about because it is bundled together with Java in the public perception.

*productive CLI tooling, high performance, works well in a really wide range of workloads from low to high level, by far the best ORM across all languages and back-end framework that is easier to work with than Node.JS while consuming 0.1x resources

Although that seems to have improved in recent years.

https://www.techempower.com/benchmarks/#hw=ph&test=json§...

RoR and whatever C++ based web backend there is count as a valid comparison in my book. But comparing the languages itself is maybe a bit off.

On a side note, you can actually compare their performance here if you’re really curious. But take it with a grain of salt since these are synthetic benchmarks.

https://www.techempower.com/benchmarks

Most benchmarks you'll find essentially have someone's thumb on the scale (intentionally or unintentionally). Most people won't know the different languages well enough to create comparable implementations and if you let different people create the implementations, cheating happens. The TechEmpower benchmarks aren't bad, but many implementations put their thumb on the scale (https://www.techempower.com/benchmarks). For example, a lot of the Go implementations avoid the GC by pre-allocating/reusing structs or allocate arrays knowing how big they need to be in advance (despite that being against the rules). At some point, it becomes "how many features have you turned off." Some Go http routers (like fasthttp and those built off it like Atreugo and Fiber) aren't actually correct and a lot of people in the Go community discourage their use, but they certainly top the benchmarks. Gin and Echo are usually the ones that are well-respected in the Go community.

There is certainly a lot of speculation in Techempower benchmarks and top entries can utilize questionable techniques like simply writing a byte array literal to output stream instead of constructing a response, or (in the past) DB query coalescing to work around inherent limitations of the DB in case of Fortunes or DB quries.

And yet, the fastest Ruby entry is at 274th place while Rails is at 427th.

https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...

oh what machine? with how many workers? doing what?

search for "node" on this page: https://www.techempower.com/benchmarks/#section=data-r21

JustJS would like a word https://www.techempower.com/benchmarks/#section=data-r20&tes...

In terms of RPS, this web service is more-or-less the fortunes benchmark in the techempower benchmarks, once the data hits the cache: https://www.techempower.com/benchmarks/#section=data-r21

Or, at least, they would be after applying optimizations to them.

In short, both of these would serve more rps than you will likely ever need on even the lowest end virtual machines. The underlying API provider will probably cut you off from querying them before you run out of RPS.