-
libui
Simple and portable (but not inflexible) GUI library in C that uses the native GUI technologies of each platform it supports.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
tokio
A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...
There is absolutely no reason we can't have a very good lightweight native UI compatibility layer.
Look at this heroic effort by a single developer:
https://github.com/andlabs/libui
It's not there, but it's probably too big of a project for one person.
Check out Cosmopolitan which vendors all its dependencies. https://github.com/jart/cosmopolitan You can't use Node with it, yet, but you can use QuickJS if you `make o//third_party/quickjs/qjs.com` and `o/third_party/quickjs/qjs.com -m third_party/quickjs/repl.js`. Cosmopolitan goes so far with vendoring dependencies that it actually has its own C library implementation that prevents functions like socket(), connect(), and getaddrinfo() from talking to the Internet if the software is running under GNU Make. Since sometimes we've found when porting software it'll have unit tests that do sneak leaks to public servers. It goes without saying that in order to make it even possible to vendor all dependencies, down to the binary level, there's a very long list of topologically ordered things that need to happen before you can even talk to the Internet. https://github.com/jart/cosmopolitan/blob/50937be7524197f23a...
Multiple event loop integration is one of things projects get to very late in their lifecycle, if they ever get to it at all. Tokio is no exception: https://github.com/tokio-rs/tokio/issues/2443
When I used to write more networking C code, I used to be careful to write my libraries to be event loop agnostic. And if my library had its own event loop, I made sure that it could be stepped independently so it could sit atop another application event loop. This is alot easier on modern Unix systems because kqueue and epoll can be stacked--you can poll a kqueue/epoll descriptor from another kqueue/epoll descriptor, so sockets, timers, etc registered with the first will bubble up to parent and your library-specific event loop can just export a single file descriptor to be polled by another event loop. Windows doesn't have such a capability so there's no simple way to bubble events up.
Of course, you can run your different event loops in different threads, but then you have to deal with the nightmare of shared data multithreading. Rust makes multi-threading "fearless" because it heavily restricts multiple threads from holding references to the same object, so Rust doesn't help in this regard, especially considering you're integrating with non-Rust code and, worst of all, GUI APIs, which tend to be some of the most inscrutable and hostile code to integrate with.