earcar

That sucks, my fellow Italian. I haven't looked into our country since I live abroad for a long time, but I'm also paying health insurance here which is not cheap at all, and haven't added it to the post since it's not necessarily a company spend.

Cordiali saluti!

That is refreshing to hear. Unfortunately I can't get out because of exit tax, an unrealized capital gains tax for the privilege of leaving the country. That is way worse than what I mention in this post and will get its own post soon.

Yes indeed.

We converted Freshflow into a GmbH and needless to say it was expensive.

The Stammkapital was required for the UG, and it's very much locked since the whole purpose of that is to take liability.

I had already people wanting to work with me before even starting the company. Couldn't send them invoices. Most importantly: didn't speed up the process!

You get one chance at getting your company form right. Any other new chance costs a ton of money in restructuring. Software is malleable, companies are less so.

That way, AFAIK, the German government will determine that the "place of effective management" is Germany, and tax you also there.

Double taxation is not better.

"one" != "only one"

Not in mine. Check the post.

It is not complicated, it is in fact quite standard here in Germany.

I explain in the post how the other options are worse.

The Ruby community's focus on elegance and programmer happiness is commendable and what keeps me in it.

Love seeing projects like this.

I think the multiplier framing is right. The thing it multiplies most is not typing speed, though, it is judgment.

If you know what good looks like, the tools are incredible. If you don't, they help you produce plausible wrong things faster.

That's true if your org treats artifacts as progress.

When artifacts are cheap, differentiation comes from quality.

I think that is probably right for the same amount of software.

But "same amount of software" is the part I do not buy. When something gets much cheaper, people usually want more of it. A lot of software does not exist today because it is too expensive to build or maintain. If that cost drops, the surface area of what is worth automating expands.

I think engineering work will move toward owning more, reviewing more, making better product decisions, and being accountable for a larger surface area.

If there's anything that our community doesn't need is exactly these posts. We have excellent gems, the only thing we lack is good marketing, and better documentation of certain pieces. Posts like this perpetrate the same culture that we want gone.

To the points the post makes: as the author of RubyLLM, I've built several chat interfaces streaming from LLMs with Hotwire. They handle token by token streaming, full message restreaming at the end, role parsing, etc. They work great and the code is concise and beautiful.

Certain apps' hot paths are on the client, so it makes sense that Figma pays a lot of attention to that. However, did you know that Figma use Rails under the hood?

Ruby deserves a different story than what's shown here.

I've been there too. That's also why I choose to build a TUI, worst case you can always ssh!

Thank you. Let me know how you get along with it!

Why not bump it to 10,000 threads? The post shows: the OS scheduler struggles badly, 18x slower allocation, 17x slower context switching. That’s measured overhead, not theory.

Complexity? We migrated in 30 minutes. It’s just Async blocks, not goroutine scheduling gymnastics.

Not claiming it’s a silver bullet - the post explicitly says “use threads for CPU work”. But for I/O-bound LLM streaming, the massive improvement is real and in production.

Fair point on the syntax, I should have been clearer. What I meant is that your existing Ruby code doesn't need modifications. In Python you'd need to use a different HTTP library, add `async def` and `await` everywhere, etc. In Ruby the same `Net::HTTP` call works in both sync and async context.

The `Async do` wrapper just at the orchestration level, not throughout your codebase. That's a huge difference in practice.

Regarding pgbouncer - yes, it helps with connection pooling, but you still have the fundamental issue of 25 workers = 25 max concurrent LLM streams. Your 26th user waits. With fibers, you can handle thousands on the same hardware because they yield during the 30-60s of waiting for tokens.

Sure, for pure performance you'd pick another language. But that's not the point - the point is that you can get much better performance for IO-bound workloads in Ruby today, without switching languages or rewriting everything.

It's about making Ruby better at what it's already being used for, not competing with system languages.

Author here. Thank you, that means a lot!

Happy to answer any questions.

Author here. The problem: every thread-based job queue (Sidekiq, GoodJob, etc.) has a max_threads limit. Set it to 25? That's your hard ceiling for concurrent LLM conversations. The 26th user waits, even though your server is 99% idle.

Switched to async-job in 30 minutes. No code changes needed. No max_threads = our AI app went from barely handling 25 users to thousands on the same hardware.

The beautiful part: existing libraries like RubyLLM automatically get async performance because Net::HTTP yields to fibers. No special async versions needed. No async/await keywords polluting your codebase.

After a decade in Python's asyncio world, this feels like how async should have been done. You get massive concurrency without the complexity tax.

Happy to discuss the technical details or migration experience. The future of Ruby AI apps is here, and it's surprisingly simple.

There will be no diff support, but it will be updated daily.

Daily!

Fascinating timing for this feature. I suspect the AI chatbot explosion has been a major driver behind the push for richer select elements.

Have you noticed how every AI interface needs to let you choose between models? The current select element is embarrassingly inadequate when you need to show more than just text labels. You want to display model capabilities, performance indicators, context sizes - not just "GPT-4" vs "Claude 3.7" as plain text.

Who's actually making the claim we should replace everything with natural language? Almost nobody serious. This article sets up a bit of a strawman while making excellent points.

What we're really seeing is specific applications where conversation makes sense, not a wholesale revolution. Natural language shines for complex, ambiguous tasks but is hilariously inefficient for things like opening doors or adjusting volume.

The real insight here is about choosing the right interface for the job. We don't need philosophical debates about "the future of computing" - we need pragmatic combinations of interfaces that work together seamlessly.

The butter-passing example is spot on, though. The telepathic anticipation between long-married couples is exactly what good software should aspire to. Not more conversation, but less need for it.

Where Julian absolutely nails it is the vision of AI as an augmentation layer rather than replacement. That's the realistic future - not some chat-only dystopia where we're verbally commanding our way through tasks that a simple button press would handle more efficiently.

The tech industry does have these pendulum swings where we overthink basic interaction models. Maybe we could spend less time theorizing about natural language as "the future" and more time just building tools that solve real problems with whatever interface makes the most sense.

Thank you! This is what the Ruby community has always prioritized - developer experience. Making complex things simple and joyful to use isn't just aesthetic preference, it's practical engineering. When your interface matches how developers think about the problem domain, you get fewer bugs and more productivity.

Thank you for your kind words!

Valid point. I'm actually already working on testing better streaming using async-http-faraday, which configures the default adapter to use async_http with falcon and async-job instead of thread-based approaches like puma and SolidQueue. This should significantly improve resource efficiency for AI workloads in Ruby - something I'm not aware is implemented by other major Ruby LLM libraries. The current approach with blocks is idiomatic Ruby, but the upcoming async support will make the library even better for production use cases. Stay tuned!

Thanks for flagging this. The eval was only in the docs and meant only as an example, but we definitely don't want to promote dangerous patterns in the docs. I updated them.

Thank you!

Thank you!