> Not really. May be true for tiny C libs with a very simple API. But for > larger C libs I would prefer writing my whole app in C than in Nim using a > low level wrapper. I tried -- wrote my Ned editor six years ago with the > oldGTK3 low level wrapper. Was much uglier, more error prone and more work > than writing all in plain C. I guess for low level Nim wrappers for Qt or > CGAL it would be the same. Even for smaller libs like cairo or blend2d only a > low level wrapper is nearly useless.
I have multiple times written Nim programs with low-level C wrappers. And I agree that for more complex libraries it isn't much better than C. But saying that it's worse is a bit of a stretch. The only downside of using Nim with a properly written low-level wrapper is that you probably have to do a lot of casting between different types which C sees as equal. That being said I find that with a couple of well written templates you can get a lot of work done even with simple wrappers and Nim. As for how error prone it is I don't think it's necessarily any worse than C, but you might get lured into a false sense of security when writing Nim and forget to handle your memory allocations properly. All of this assumes properly written wrappers though. As soon as you have a mismatch between the C types and the Nim types in the wrapper all sorts of errors crop up. > Wrapping C code is best done in two phases: one that expresses the C ABI in > Nim terms - pretty much, this is what a header file does in C - you simply > replace your .h file with a .nim file and change the syntax, adding > appropriate Nim annotations like bycopy and so on. After this stage, the C > header file is no longer needed, but should correspond 1:1 to the Nim file. I whole-heartedly agree, and Futhark aims to automate the first phase. It allows you to import the .h files directly and then focus on writing the high-level wrapper instead. > I find nimterop to work better mainly because it has a much better C parser > than c2nim, while it still knows about Nim quirks. The best feature it has it > that it outputs a Nim file that you can further fine-tune. I haven't been able to get nimterop to work sufficiently well for my purposes, which is why I wrote Futhark. It aims to do much the same thing, and will also spit out a Nim file that can be further modified (although I don't recommend this, you should rather use the retyping functionality, or the object override functionality to create better representations if you have something that mismatches). > The final point is that just like you might accidentally mismatch C headers > and the compiled libraries they reference This is the main reason for the automatic wrapping. It is all well and good to take the output from nimterop or c2nim and fine tune it to your needs, but as soon as someone shows up with a newer version it all breaks down. With Futhark it will automatically rebuild the correct definitions and the high-level wrapper can still work just fine as long as nothing has been majorly restructured. > Love the naming: futhark (runic alphabet) and opir (rune master). Thanks, I felt pretty clever when I came up with that name :) > Well I have used c2nim successfully, on thousand of lines of C++ code. I haven't. I have tried time and time again to use c2nim, and later nimterop, without any luck. Last time I tried I spent days fiddling with .h files and felt I was slowly inching my way closer to something that could maybe, possibly work (although how would I know, I had changed a lot of the .h files, so I might've messed up at some point). I got a lot of help on IRC as well, but as this was meant to be used for a project at work and I really wanted to show how well suited Nim was for this task I ended up writing the definitions manually instead. This has been working well for me since then, but every time the underlying library changes I have to go over all the structures again, or just try to run the software and hope it doesn't randomly SEGFAULT. The latter scenario has happened more than once already.. Futhark was written out of frustration. Frustration with what I saw as a gaping hole in the Nim ecosystem. Nim is great, and it's C interop is top-notch, but the inability to easily and automatically get up-to-date information from C libraries have meant that you either have to spend a lot of time writing wrappers by hand, or hope that someone has already sunken this time cost for you (and published it, my work project wrappings are still not publicly available). As many here has pointed out using a C library directly in Nim might not be very pleasant or ergonomic, and it might be prone to errors. But by taking human error-prone labour out of the equation it is much more likely to provide a good result. As I mentioned I have used many wrappers for C libraries that have either not been tested properly (who has time to test all the different edge-case functions of a C library?) or which has simply been outdated, either by changes to the C sources, or by changes to the Nim language. All these scenarios require manual work to fix, manual work that isn't necessary with Futhark. To put it this way, after spending about as much time writing Futhark as I used trying (and failing) to get c2nim and nimterop to work on wrapping the C sources I needed I replaced my 300 lines of manually written labour intensive wrappers that I spent a couple days writing and more time than I care to admit on maintaining (and they still only covered just what I needed to move on with the project) with about 10 lines of Futhark statements telling it which header files I wanted, what defines I required, and the extra type-safe re-definitions I had applied. It is now able to seamlessly work across versions of the original source without breaking, and I can finally but to rest the tiny voice in the back of my mind telling me that they might be wrong. So to sum up, I wrote Futhark because none of the other solutions have worked for me. It is still not perfect, but I hope that it will be soon. It allows me to just import C and not have to think about it at all if I don't want to. Had the other tools worked I wouldn't have had to do it, and I hope that new and better Nim wrappers will come from it.
