> Well the "editing" consists to 99% of "removing junk that won't result in Nim > code anyway" so there is hardly any "error risks" involved.
This is fairly naïve. Sure if you're proficient in C and Nim then maybe you'd have a fairly good grasp of what can be removed without any issues. But hiding behind layers of macros might be a calling convention attribute which suddenly means that your able to build it on your machine, but a different machine defaults to the wrong calling convention and now you have subtle bugs. Just an example of course, but I'm pretty confident in saying that a C compiler is better at reading C code than any of us. > In the same time period I wrapped most of wxWidgets which is C++, not C, with > c2nim back in the day. Different people have different experiences. I'm > biased but I've seen plenty of people using c2nim successfully, not just me. I honestly have no idea how you managed to do this. Every time I've tried using c2nim I've struggled for ages and never gotten anywhere. Doesn't help that there are very little docs on how to use it I guess. And as I'm chipping away at one error after another I have no idea if it will start working after the next one or if I'm 10000 changes away from a working wrapper. With Futhark I've been able to use a complex library like Gtk with WebKit2 support (which none of the existing wrappers had) in a matter of minutes. And when I needed to use the JavaScriptCore library as well it was literally adding three lines of code and it just worked. > I think tools like Futhark might be doing more harm than good for Nim's > ecosystem. The same is true for c2nim. [...] This is an interesting point, and I don't necessarily disagree. Of course Nim has the speed of C and since it compiles to C it feels like a strange restriction to have to force every library to convert things to Nim types. It would also mean a substantial performance loss which isn't as apparent when you're working with Python. Besides, I write Nim code because I enjoy writing Nim code more than I enjoy writing C code. This is of course an argument with no technical merit, but as @elcritch points out I'd much rather spend my time building a Nim API on top of a C library _in Nim_ than having to build it in C. Futhark focuses on simply wrapping a library as directly as possible, and then you as the library owner should build the Nim API abstractions on top of this. This is what I did with libCoap and I probably wouldn't have had any energy left to build the async API and automatic destructors if Futhark hadn't built a complete wrapper for me instantly before I even started looking at the API. With enough contributors and man hours I'm sure it would be possible to hand-craft the most exquisite wrappers. But Futhark isn't the antithesis to this, but rather a tool to skip the painful step of just getting a C library to work in Nim.
