How so? The likely reason is that a C lib is usable from many other environments. Look at ncurses for example. Heavily used from many languages, and written in C.
Another reason is that the underlying tools used by this library are likely in C as well, so it's probably the easiest language to use for the task.
C is easy to package and distribute. I once built a Python + GTK application for a school project. On Ubuntu that was no problem at all, but on Windows it was a complete mess because I had to bundle Python + GTK for Windows + all their dependencies. I think the result was around 200 MB of dependencies and ~100 kB of actual Python code. C + libui would have been much better in this regard.
It's odd to see you saying this, given your security focus. But I suppose implicitly you're referring to UI apps that don't expose remote attack surface.
Anyhow, I used to be the same way (perhaps surprisingly given what I work on now), but I stopped once I realized that it just takes so long to do basic things in C compared to other languages. The downside of slow compilation, for example, pales in comparison to the downside of it taking a lot more code to do basic things like string manipulation.
I'd also mention that, on Windows, C has big dependencies as well (msvcrt), unless you cheat like MinGW does and use the unsupported system msvcrt.
> It's odd to see you saying this, given your security focus. But I suppose implicitly you're referring to UI apps that don't expose remote attack surface.
I'm really quite conflicted here. I've written in the past that it can even be seen as irresponsible to write new security-sensitive programs in C/C++ when there are reasonable alternatives available, which is most of the time - and "security-sensitive" can include almost anything, given the right scenario. On the other hand, while I'm a big fan of Rust and use it for some personal projects, some things about it drive me crazy, while C's low-level nature appeals to me, so I also like to use C. I can justify this contradiction to myself easily enough, because I don't write all that much code that other people actually use, but that's something I'd like to change... :( In any case, I'm looking forward to quality-of-life improvements in Rust such as incremental compilation, which should tilt the balance more onto its side.
I'd consider it for a hobby project, or for adding a GUI to a C program without introducing many extra dependencies. Judging from the comments though, most of the people interested in this library aren't interested in writing a C GUI app at all, and I suspect that's your real answer.
The FFI reasonings are OK, I understand them. I didn't think in those terms originally. (Thought I asked about writing a C app not a C library...)
But speed and C are othogonal nowadays (at least if productivity is in the picture). It is so much simpler to write correct programs leveraging multicore environments an/or asynchronity in other environments, that it is not productive to chose C for speed. (In terms of development costs. Ofc. there are special cases when it might be worth, I'm talking about the general situation)
Another reason is that the underlying tools used by this library are likely in C as well, so it's probably the easiest language to use for the task.