The Moonbit team recently published a blog post claiming their language runs "30% faster than Rust" for FFT workloads. This is a lie by omission. They benchmarked against a deliberately crippled Rust implementation that no competent programmer would write.

Sources:

What the benchmark is

This is a straightforward iterative Cooley–Tukey FFT over a basic Complex type with real and imag fields. There's nothing exotic here: it's the kind of benchmark where idiomatic, allocation-conscious Rust should do very well when implemented sanely.

What was wrong with the Rust baseline

The Rust version Moonbit used in their comparisons was knee‑capped. Concretely:

Reusing buffers/allocations is something I have to do in otherwise ordinary Java web applications and APIs. This isn't fancy, advanced, or specific to Rust in any way.

Why this is dishonest

Moonbit's blog post claims their FFT implementation runs 30% faster than Rust. They published the benchmark code at https://github.com/moonbit-community/benchmark-fft

This is the sort of thing you'd lose marks for in a sophomore CS class: it's not representative of how to write a performant FFT in Rust and it dramatically under-states Rust's performance ceiling on this exact algorithmic shape.

This is deliberate misrepresentation. There have been PRs posted for fixing the Rust implementation for the last two weeks with no replies and no merges or blog posts retracting their claim.

What I changed

In my PR I:

See the PR and discussion: github.com/moonbit-community/benchmark-fft/pull/15

The fixed benchmark results

The benchmark implements a straightforward Cooley-Tukey FFT algorithm using a Complex struct with real and imag fields. This is basic numerical computing and is the kind of thing Rust excels at when you're not deliberately sabotaging it.

How bad was their code?

Their Rust example was so poorly written that it took me just 5 minutes of prompting GPT-5 to generate a Rust implementation that was 2.33x faster than Moonbit. Five minutes. With an AI assistant.

If an AI can outperform your "benchmark" in five minutes, you're not benchmarking languages - you're benchmarking your own incompetence or dishonesty.

What they claimed vs reality

Their blog post uses these bogus numbers to claim Moonbit has superior performance for numerical computing. They write about "value types" and "bits patterns" as if their language design inherently produces better performance.

But when you fix the obvious problems in their Rust code:

That's not a small difference. That's not a measurement error. That's the difference between a fair comparison and a scam. Especially when it took a single prompt and 5 minutes to get GPT-5 to produce a version that was 2.33x faster and that passed validation against rustfft

Why this matters

Publishing language marketing posts that rely on an unfair and unrealistic baseline undermines trust. The benchmark in question is simple enough that a competent Rust baseline is trivial to produce. Using a recursively allocating implementation as the "Rust" side of a performance comparison is not credible.

Moonbit's blog post cites numbers derived from this broken baseline and makes a very broad claim on that basis. Those numbers do not reflect the typical performance characteristics of Rust on this task and should not be used to draw conclusions about relative performance.

What Moonbit should do

  1. Retract or amend the post with a clear note that the Rust baseline was flawed.
  2. Re-run with a corrected Rust implementation (e.g., the one in my PR).
  3. Publish updated numbers and methodology so the community can reproduce the results.
  4. Apologize for misleading the developer community

That is the minimum required to restore confidence in the published comparison.

Until they do this, every benchmark they publish should be treated as suspect. Every performance claim should be independently verified. Every comparison should be assumed to be rigged. Other performance numbers they've claimed in their marketing copy looks potentially suspect. I work on perf engineering and evaluation regularly.

Benchmark fairness and comparison fidelity

I want to note that I was very conscious of not making the Rust implementation dissimilar to the other implementations.

Again: the core issue is not that Rust "wins"; it's that the original Rust baseline was obviously broken, and Moonbit's post relied on it. Fix the baseline, fix the conclusions.

References

Check my work

Don't take my word for it. The code is all public:

Run the benchmarks yourself. See the difference. Judge for yourself.

The lesson

When someone shows you benchmark results that seem too good to be true, they probably are. When a new language claims to beat established, heavily-optimized languages by significant margins, check their work.

And when you catch someone lying with benchmarks, call them out. The programming community deserves better than this.