Hi there.
Many Nim libraries I've seen, tend to be very thin bindings to C libraries.
My problem there is that - it's left up to the programmer to check that return values don't indicate error - eg not a -1 value (according to original API), and various other shoot-yourself-in-the-foot things you can do easily with C libraries.
Coming from Python, I'm really happy there that the bindings/libs there usually have very comprehensive error checking when crossing the C ABI layer, in both directions.
Basically that would mean having something like a "safe" layer (eg: SDL2_safe lib, that wraps SDL2 C bindings for instance), where there's a lot of defensive programming before and after the C library call, that the library does for you (and raises exceptions), so your app code doesn't need to.
But that doesn't seem to be idiomatic Nim style (?).
More or less, while coding in Nim - if you want to code carefully, you'd still need to keep the corresponding C API docs open - and then be cross-referencing the Nim-idiomatic library names, against their original C names, to be able to code in a more safe way.
Obviously there would be something like a performance cost there, and also a lot of work to add "safe" wrapper libraries over "unsafe" C code. Though, could also be designed to be compiled out in release mode.
If you're coding in C or C++, or many other languages, the exact same thing applies, too.
But it does make me a bit uncomfortable as a primarily Python coder (not coming to Nim originally from C or C++).
Is this kind of thing a design decision/trade-off - eg Nim is designed to be a very powerful programming language, with efficiency and expressiveness in mind, but safety is not a high priority?
For this level of OCD - where safety or correctness is valued above efficiency or expressivity - would a different programming language be more appropriate? (Haskell, Ada and Rust come to mind as the most obvious examples).
Or is there some demand or need for safer coding in Nim? eg: If there were an SDL2_safe wrapper for SDL2 C bindings, then a lot of people in the Nim community would prefer to use that instead (?). eg - a lot of people seem to want pointers to be "not nil" by default.
This is the same situation of early Scala, where many libraries where just adapted from Java.
Ideally, one would want something idiomatic and easy to use, but it takes a while. For a concrete example, the linalg library wraps BLAS under the hood. In fact, I am about to move the BLAS bindings under a separate library. This part is easy to generate, and most of the work lies in improving user friendliness and making things more idiomatic, making use of gc pointers and so on.
So, do not worry. If you see many C-like libraries it is because this is the easiest thing to do first, and allows rapid access to a wide range of libraries. Over time, these will become more and more wrapped in friendlier interfaces