What does HackerNews think of falcon?

> I happen to be using Falcon

heh I'm always annoyed by this unfortunate name clash:

https://github.com/socketry/falcon

Rack 3 has better support for web servers like Falcon[0] that are designed to take advantage of async or blocking vs non-blocking IO throughout the stack.

Maybe the same for Puma?

[0]: https://github.com/socketry/falcon

Could you comment 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. My experience with these concurrency models in Rails apps is that one single gem could make a blocking IO call (for example) and negate all of the concurrency/performance gains. It would be cool if Ruby could be configured to throw errors for these types of calls to make finding and fixing offending gems easier.

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.

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

As you can imagine, deploying a new technology to production can have issues :p

I've been dogfooding falcon (https://github.com/socketry/falcon) for the past week, which is built on top of async/Ruby. The HN hug of death + Reddit hug of death is a really great traffic test.

I think actually it's been pretty solid, but something caused the instance to run out of swap space, even though it had plenty of free memory. It's something I'll have to try and reproduce so I can understand how it's happening.

Or the Ruby webserver

https://github.com/socketry/falcon

So, I implemented https://github.com/socketry/falcon - a HTTP/1, HTTP/2 web server, including client.

HTTP/2 in my opinion is simply a better protocol. It's more robust, and it has a binary framing layer which implements connection semantics separately from request/response headers. What I mean by this, is `content-length` or `transfer-encoding` are no longer used to control how the protocol actually works (i.e. how many bytes of data are consumed). I think this is a great step forward because it removes ambiguity and simplifies the overall protocol, and it's clear how extra features can be added in the future without impacting existing clients/servers - something that HTTP/1 struggled with a bit.

I also think it impacts how we build web applications. I already wrote this as a blog post: https://www.codeotaku.com/journal/2018-10/http-2-for-ruby-we...