I think the problem is the ffi overhead to C from Go is really high, like, way higher than any comparable language, because of the segmented stack thing. I mean the nice thing about Love2d is that LuaJIT has the best ffi overhead when calling C.
https://github.com/dyu/ffi-overhead
In Nine years of Godyu
ffi-overhead
C2014–2025
dyu / ffi-overhead
ffi-overhead
comparing the c ffi (foreign function interface) overhead on various programming languages
25Distinct people
28Mentions
0Explicit recommenders
700GitHub stars
What to know before exploring
What it is
comparing the c ffi (foreign function interface) overhead on various programming languages
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:01:12 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 year28 dated mentions
Observed mentions: 2014-04-08 01:17:48 UTC to 2025-11-23 13:56:53 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 | 0 | 0 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 1 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
ffi-overhead
comparing the c ffi overhead on various programming languages
Requirements:
gcc
tup
zig
nim
v
java7
java8
go
rust
d (dmd and ldc2)
haskell (ghc)
ocaml
csharp (mono)
luajit
julia
node
dart
wren
elixir
My environment:
- Intel i7-3630QM laptop (4cores, HT) with 16g ram
- Ubuntu 14.04 x64
- gcc/g++ 5.4.1
- tup 0.7.4
- zig 0.2.0
- nim 0.14.3
- v 0.2.2 aebb551
- java 1.7.0_72 and 1.8.0_91
- go 1.8.0
- rust 1.17.0-nightly (c0b7112ba 2017-03-02)
- dmd 2.0.71.1
- ldc2 1.9.0
- ghc 7.10.3 (at /opt/ghc)
- ocaml 4.06.1
- mono 5.12.0.226
# dynamic languages
- luajit 2.0.4
- julia 0.6.3
- node 6.9.0 (at /opt/node)
- dart 1.22.0 (at /usr/lib/dart)
- wren 0.1.0
- elixir 1.6.5 (Erlang/OTP 20)
Initialize
tup init
Compile
./compile-all.sh
Compile opts:
-O2 (gcc - applies to c/jni/nim)
-C opt-level=2 (rust)
Run
./run-all.sh 1000000
Measurement:
call the c function "plusone" x number of times and print out the elapsed time in millis.
int x = 0;
while (x < count) x = plusone(x);
2 samples/runs
Results (500M calls)
./run-all.sh 500000000
The results are elapsed time in milliseconds
============================================
luajit:
891
905
julia:
894
889
c:
1182
1182
cpp:
1182
1183
zig:
1191
1190
nim:
1330
1330
v:
1779
1781
rust:
1193
1196
d:
1330
1330
d ldc2:
1191
1189
haskell:
1197
1198
ocamlopt:
1634
1634
ocamlc:
4299
4302
csharp mono:
2697
2690
java7:
4469
4472
java8:
4505
4472
node:
9163
9194
node scoped:
15425
15409
go:
37975
37879
dart:
31265
31282
dart scoped:
61906
69043
wren:
14519
14514
elixir:
23852
23752
Read the full README on GitHubWhat Hacker News says
10 sources> I think of Julia and swift as higher-level languages, more domain-specific. Different tools for different problem domains.
Well...my particular interest in these types of languages is primarily in the realm of soft real-time simulation, specifically various kinematic simulations.
Of the three, only Julia is garbage collected, and (unlike some other GC languages) it's fairly easy to not exercise the collector. I'm encouraged that will continue to be the case, since there's an organization using it for robotics, which is implicitly a hard real time use case.
http://www.juliarobotics.org/
Julia, Swift and Rust are all clearly general purpose languages. Swift is unabashedly general purpose, while Julia and Rust each have a primary niche - math/science and systems, respectively. All three use the excellent LLVM infrastructure.
Aside from de
Read the rest
terminism (which mainly requires pre-allocating nearly everything), my primary requirements are expressiveness/productivity, readability, and efficient runtime performance.
All three languages produce highly optimized code, and Rust probably has the edge as far as efficiency goes - but it clearly loses on the first two criteria, at least to Julia. If one needs access to machine level functionality in Julia, there's an extremely efficient C FFI, so mixing Rust and Julia (for instance) would be painless if needed.
https://github.com/dyu/ffi-overhead
It's a great time to be a software developer, and things will only get better as languages and tooling continue to improve!
good question! i'm not an expert.
my understanding is go is slow because each function call has to copy over to a bigger stack (goroutines have tiny stacks to start, and grow on demand, but c code can't do that, natch) and because it has to tell the goroutine scheduler some stuff for hazy reasons.
this github issue has a lot of interesting discussion of go ffi: https://github.com/golang/go/issues/16051
these benchmarks https://github.com/dyu/ffi-overhead seem to show that a c call via cgo will be about 14 (!) times slower than a c call from c# in mono, which itself is about 2 times slower than just a plain c call.
In Getting to Go: Garbage collection and runtime issuesGreat ffi perf too! From the benchmark over at github.com/dyu/ffi-overhead, julia is on par with luajit.
In My favorite things that are coming with Julia 1.0[Here's a C# example](https://github.com/dyu/ffi-overhead/pull/10).
In Comparing the C FFI overhead in various programming languagesOP poses a good question and I don't think it's a simple case of GC vs. no GC. In Nim's case it might have something to do with not using the C int types (PR already open to fix this: https://github.com/dyu/ffi-overhead/pull/6)
In Comparing the C FFI overhead in various programming languagesThis would be worth mentioning on the project issue page, methinks. The author might not want to do the work but it's a very good thing to keep in mind for anybody looking at the project and making judgement calls off of it.
https://github.com/dyu/ffi-overhead/issues
I didn't do so because it wasn't my idea. I certainly don't mind though.
In Comparing the C FFI overhead in various programming languagesComparing the C FFI overhead in various programming languages
141 points · Open discussionWell, see my issue: https://github.com/dyu/ffi-overhead/issues/2
In Writing space invaders with GoMy understanding is that Go's ffi overhead[1] makes game development impractical at a certain level, due to the amount of opengl calls you have to make. Is this still the case?
[1] https://github.com/dyu/ffi-overhead/blob/master/README.md
In Writing space invaders with Go