Agree, I believe the benchmark shown Yaji and jq in this repo is useful for you
https://github.com/kostya/benchmarks/blob/master/README.md
In Faster and simpler with the command line: deep-comparing JSON files with jqkostya
benchmarks
Makefile2014–2025
kostya / benchmarks
benchmarks
Some benchmarks of different languages
62Distinct people
74Mentions
1Explicit recommenders
2.9KGitHub stars
What to know before exploring
What it is
Some benchmarks of different languages
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
I'm surprised you're able to get Turing to run faster, to be honest. I looked at Turing and was impressed by it, but in general my experience with MCMC libraries in Julia is…
wululiyu used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- crystal-lang/crystal · linked in 2 of the same discussions
- nsf/pnoise · linked in 2 of the same discussions
- the-benchmarker/web-frameworks · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:02:05 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year74 dated mentions
Observed mentions: 2014-11-25 20:25:21 UTC to 2025-08-11 11:33:32 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 15 | 1 | 14 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 8 | 3 | 5 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 13 | 0 | 13 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 9 | 1 | 8 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 3 | 2 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Table of Content
Overview
Measurements
Test Cases
Brainfuck
bench.b
mandel.b
Base64
Json
Matmul
Primes
Tests Execution
Environment
Using Docker
Manual Execution
Prerequisites
Contribution
Makefile guide
Binary executables
Compiled artifacts
Scripting language
README update
Docker image update
Overview
The benchmarks follow the criteria:
They are written as the average software developer would write them, i.e.
The algorithms are implemented as cited in public sources;
The libraries are used as described in the tutorials, documentation and examples;
The used data structures are idiomatic.
The used algorithms are similar between the languages (as the reference implementations), variants are acceptable if the reference implementation exists.
All final binaries are releases (optimized for performance if possible) as debug performance may vary too much depending on the compiler.
My other benchmarks: jit-benchmarks, crystal-benchmarks-game, LangArena
Measurements
The measured values are:
time spent for the benchmark execution (loading required data and code self-testing are not measured);
memory consumption of the benchmark process, reported as base + increase, where base is the RSS before the benchmark and increase is the peak increase of the RSS during the benchmark;
energy consumption of the CPU package during the benchmark: PP0 (cores) + PP1 (uncores like GPU) + DRAM. Currently, only Intel CPU are supported via the powercap interface.
All values are presented as: median±median absolute deviation.
UPDATE: 2026-07-19
Test Cases
Brainfuck
Testing brainfuck implementations using two code samples (bench.b and mandel.b).
Supports two mode:
Verbose (default). Prints the output immediately.
Quiet (if QUIET environment variable is set). Accumulates the output using Fletcher-16 checksum, and prints it out after the benchmark.
Brainfuck
bench.b
Language
Time, s
Memory, MiB
Energy, J
C# (Staged)/.NET Core
0.373±0.009
36.62±00.12 + 0.25±00.00
14.33±00.26
Scala (Staged)
0.409±0.011
229.62±03.27 + 7.00±01.44
26.31±00.71
Racket (Staged)
0.885±0.000
101.37±01.65 + 0.06±00.06
34.39±00.17
V/gcc
0.985±0.001
2.12±00.00 + 0.00±00.00
41.65±00.28
Rust
1.008±0.000
1.88±00.00 + 0.00±00.00
42.93±00.33
D/ldc2
1.078±0.001
3.12±00.00 + 0.00±00.00
45.78±00.24
C++/g++
1.097±0.002
3.38±00.00 + 0.00±00.00
46.21±00.59
C/gcc
1.112±0.001
1.38±00.12 + 0.00±00.00
47.10±00.09
D/gdc
1.116±0.001
6.75±00.00 + 0.00±00.00
48.89±00.28
C/clang
1.136±0.000
1.44±00.06 + 0.00±00.00
48.52±00.33
C++/clang++
1.167±0.002
2.88±00.00 + 0.00±00.00
48.87±00.76
Nim/gcc
1.171±0.001
2.00±00.00 + 0.00±00.00
48.80±00.70
Java
1.191±0.000
41.74±00.09 + 1.00±00.00
49.32±00.60
Vala/gcc
1.202±0.001
5.25±00.12 + 0.00±00.00
50.70±00.44
Kotlin/JVM
1.224±0.002
44.48±00.07 + 1.31±00.25
51.60±00.64
Vala/clang
1.235±0.000
5.19±00.06 + 0.00±00.00
52.40±00.39
Go
1.256±0.000
3.75±00.00 + 0.00±00.00
52.69±00.80
C#/.NET Core
1.280±0.001
36.88±00.06 + 0.00±00.00
54.29±00.22
Go/gccgo
1.287±0.000
23.50±00.38 + 0.00±00.00
54.23±00.16
Zig
1.327±0.000
1.38±00.12 + 0.00±00.00
55.13±00.40
Crystal
1.545±0.001
3.25±00.00 + 0.00±00.00
65.69±00.40
Julia
1.564±0.003
244.00±00.12 + 0.38±00.00
67.80±00.43
F#/.NET Core
1.566±0.002
41.88±00.07 + 0.12±00.00
65.15±00.12
Nim/clang
1.579±0.000
2.25±00.00 + 0.00±00.00
65.59±00.57
OCaml
1.607±0.002
3.25±00.00 + 2.62±00.00
75.45±00.78
MLton
1.737±0.006
1.62±00.00 + 0.38±00.00
74.87±00.28
Chez Scheme
1.758±0.005
25.88±00.29 + 3.25±00.00
74.43±00.21
Racket
1.761±0.013
112.86±00.03 + 0.50±00.38
72.49±02.28
V/clang
1.846±0.009
2.06±00.06 + 0.00±00.00
80.00±00.53
Scala
2.379±0.003
66.03±00.14 + 196.44±00.12
108.88±00.92
Node.js
2.954±0.060
49.57±00.06 + 5.78±00.12
126.35±03.17
D/dmd
3.010±0.001
3.50±00.00 + 0.00±00.00
113.43±01.11
Haskell (MArray)
3.497±0.001
4.00±00.00 + 4.00±00.00
144.74±00.32
Haskell (FP)
3.819±0.008
4.12±00.06 + 4.06±00.06
163.47±01.56
Ruby/truffleruby (JVM)
4.645±0.070
354.81±05.59 + 478.37±54.20
221.41±05.66
Ruby/truffleruby
5.169±0.461
197.19±00.69 + 693.00±117.12
252.03±23.51
Swift
5.497±0.001
17.00±00.12 + 0.00±00.00
205.09±04.14
Lua/luajit
5.686±0.024
2.50±00.00 + 0.00±00.00
235.32±01.30
Python/pypy
9.398±0.038
60.19±00.19 + 30.10±00.05
419.65±03.72
Idris
15.088±0.032
21.55±00.26 + 8.00±00.00
677.49±01.79
Elixir
20.456±0.025
90.88±00.30 + 0.00±00.00
814.83±07.69
Ruby (--jit)
30.807±0.033
21.88±00.13 + 4.62±00.00
1275.90±04.28
PHP
34.055±0.041
17.61±00.06 + 0.00±00.00
1447.00±15.80
Lua
37.051±0.168
2.62±00.00 + 0.00±00.00
1528.23±05.85
Ruby/jruby
38.543±0.745
255.48±00.77 + 70.31±00.25
1732.28±34.61
Python
61.009±0.870
11.38±00.00 + 0.00±00.00
2601.10±34.54
Ruby
74.107±0.332
12.12±00.06 + 0.00±00.00
3209.85±28.74
Tcl (FP)
189.615±0.465
4.62±00.00 + 0.00±00.00
8409.77±69.18
Perl
225.517±1.873
7.06±00.06 + 0.12±00.00
9777.03±135.29
Tcl (OOP)
373.095±1.341
4.62±00.00 + 0.00±00.00
16604.13±190.89
mandel.b
Mandel in Brainfuck
Language
Time, s
Memory, MiB
Energy, J
C# (Staged)/.NET Core
2.917±0.001
36.75±00.00 + 3.25±00.00
109.82±00.22
Scala (Staged)
7.118±0.079
228.10±04.74 + 71.23±06.06
356.09±07.48
C++/g++
10.143±0.051
3.50±00.00 + 0.62±00.00
434.41±04.03
C/gcc
12.544±0.019
1.62±00.00 + 0.25±00.00
509.37±03.30
Vala/gcc
12.718±0.010
5.25±00.06 + 0.50±00.00
511.94±00.90
C++/clang++
12.803±0.022
3.00±00.00 + 0.62±00.00
545.25±01.09
Zig
13.030±0.017
1.50±00.00 + 1.00±00.00
556.10±03.71
Java
13.041±0.020
41.77±00.15 + 1.94±00.06
537.41±01.88
C/clang
13.120±0.021
1.50±00.06 + 0.25±00.00
579.20±04.21
Kotlin/JVM
13.463±0.052
44.46±00.06 + 2.56±00.06
571.73±03.08
D/ldc2
14.340±0.012
3.06±00.06 + 0.75±00.00
591.01±03.53
Rust
14.460±0.021
1.94±00.06 + 0.25±00.00
577.37±02.52
Go
14.540±0.007
3.75±00.00 + 0.00±00.00
584.48±01.83
Vala/clang
14.802±0.012
5.12±00.00 + 0.50±00.00
595.99±01.53
Crystal
14.891±0.054
3.38±00.06 + 0.38±00.00
631.17±02.60
D/gdc
15.17
Read the full README on GitHubWhat Hacker News says
4 sourcesI believe this comparison benchmark could be useful for you and you can expand further with more tests. Although I got downvoted for sharing a link.
https://github.com/kostya/benchmarks/blob/master/README.md
In Faster and simpler with the command line: deep-comparing JSON files with jqI know you're publicly directly messaging, but as an outsider to the discussion, I don't see any actual mention in your posts why D isn't included. Just that it "used to be."
There are many of benchmark projects that include D and don't appear to be struggling under any kind of massive burden. For example:
https://github.com/kostya/benchmarks
What are your actual reasons for not keeping D... "scala... and Clojure and ..."? The results in the previous link show D as a massive competitor (sometimes 1st place beating C and C++) on both memory and speed. Wouldn't the purpose of benchmarks be... to highlight useful, highly-scoring languages? Isn't that one of the primary reasons people read benchmarks?
(The D implementations are also often smaller in lines of code, as per this benchmark project:
https://togototo.wordpress.com/2013/08/23/benchm
Read the rest
Last fall I tried to figure out why Rust is slower than D in a base64 benchmark (https://github.com/kostya/benchmarks). It turned out that decoding in Rust is really fast but encoding is a bit slow. I looked at the assembly output of both programs and I could more or less follow the steps in the Rust version, but the D version was only about 5 SIMD instructions (without a single bit shift). I also checked the source code, the Rust version is fairly long, because a part of the hot loop is manually unrolled, but the D version looked like the simple, naive implementation in C. It might be a result of newer LLVM version (LDC was already using LLVM 5 and rustc is still on LLVM 4) or rustc still might have issues with optimizer settings (both binaries were compiled for Intel Haswell).
In Fast base64 encoding and decoding