I’ve Given Up on Bun.

Hulk in Public — Mon, 18 May 2026 03:10:29 +0000

Bun’s implementation language has been migrated from Zig to Rust.

I have no intention of criticizing either Zig or Rust. I think both are excellent languages.
What I want to criticize is Bun’s development process.

Rewrite Bun in Rust #30412

Jarred-Sumner posted on May 08, 2026

Blog post with details coming soon.

It passes Bun's pre-existing test suite on all platforms (and fixes several memory leaks and flaky tests), the binary size shrinks by 3 MB - 8 MB, the benchmarks are between neutral and faster - and most importantly, we now have compiler-assisted tools for catching & preventing memory bugs, which have costed the team an enormous amount of development & debugging time over the years.

The codebase is otherwise largely the same. The same architecture, the same data structures. Bun still uses few 3rd party libraries. No async rust.

To try this, run:

bun upgrade --canary

Please do file issues if you run into any. If this thread gets crazy I will lock it.

Note:

Still some optimization work to do before this lands in non-canary version.
Still some cleanup work to do (which will come in a series of follow-up PRs)

View on GitHub

I have never seen a diff this large before.
What is even more surprising is that, using Claude Code, they reportedly went from implementation to review and merge in less than a week.

Anthropic, which owns Bun’s developer Oven, will likely use this “success story” to further market Claude models and tools.

Even if the migration to Rust has solved the memory leak issues, and even if AI implemented excellent code at incredible speed, I am dismayed by a development process that can release code almost instantly without much review.

To be clear, I am not claiming that AI-generated code is evil. AI can produce useful code, and I also rely on vibe coding in areas where the security risk is low.

But I still review the generated code again and again before I trust it.

My criticism is directed at the act of releasing code without taking full responsibility for it — that is, shipping a massive change without carefully reading and understanding every part of the diff.

Given the sheer size of this change, I do not believe it was physically possible for the Bun development team to thoroughly review all of it in less than a week. That, not the use of AI itself, is what I find unacceptable.

Some people say, “This is the first step in a gradual experiment. It will get better from here, and the Rust code will become more refined as unsafe code is eliminated.”
Don’t be ridiculous. My products—SuperRails and LazyCafe —use Bun. Are my products Anthropic’s sandbox?

In the near future, I plan to migrate SuperRails from Bun to a pnpm-based esbuild setup. I will consxider similar changes for other products, including LazyCafe.

Anthropic and the Bun development team are so focused on short-term problems—how to go public as quickly as possible, and how to resolve memory leak issues as quickly as possible—that they lack the perspective of keeping these tools and products in society for the long term.

This way of doing things does not align with my development philosophy: quietly running businesses that can survive for decades.

Super Rails | Rails Boilerplate for Solopreneurs

A production-ready Rails boilerplate with Devise, Avo, Stripe, ViewComponent and more. Skip the setup, ship your MVP in days.

super-rails.com

Why I Still Choose Ruby on Rails in the Age of AI

Hulk in Public — Sun, 17 May 2026 12:11:07 +0000

Hello, I’m Haruku, a freelance developer.
After recently starting my own company, I’ve found myself thinking more about what kind of web framework fits the age of AI.

I entered the world of computer science through Ruby, and since then I’ve launched side projects using popular technologies such as TypeScript (Next.js, Nuxt.js), Go, and Rust.
But in the end, I realized that Ruby and Ruby on Rails fit my use case best.

And that judgment has not changed even in 2026, when AI coding has become far more advanced.

In this article, I’d like to explain why I decided to keep using Ruby in the age of AI.

For context, I plan to use Rails for every business I start through my company going forward. Please read this as one perspective from someone who is, in a sense, a “Rails believer.”

Why I Use Rails

A Strongly Opinionated Community

Many of you have probably heard the term CoC. Yes, “Convention over Configuration.”
When starting a new Rails project, the framework forces many decisions that developers would otherwise have to make from scratch. Developers simply follow those conventions.
Developers who use Rails always code with this concept of CoC in mind.

For example, if you want to create a new model tied to a database, you only need to type:

rails new model Post title:string body:text

in your terminal, and Rails will automatically create the table, the model layer, and the related tests.

When I first learned programming and touched Rails, I wasn’t particularly impressed by this.
But when I later tried Next.js and Nuxt.js, I was shocked to realize that this was not the norm.

In many other frameworks, even the ORM for connecting to the database and the testing library are things you have to introduce yourself.

I genuinely wondered why so few other languages had truly “batteries-included” frameworks.

Even worse is that there is often no correct answer for “architecture,” including file structure.

Where would you place the file that defines a User model?

In Rails, of course, it goes in /app/models/user.rb.
But in TypeScript, Go, or Rust? Where do you put it? Do you just create your favorite location???

When hundreds of these decisions pile up, developers feel stressed even just reading the code.

Eventually, they set off on a journey to discover “what good architecture is,” spending time and mental energy on things like Clean Architecture or Onion Architecture that produce no profit at all. (Yes, that was me in the past. lol)

Rails’ strong philosophy is sometimes criticized as “inflexible” or “not suitable for certain cases.”

But unless you are planning a very large-scale project from the beginning, it probably won’t be a problem.

DHH, the creator of Rails, has pointed out that most modern web development is CRUD—that is, applications of simple database reads and writes—and has openly stated that Rails is fully capable within that scope.

This is highly compatible with AI coding.

For example, suppose an AI goes off the rails and writes logic inside the User model that sends an HTTP request. (They do this often.)

In terms of whether it runs or not, it probably will.

But sending HTTP requests is clearly not the responsibility of the model layer. The role of the model layer is to handle database reads/writes and relationships.

The more rotten code increases, the harder it becomes for both humans and AI to maintain the code or add new features.
And AI takes zero responsibility for the code it generates.

That is why, in the age of AI, a strongly opinionated Ruby on Rails becomes a strength.

Specialized for Small-Scale Development

You may have heard people say, “Large companies like GitHub and Shopify use Rails! That’s why you should use Rails!”

That is true, but I’d rather argue that Rails’ real strength shines in smaller, elite teams—say, one to five people.

DHH wrote a book called Rework.

Rework on Amazon

It argues that you can make enough profit with a small team without raising huge amounts of VC funding or hiring employees at scale.
This book influenced my life more than any other.

And I believe this approach of pursuing profit with a small team fits perfectly in the AI age.

Since LLMs became widespread, people have started saying that “a one-person unicorn company will emerge within a few years.”

Going forward, I believe engineering teams will continue to shrink, and the default competition will be about how quickly and how many products you can build and launch until you find PMF.

In other words, we are entering an era where small teams launch many products.

Rails is a framework DHH created for himself.

It is specialized for quickly launching from a business perspective, adding features, getting market feedback, and rapidly repeating that cycle.

The rails g scaffold command is the clearest example of this.

About three weeks have passed since I started my company, and by using only two free days per week—roughly ten days total—I was able to build a product and now have a realistic path to release it next week.

This is possible precisely because of Rails’ strong philosophy based on CoC and the community that supports it.

I don’t think it would have gone that way with something like Next.js. (I can imagine days spent fighting server components and caching.)

As a framework for a small elite team using AI to run the PDCA cycle, I don’t think there is anything more suitable.

bramjetten.dev

And as shown by the large companies mentioned earlier, Rails can also scale properly when used appropriately.

More Than 20 Years of History

Ruby on Rails was released in July 2004. It already has more than 20 years of history!

As you know, for generative AI to produce more accurate results, the quality and quantity of the training data are prerequisites.

As an engineer, I fully understand the desire to build products with “modern” technologies.
But from the perspective of getting a business off the ground, you should absolutely avoid that. The reason is that the probability of failure increases.

When reviewing AI-generated code, haven’t you ever replied, “That was true for an old version, but the latest version is different”?

Rails has been used with consistent rules for more than 20 years, so it almost never outputs wildly incorrect code.

This high level of trust is one of the reasons I love Ruby.

blog.arkency.com

Simple and Easy to Understand

Take a look at recent release notes from well-known frameworks:

“Server Components added?” Weren’t you the ones generating HTML only on the client side?
“Caching is now easier to handle?” Why do I have to think about caching in addition to what I’m eating tomorrow?
“We fixed a vulnerability!” Oh no, my company’s server was used for Bitcoin mining.
“This rendering feature is only supported on ◯ercel!” What a wonderful challenge to the open-source culture.

Honestly, I think many people are tired of recent web trends.

If that sounds like you, please come to the Ruby and Rails community. It’s quiet here.

For those who know nothing about Rails, here’s a quick summary of recent Rails trends:

Hotwire (Stimulus and Turbo) becoming the default: You can implement SPA-like UI experiences with the familiar Rails development style, while writing almost no JavaScript.
Hotwire Native: By applying WebView technology, you can build native-like iOS and Android apps simply by writing normal Rails.
Kamal: If you can prepare your own computer, such as a VPS, you can deploy in just a few steps. (It’s very easy and cheaper to operate than AWS or GCP!)
Production-ready SQLite and Solid Stack: Rails has moved closer to a setup that can be operated without relying on external infrastructure like PostgreSQL or Redis. (Of course, not relying on external services also makes it cheaper!)

These trends are extremely consistent: “Less is more.”

Despite its overwhelming history, I truly love Ruby on Rails as a framework that continues to evolve in a simpler and smarter direction.

Responses to Common Criticisms of Rails

I’ve talked about my love for Rails so far, but finally, I’d like to summarize my own responses to common criticisms of Rails.

It’s not a statically typed language. The lack of type completion is painful.

→ Whether a language is static or dynamic does not change the value delivered to users. Of course, each has its pros and cons.
But I believe Ruby’s flexibility supports Rails’ “OMAKASE for now” culture.
As for type completion, I don’t think you need to place too much importance on it. The existing ruby-lsp works well enough, and DHH himself apparently doesn’t use editor completion in the first place.
Today we also have completion through GitHub Copilot, so from the perspective of “starting a new business,” I don’t think this is a problem.

Ruby code tends to get messy.

→ This can be said of any language. Engineers with low development ability can write messy code in Ruby, TypeScript, Rust, or anything else.
The reason people often claim that “Ruby code gets messy” may be because Ruby is one of the relatively beginner-friendly languages.
Rather than turning it into a language issue, I think we should focus on how to write readable code, how to design databases appropriately, and how to name variables properly.

Also, based on my experience, senior engineers actually tend to write more verbose and harder-to-read code.
I don’t know why, but one hypothesis is that executives and managers throw unnecessarily complex requirements at “reliable senior engineers,” and the code that satisfies those requirements becomes messy as a result.

So rather than Ruby code itself being dirty, I think the unnecessary complexity and ambiguity of business requirements creates the impression that “Ruby/Rails code is somehow hard to read.”

But it’s not popular these days, right?

→ That is a painfully valid point. Ruby’s popularity is steadily declining.
If your goal is to “learn a programming language and increase your salary,” TypeScript is probably the safer choice.
I hope Ruby will be reevaluated.
Because from a business perspective, it is the best language and framework.

Ruby’s poor performance is terrible!

→ Do you want to drive an F1 sports car to the nearest supermarket?
I’m fine with a used compact car.

Twitter escaped from Rails!

→ And then it became Elon Musk’s toy!

I’m Developing a Rails Boilerplate for Solopreneurs

Because I love Rails, want to succeed with my own business using Rails, and want to launch as many products as possible, I’m developing a Rails boilerplate for solopreneurs that specializes in MVP development.
It will be released soon.
~~If you’re interested, I’ll distribute it for free to testers, so please send an email to haruku.maniwa@laicos.tech with the subject “Template Request.”~~

(Update)
The beta version is no longer available!
The official version can still be purchased at super-rails.com.

Super Rails | Rails Boilerplate for Solopreneurs

A production-ready Rails boilerplate with Devise, Avo, Stripe, ViewComponent and more. Skip the setup, ship your MVP in days.

super-rails.com

Have a great development life!

DEV Community: Hulk in Public

I’ve Given Up on Bun.

Rewrite Bun in Rust #30412

Super Rails | Rails Boilerplate for Solopreneurs

Why I Still Choose Ruby on Rails in the Age of AI

Why I Use Rails

A Strongly Opinionated Community

Specialized for Small-Scale Development

More Than 20 Years of History

Simple and Easy to Understand

Responses to Common Criticisms of Rails

It’s not a statically typed language. The lack of type completion is painful.

Ruby code tends to get messy.

But it’s not popular these days, right?

Ruby’s poor performance is terrible!

Twitter escaped from Rails!

I’m Developing a Rails Boilerplate for Solopreneurs

Super Rails | Rails Boilerplate for Solopreneurs