It bears noting that the native Nim FFI is very "thin" & easy. E.g., at least for code anticipated to be compiled by the C backend, you can just declare the C function as a Nim proc (EDITTED to look nicer on mobile):
c2nim is more helpful for larger C APIs with a lot of C structs and a wide set of entrypoints/API calls. For simple enough C code it can be used as a "starting point" to port the whole thing, but you will probably at least want to change things like a1, a2, etc. parameter names ("a" for "argument"). Nim has named arguments (like Python, f(x=2)) so such names are a bit more important. (Not that all code meant to be read by a human should not have good param names.)
Cool project. One of the best decisions we made for C2Rust was to use clang to parse C code (which is also the recommended approach by the author of Corrode). It looks like C2nim is rolling its own C parser for now; that's eventually going to become a limitation as the project expands to cover more of C.
I predict Clang in 10 years will be like Google today compared to Google 10 years ago: a bloated goliath that nobody likes any more but for which there aren't any alternatives.
One problem is parsing C inevitably means parsing headers, which often means parsing system headers, and they tend to be full of non-standard C weirdness (and have new things added all the time) which in practice are often understood by clang and gcc and not a lot else.
While what you say is true, it's impact need not be so prohibitive as to box you in to clang/gcc. TinyCC/tcc [1] parses almost all C99 with a 3900 line tccpp.c and 8000 line tccgen.c.
As long as extensions are careful to stay "syntactically isolated", the complexity of parsing C need not explode.
E.g., at least on Linux where glibc headers are very gcc-tilted, the only extension tcc really needs is that __attribute__(()) stuff (maybe 1 or 2 other "just ignore this stuff" things).
While there can always be edge cases that are broken, I use tcc daily on Linux without issue. So, I would encourage people to not view C as an untamable complexity monster or be captive to prevailing implementations. { C++ is, of course, a more unfortunate story in this and so many other regards :-) }
Linux is a bit of a special case, unfortunately on other operating systems system headers must not be written in standard C or in C at all (e.g. Objective-C on macOS, or Windows SDK headers requiring Microsoft-specific extensions or even a C++ compiler).
I did use TinyC/tcc successfully on Windows a few times without any header problems, but it was very admittedly a far less rigorous test and may well have not touched any headers with MS-specific extensions. I never tried it on MacOS, though it would be unsurprising if that NeXT/Mach-O derived object format were unsupported.
Anyway, the world of C extensions has mostly seemed syntactically judicious/surgical. That's more just cultural, not guaranteed by anything, but it makes me suggest (without knowing) that MS extensions would probably not be hard to support without complexity explosion. Apple, on the other hand, doing their own chips now and Swift and just generally being even more of a closed system..They seem most likely to make that hard someday if they ever think they can make more money by not supporting POSIX-like programs. :-( { EDIT - there will likely always be some demand for/a way to create C callable wrappers/headers for system services, though. So, I don't think that it's crazy to hold out hope that this will remain possible/not too bad for the foreseeable future. }
They already hardly support POSIX-like programs on iOS and watchOS.
In what concerns macOS, UNIX certification is anyway only for CLI applications and daemons like software, stuff like graphics isn't part of UNIX trademark.
Fair enough. They surely don't support tcc directly anyway. So, what I really meant was "informal hacker community support" (probably on jail broken/rooted devices when/where applicable!), not "official company support" and I didn't mean to suggest zero work would be involved..Just not a complexity explosion like C++.
I see moving away from C as fortunely, and if it wasn't for uprising of Linux based FOSS, we would be much further down that line, given how all desktop stacks were focusing on C++ during the late 90s.
Rust will have Rust/WinRT on Windows, Nim can also go down that path for example.
I don't believe so. Just incremental improvements, no breakthrough. As for HN popularity, that is often a matter of chance. If a submission gets a few early upvotes and makes it to frontpage, it snowballs from there, often regardless of anything particularly noteworthy.
Header-only is more applicable since you often only need declarations/Nim prototypes and a passL/C linkage to C libs where the C generated by Nim just calls into the C library.
But if you wanted to port C to a "pure Nim" for whatever reasons (e.g. to also work at compile-time in the Nim VM or the Javascript backend) c2nim also works and can help. It may not work so well on fancier code, e.g. using a lot of cpp macros, etc. That tends to turn up more in .c files than .h files, but the boundary is obviously somewhat arbitrary.
