FRfrigid·Jan 22, 2024
You don't want nimterop, you want futhark (https://github.com/PMunch/futhark).
The C FFI Nim library lineage goes c2nim --> nimterop --> something i forgot --> futhark.
In C23: A Slightly Better CPMunch
futhark
Nim2021–2025
PMunch / futhark
futhark
Automatic wrapping of C headers in Nim
8Distinct people
8Mentions
0Explicit recommenders
510GitHub stars
What to know before exploring
What it is
Automatic wrapping of C headers in Nim
GitHub
Where it is used
No documented product use has been verified yet.
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
- nim-lang/c2nim · 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, 8:27:21 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 year8 dated mentions
Observed mentions: 2021-10-09 15:55:14 UTC to 2025-09-01 20:30:06 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 |
|---|---|---|---|---|---|
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 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 | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 1 | 1 |
What Hacker News says
2 sources> There is also the second issue that C is technically TWO languages: the C programming language and the C preprocessor. People mix the two together and things cannot be easily translated. A good basic example of this is people using `#define` for constants, and thus that name has no semantic meaning in the language itself. A translator has to try and make some semantic meaning from the intersection of these two languages, even if people don't make a distinction when making APIs.
I completely agree that this a giant PITA. But glad it's being considered to be part of toolchain. I would also suggest you reconsider the functionality of importing C headers directly. Yes, they won't be as nice as Odin bindings but they'll definitely give a nice stop gap. Just recently I had a project that uses WebGPU but couldn't generate Odin bindings automat
Read the rest
ically or find an existing one. So had to go with C++.
Another aspect is, many times I deal with proprietary APIs that have headers with all sorts of macros, bitfields and byte paddings. Having a direct C header import might also help with this case. Yes that API will still be ugly and less ergonomic but everything else would be nice. A bit like Futhark for Nim[0] or lcpp for LuaJIT[1] would really help to write more Odin.
Standard Library - I don't remember off the top of my head but I tried strconv procs a while ago to parse OBJ files and found that the floating point parsing to be slower than strtod. Maybe it's not the case anymore I'll give it a try again and open issues on Github for any feature requests.
Bitfields - In my line of work this is a must-have.
[0] - https://github.com/PMunch/futhark
[1] - https://github.com/m-schmoock/lcpp