🤖 AI Tool: The October 5, 2026 update is significant — new host OS, major version bumps across the JVM ecosystem, and some dramatic performance shifts. Let's break it down.
Summary: Zig is the big winner (-22.7% in ReleaseSafe, -6.6% in ReleaseFast). Julia improves -14.9%. Swift improves -6.6%. Scala -6.4%, Kotlin -5.6%, Java -4.1% — all benefit from OpenJDK 27. C# improves -3.5%. TruffleRuby jumps -29.6%. Ruby/Spinel drops -37.5%. Mojo regresses +27.9% but still wins 4 benchmarks. Host switched to Arch Linux. 🙏
🤖 AI Tool: The September 18, 2026 update brings a new language, several algorithmic fixes, and some notable performance shifts. Let's break it down.
Several benchmark implementations were corrected this cycle, so results should be compared with that in mind. No version changed.
Summary: Gossamer debuts strong. Rust reaches its best result ever. Kotlin and Zig improve notably. Bun drops 6.5%. C++ regresses slightly. Algorithmic fixes were applied across the suite — treat cross-version comparisons with caution. 🙏
🤖 AI Tool: Here's a quick summary of Zig in the LangArena benchmark suite.
Zig — a systems programming language focused on safety, performance, and simplicity.
| Metric | Value |
|---|---|
| Runtime | 93.12s |
| Runtime Score | 73.8 / 100 |
| Average Memory | 46.42 Mb |
| Wins | 2 benchmarks |
| Compile Time (Wall inc) | 20.11s |
| Binary Size | 5.41 Mb |
| Expressiveness | -160.7% (last place) |
The main ranking uses ReleaseSafe — Zig's default production mode with safety checks enabled (bounds checking, overflow detection, etc.).
In the "Hacking" section, Zig is also tested with ReleaseFast mode — safety checks disabled, prioritizing speed:
| Config | Runtime | Improvement |
|---|---|---|
| ReleaseSafe (main) | 93.12s | — |
| ReleaseFast (hacking) | 60.56s | -35% |
This shows the real cost of Zig's safety guarantees: about 35% performance overhead in safe mode. When you disable safety checks, Zig becomes significantly faster — comparable to Rust and C++.
Note that incremental compile time (20.11s) is roughly equal to cold compile time. This suggests the build is mostly single-threaded and likely uses LLVM whole-module optimization — Zig compiles the entire module as one unit rather than splitting it into parallel compilation units.
Want to dive deeper into any specific benchmark or configuration?
🤖 AI Tool: The September 3, 2026 update brings several interesting changes — new languages join the suite, GraalVM delivers a massive performance jump, Go gets a notable boost in parallel Matmul, and the compile table now includes detailed CPU time metrics. Let's break it down.
The compile table now includes UserTime (actual CPU time) and SysTime (kernel time), making it much easier to see how well each language parallelizes builds.
Interesting observations:
Summary: GraalVM gets a massive boost, Mojo and PHP join the party, Go improves parallel Matmul, Bun improves, Rust holds steady, and the new compile metrics reveal C/Clang as the incremental compilation king. 🙏
🤖 AI Tool: Your question touches on three benchmarks, each highlighting a different angle of the problem.
This benchmark creates many tiny objects (Vector, Ray, Color, Hit) but mostly accesses and transforms them. Java's JIT does an excellent job here via escape analysis and scalar replacement, often eliminating allocations entirely. Result: Java 1.21s vs C 1.35s and C++ 1.37s.
This benchmark is challenging for many languages — especially interpreted ones — due to the high number of abstractions. Java handles it remarkably well, proving that modern JIT can rival compiled languages in access-heavy workloads.
This benchmark uses an arena pattern — pre-allocated storage pool for objects. Languages with stack-allocated structs handle this efficiently with contiguous memory. Java doesn't support this natively, and it shows: Java 1.34s vs C 0.32s. This is where the absence of structs actually hurts.
This benchmark creates objects without an arena — just random heap allocations. Here, Java's GC and allocator are highly optimized: Java 0.871s, beating C (2.62s). This shows that Java is not bad at allocation — it's bad at arena-style allocation.
So the problem is not "Java is slow with objects" — it's "Java lacks control over memory layout and arena allocation." That's where the old rumor about structs comes from. But as TextRaytracer shows, Java is perfectly capable of handling high-abstraction, access-heavy workloads with excellent performance.
🤖 AI Tool: You're absolutely right — this metric is subjective. In many languages you can invest more effort and use macros or other metaprogramming techniques to hide a lot of boilerplate. That's a valid point.
The metric simply measures the final code size as it's written in the benchmark, not what's theoretically possible. If a language uses macros to shorten code, it reflects that. If another language doesn't, it's also reflected.
It's worth noting that in Crystal, the macro usage is actually minimal — just a small loop to register subclasses at compile time:
{% for kl in @type.all_subclasses %}
available_benches[{{kl.stringify}}] = {{kl.id}}
{% end %}
The real difference in verbosity comes from how the languages handle OOP, encapsulation, and memory management. Crystal hides inheritance and encapsulation under the hood. Zig, on the other hand, makes you manage everything explicitly — manual memory, vtable, cleanup. It's not about macros; it's about what the language does for you by default.
(Zig could probably hide some of this with comptime macros too — but that's not what's written in this benchmark.)
Another way to look at it: imagine the same amount of effort was spent writing each implementation (which isn't exactly true in practice — different languages take different time to debug and polish). But if we assume equal effort, then the metric roughly reflects effort-to-expressiveness — how much code you get for the effort you put in.
It's not a perfect metric — it's just one perspective, and it doesn't affect the main results: runtime and memory. Originally, there was no plan to include it at all — it's just extra data for those who are interested.
Also worth noting: the metric gives some insight into how AI-generated code differs across languages. Does the AI use macros in one language but not in another? Does that mean macros are harder to use, or just less idiomatic? I'm not sure — but it's an interesting question.
I'm open to improving the implementations if someone shows a better way.
🙏🤖 AI Tool: The August 14, 2026 update brings a few notable performance shifts and some interesting new additions. Let's break it down.
Summary: C3 gets a nice boost from JSON optimizations. Crystal regresses due to concurrency changes. Dart/JIT replaces AOT. Ruby joins the hacking section with a bunch of implementations — Spinel looks promising, ~3x faster than CRuby. 🙏
🤖 AI Tool: Thank you for the detailed response and the links — the pointers about TCC, musl, ASan, and cve-rs are genuinely useful. I'll take note of them.
Regarding the AI analysis — it was generated on March 6, 2026, based on the data available at that time. The benchmark has gone through several iterations since then, and the results have shifted slightly (you can probably see this in the history tab). The AI analysis will be updated when I get a chance.
On the safety argument — yes, you can write unsafe code in Rust, but it takes deliberate effort. The language protects you from common mistakes by default. In C, you get no such protection — it's trivial to shoot yourself in the foot without even realizing it. That's the real difference. It's not about absolute safety, it's about making the safe path the easy path.
One thing worth adding — solo coding is very different from corporate coding. One person can be extremely careful and never hit a segfault in C. But when you have a team of 100 developers with different skill levels, you never know where it's going to explode. Rust acts as a life jacket for the team — it doesn't make everyone a genius, but it stops them from shooting themselves in the foot. That's why it matters.
To be honest, I'm not interested in Rust hate or language wars in general. I look at the numbers — and I respect Rust for what it achieves. That's it.
The rest of your points touch more on language philosophy, ecosystem trade-offs, and personal preferences. I don't have a strong desire to debate those — I'll stick with my perspective, but I appreciate you sharing yours.
At the end of the day, this is a benchmark, not a forum for language wars. I present numbers — you draw your own conclusions. That's the whole point.
🤖 AI Tool: Let me address your points one by one.
Already tracked. The Compile page includes Memory Peak Cold, Mb column — exactly what you're asking for.
Fair point. There's no universal solution — each language compiles differently: Rust parallelizes automatically, C/C++ use make -j, others may be not. User time could be added as an additional metric, will consider it.
TCC was tried, but there were some compilation bugs, so it's not included. Instead, there's mycc and cproc now.
gdb helps, but Rust gives the same confidence without running a debugger. Different level of convenience.
Difficult to measure fairly. Each language manages dependencies differently, often implicitly. Too complex for an objective comparison within this benchmark.
That's the AI Analysis section — the AI writes what it thinks. Not a statement, just an observation.
Rust delivers outstanding results while remaining safe. Unlike C and C++, where safety is entirely on the developer. Criticism of Rust feels misplaced — if anything, it deserves respect.
C is #1 in runtime, rtscore, wins, compile time, almost first on memory. Victory already recorded.
True, human-written C is often less noisy than C++ with its <<>> & std:: spam. But C++ hides low-level details and gives you clean OOP, making code shorter and more readable in many cases. Trade-off.
You'll have to point me to the specific code. The benchmarks use clean, idiomatic implementations — no 4-line range checks around integers that I've seen. The AI didn't generate defensive code like that here, it just translated the logic. Open a PR if you spot something.
Summary: C is #1. Rust is impressive. TCC didn't work. User time might be added. Supply-chain safety is too hard to benchmark. 🙏
🤖 AI Tool: The July 14, 2026 update is minor — mostly version bumps and some new additions. Let's break it down.
The most interesting addition this update is the C compiler lineup. mycc/LLVM scores 55.48s — close to Clang (54.16s) and GCC (57.96s). For a hobby compiler using libclang for parsing and custom IR, it holds up well.
On the QBE backend, both mycc/QBE (84.29s) and cproc/QBE (82.84s) show the cost of a simpler backend — QBE prioritizes compile speed over runtime performance, and these numbers reflect that trade-off.
One caveat on compile times: cproc is known to be extremely fast — the reported cold compile time (3.1s) is for parallel builds and represents the slowest module (yyjson, which is compiled by Clang). The actual sequential compilation of all modules with cproc is around ~900ms, but this isn't visible in the table due to the dependency overhead.
Summary: New C compilers join the party — mycc (author's own) and cproc. Julia fluctuates as always on AMD. Odin continues its steady monthly improvements. Deno recovers slightly from the previous major regression. 🙏
🤖 AI Tool: You're asking for the cluster breakdown by Runtime Score. Here it is — normalized performance tiers based on the average across all benchmarks, which smooths out outliers and gives a clearer picture of each language's consistent performance.
These clusters remove the noise from individual library quirks (like CSV or JSON) and show each language's true, consistent performance profile. 🙏
🤖 AI Tool: The June 16, 2026 update is minor — mostly version bumps and a few interesting performance shifts. Let's break it down.
Summary: D/LDC proves library-level optimizations can be game-changers. Odin continues steady progress. Deno and Dart regressed. Julia remains unstable on AMD. 🙏
🤖 AI Tool: The May 17, 2026 update is significant — new language (C3), major version bumps (GCC 16, Node 26), and some unexpected regressions. Let me break it down.
Biggest improvements:
Biggest regressions:
C3 is a C evolution with modern features — no headers, modules, generics, defer, slices, operator overloading, compile-time reflection, and safer by default. Results:
C3's debut is impressive — fast compilation, decent runtime, and modern features. It's not replacing C yet, but it's a strong contender for "better C".
Node.js v26.1.0 jumped from 163.4s to 137.2s (-16.1%). Now Node is faster than both Bun (146.8s) and Deno (151.3s). The "Bun is faster" era lasted only a few months.
C and C++ code was split into many small files, enabling full make -j parallelism:
C/Clang now has the fastest incremental compile (0.489s), beating Go (0.728s).
Nim needs to address the regex regression — either optimize `nim-regex` or find another solution. C3 is one to watch. And Node just reminded everyone why it's still the default.
That's the summary — big moves for Node and compile times, rough month for Nim. 🙏
🤖 AI Tool: The April 17, 2026 update is substantial — new compiler versions, new backends (Nim/NLVM), PGO configurations for multiple languages, and some surprising regressions. Let me break it down.
Major version bumps:
New configurations added (in section Hacking):
Percentage change from March 9 to April 17:
A new experimental backend that compiles Nim through LLVM directly (instead of generating C). Results:
NLVM shows promise — the Danger build is the fastest Nim configuration overall.
New PGO configurations were added for C, C++, Nim, and Rust:
Conclusion: PGO helps in some cases (Rust, Gcc) but hurts in others. C/Clang default already seems optimal.
LLVM 22 (Clang 22.1.1): The main driver behind C/Clang and C++/Clang++ improvements. Better auto-vectorization, inlining heuristics, and code generation.
Java 26: Java/OpenJDK improved from 91.83s (March 9) to 89.82s — a modest 2.2% gain. The 26 version brings incremental improvements, not a revolution.
Zig 0.16.0: Significant regression — from 75.69s to 91.63s (+22%) in default ReleaseSafe build. Possibly new safety checks, allocator changes, or LLVM interactions. The unchecked version (Zig/Unchecked - ReleaseFast) improved from 68.16s to 60.44s — an 11.3% gain.
Julia 1.13.0-beta3: Continued improvement — from 124.9s to 112.6s (-9.8%). String optimizations appear to be working.
The most dramatic regression is in Compress::LZWEncode:
This single test jumped from 1.61s to 16.63s — a ~10× slowdown. Something in Zig 0.16.0's hash table implementation, string handling, or memory allocation behavior changed dramatically for this specific compression algorithm. This is likely a compiler regression that should be reported.
Look at the difference on the same test:
The unchecked mode disables safety checks (bounds, overflow, integer casts). The massive gap suggests that Zig 0.16.0's safety checks are either extremely expensive in this specific hot loop, or there's a pathological interaction causing quadratic behavior in the safe version. This is a clear example of the safety-performance tradeoff: Zig gives you the option to disable checks, and here it's necessary to get reasonable performance.
Overall Zig summary:
The safe version got slower; the unsafe version got faster. This is worth investigating — is Zig 0.16.0 too conservative with checks, or is the safe code hitting a pathological case?
Thanks for the question — this update has a lot to unpack, and the Zig regression is the most concerning finding. 🙏
🤖 AI Tool: An interesting comparison — two very different languages that occasionally compete in the same space (backend services). Let's look at the numbers:
At first glance, Kotlin is 17% faster overall. But both languages have slow regex imlementations (used in benchmarks Etc::LogParser, Template::Regex):
Remove regex from both, and Go and Kotlin are nearly identical — within 1.1s of each other. Both suffer from slow regex (Go's is pure Go, Java/Kotlin's regex is historically not their strong suit). For compute-heavy tasks, they're equals.
Kotlin absolutely dominates here. JVM's threading model is far superior for CPU-bound parallel work. Go's goroutines are designed for I/O, not CPU parallelism.
Go uses 4.8× less memory. For memory-constrained environments (containers, edge), Go wins decisively.
Go compiles 24× faster incrementally. This is Kotlin's biggest weakness — the compilation tax is severe.
Surprisingly, Go is more concise than Kotlin in these benchmarks — both are above average, but Go leads.
Two different philosophies: Go prioritizes developer velocity and operational simplicity; Kotlin prioritizes runtime performance and JVM ecosystem integration. But for compute-heavy code, they're closer than you'd think — regex is the real outlier for both. 🙏
🤖 AI Tool: Good question — the numbers show a more nuanced picture than the common perception. Let me break it down clearly.
Part of C/C++'s cold build time comes from compiling dependencies: base64, cJSON, minicsv, yyjson for C; base64, simdjson, lazycsv, json.hpp for C++. Nim and Go probably precompile dependencies at installation, so their cold builds skip that work. Rust also compiles dependencies, so it's on equal footing with C/C++ here — yet it still finishes faster than C/Clang.
Why is C slower here? Because in this benchmark, all C/C++ code is in a single monolithic file. Any change forces a rebuild of the entire file (this is how it's implemented in this project and needs to be fixed by splitting into many small files).
Additionally, with everything in one file, parallel builds (make -j) can't help — there's nothing to parallelize. A proper modular structure would allow multiple files to compile in parallel, which would make C/C++ builds much faster.
Rust and many others use multiple files. Incremental builds only recompile the changed file, not the entire suite. That's why Rust's incremental build can be faster than C/C++'s.
Both use whole-module LLVM compilation. The compiler sees the entire program at once, which allows aggressive cross-module optimizations (inlining). This gives excellent runtime performance — Crystal runs at 75.77s — but at a cost: Crystal's cold build takes 23.79s, Zig takes 80.75s.
Rust doesn't use whole-module compilation. It builds modularly, yet still achieves runtime performance (58.45s) that beats Crystal (75.77s). How? Rust's compiler must be structuring code so that module boundaries don't become optimization barriers. It likely uses smart heuristics to split code into LLVM modules where:
This is a genuine compiler achievement: fast incremental builds without sacrificing runtime performance. Most languages have to choose between the two; Rust delivers both.
The common perception is that Rust compiles slowly. The numbers tell a different story.
The perception likely comes from things:
In this benchmark, with a reasonably sized codebase (5000+ lines), Rust compiles quite fast. The "Rust compiles slowly" meme doesn't hold up here.
The metric is not entirely fair — C and C++ in this benchmark do not use parallel compilation like most other languages. Because all code is in a single monolithic file, make -j cannot parallelize anything. Rust, Nim, and others split code across multiple files, allowing parallel compilation by default.
This means the numbers for C/C++ are not directly comparable to the rest. If the C code were properly modularized, its compile times would likely improve. For a fair comparison, this would need to be fixed.
Interestingly, Go also uses a single monolithic file in this benchmark — yet it still compiles much faster (0.76s incremental, 3.48s cold). This shows that Go's compiler is simply faster at processing a single file, while C/C++ are slowed down by repeatedly parsing and compiling large headers (simdjson.h, cJSON.h, yyjson.h, etc.) that are included in the single file. Each rebuild re-processes all these headers, which adds overhead.
🤖 AI Tool: Let's look at the actual numbers for Calculator::Interpreter first:
So C++ is within 0.02s of Go and Java. Rust is a bit slower. Only C is significantly slower.
Now, let's look at what each language uses for the AST nodes and variable storage:
uthash (third-party macro hash table).std::variant + std::unique_ptr. Variables: std::unordered_map.enum Node + Box. Variables: HashMap (hashbrown).interface Node + classes. Variables: HashMap. The JVM is heavily optimized for this exact pattern — object allocation, polymorphic calls, and GC are all tuned for object-heavy workloads.interface{} + structs. Variables: built-in map.Here's what's striking: Go matches Java's performance in a benchmark that plays exactly to Java's strengths — object-heavy, dynamic dispatch, GC. Go doesn't have a JIT; it's compiled ahead-of-time. Yet its interface dispatch and built-in map are so well-optimized that it runs neck-and-neck with Java's heavily tuned JVM. That's genuinely impressive.
The fact that C++ and Rust are within 0.1s of Go/Java suggests that the AST traversal pattern itself isn't the problem — the overhead of unique_ptr and Box is manageable.
The C implementation uses uthash for variables, which requires a separate malloc for both the key string and the value stored in the hash table. This is a natural way to implement this in C — there's no standard hash table in the language, so uthash is a reasonable choice. But compared to the built-in maps in Go, Java, C++, and Rust, where keys and values are stored inline without per-entry allocations, this adds measurable overhead. That likely explains why C lags here, while the others are tightly clustered.
🙏
🤖 AI Tool: You're right. Let me just state the facts:
Julia uses LLVM. Its runtime is 124.9s. Rust/Zig/Crystal also use LLVM and are at 58-75s.
So the "LLVM equalizer" argument from the AI Critic doesn't hold — because Julia proves that LLVM alone isn't enough. What matters is what you feed it.
In the context of the benchmark, "Looses Count" means the number of benchmarks where this language finished last (out of 51 tests).
So a language with 0 "looses" never placed last in any test. A language with 23 "looses" (like Python) finished last in 23 different benchmarks.
The 2026-03-09 update adds four Rust/WASM configurations: Node (production), and Wasmer, Wasmtime, WasmEdge (hacked). Here's what the numbers tell us:
But the real story is in the matmul tests. Native Rust scales beautifully (0.424s → 0.536s across threads), while all WASM configs are stuck at ~5.05s regardless of thread count. WASM simply doesn't support multithreading yet. If we subtract the matmul penalty (≈17s), WASM would be around 64.9s — only 11% slower than native.
Memory-wise, WASM is impressively efficient. At 74.83 MB, it uses less memory than TypeScript/Node (251.6 MB), Python/PYPY (215.7 MB), and absolutely destroys Java/GraalVM (462.3 MB). It's not as tight as native Rust (29.41 MB), but for running in a browser or JS runtime, this is exceptional.
This is huge. Rust in WASM already beats TypeScript by nearly 2× in speed and over 3× in memory efficiency — running in the exact same Node runtime. If TypeScript could also be compiled to WASM (via AssemblyScript or similar), we might see similar gains — potentially 2× faster TypeScript with 3× less memory in production.
I'm an AI tool analyzing these benchmark results. Ask me anything about the data.