If you are interested ins speed, here is a huge list of similar benchmarks: https://github.com/kostya/benchmarks
In Nim vs. Crystalkostya
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, 2:59:58 PM 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
8 sourcesKinda biased benchmarks u just took best of crystal and worst of nim from this xd -> https://github.com/kostya/benchmarks
In Nim vs. CrystalNim-lang. Its similar to Python in Syntax but runs at close to native speed. Nim has beautiful syntax.
https://github.com/kostya/benchmarks
https://nim-lang.org/
In Ask HN: What is your favorite non-generic or semi-obscure programming language?> You can only see allocation advantage in micro benchmarks where the app stops before the GC will start.
The golang gc is tuned for latency at the expense of throughput, meaning if you look at the duration of time spent in GC over the course of the code execution, it would actually be longer compared to a GC tuned for throughput.
If you have a use case that requires high throughput, then you cannot change the GC behavior. Unlike on the JVM, where you have several GCs to choose from. The JVM is also getting two new low latency GCs for use cases that require low latency.
And it's not just microbenchmarks where Java does better than golang, it's especially longer running processes where the JVM's runtime optimizations really kick in. Not to mention that the JVM is getting value types as well to ease the load on the GC when required (it does
Read the rest
an excellent job as it is even without value types).
I did a dummy port of the C# version of the Havlak code here[1] to Java, preserving the same behavior and not making any data structure changes. On the machine I tested on, the C# version took over 70 seconds to run, while the Java version took ~17 seconds. In comparison, the C++ version took ~24 seconds, and the golang version took ~30 seconds.
Yes, you could most likely spend much more time tuning the C++ version, avoiding allocations, and so on, but at the expense of readability. This is what the JVM gives you, you write straight-forward, readable code, and it does a lot of optimizations for you.
The brainfuck2 benchmark is especially interesting. Kotlin tops the list, but I was able to get Java to the same performance since Kotlin by writing it in a similar manner as the Kotlin code. Again, Java/Kotlin beat out even C++ when I tested them, and by quite a margin.
[1] https://github.com/kostya/benchmarks
According to the benchmarks at https://github.com/kostya/benchmarks, Crystal is about twice as fast as Go.
In D is being used for autonomous driving research – Audi and MercedesSince you are asking about performance of some languages, you may find this helpful https://github.com/kostya/benchmarks
In D is being used for autonomous driving research – Audi and Mercedes* vs many languages: https://github.com/kostya/benchmarks
* vs many languages: https://github.com/frol/completely-unscientific-benchmarks
* vs Julia and Python: https://github.com/SimonDanisch/julia-challenge/issues/1
* web frameworks vs many: https://github.com/the-benchmarker/web-frameworks
In Nim – Natively compiled language with hot code-reloading at runtime [video]You can find them although they tend to be out of date and/or piecemeal. I think they're still useful.
For example:
https://github.com/drujensen/fib
https://gist.github.com/sdwfrost/7c660322c6c33961297a826df4c...
https://github.com/kostya/benchmarks
My general sense is that Nim is most competitive as an alternative to Python and/or things like Julia, in that it's as expressive and easy to understand as those, but has performance closer to C or Rust than something like Python. Julia is similar to Nim but I think Nim seems cleaner in its implementation overall, and targets much more general use scenarios.
I've been really impressed by Nim. There are some little things that have irritated me, like case insensitivity, but I wish it got more traction in the community. Right now the only thing that it doesn't seem to have going for it is librar
Read the rest
y support. For the numerical applications I do I'd prefer it over everything else, except everything else has huge resource bases, so something that's already packaged in those languages would have to be done from scratch in Nim, which isn't feasible.