-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
zig
General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
-
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.
The thing that most provoked me to wonder about this was finding this project: Zig Error-ABI. It is designed to turn errors into hash codes so that they can be passed across the ABI boundary. As a Zig library, this only seems to make sense if there is Zig on both sides of the ABI boundary. It is counterintuitive that this should ever have reason to happen.
The related issues (so far and to my knowledge) are - https://github.com/ziglang/zig/issues/3786 - https://github.com/ziglang/zig/issues/10156 - https://github.com/ziglang/zig/issues/10558
Since you're familiar with C and Zig, you might be interested to know about the D Langauge approach which is somewhere in between. When you import a file in D, it does not mean "include it's code in the compilation" like it would in Zig (unless you supply the '-i' argument to the compiler, I added that here https://github.com/dlang/dmd/pull/7099). Instead, when it imports a module it will parse the file but only look at interfaces (i.e. types, constants, function signatures, etc). By convention if this module comes from a library, then it would have been compiled beforehand and the source code is used to like a C header file.
You do not need pre-compiled libraries for generated code. As an example, see zig-wayland, which generates code based on the Wayland protocol XML files during a build-step.