Would you be ok sharing more details how you combine both? I’ve been experimenting with this for a personal project, but integrating zig in a .NET solution has been fairly messy. Would love to read others experiences doing so successfully
I should be more precise, I don't use them in same project. I am C# professional but using Zig for simple embedded programing projects and some tools that don't have requirment for complex runtime. If I would have to glue them together then I would probably compile Zig to webassembly component and use it in C# hosted env.
Using wasm for this sounds like a difficult and wasteful approach.
Is there a reason you are avoiding a simple compilation of Zig part of codebase into a dynamically or statically linked library and calling into it with P/Invoke? You only need a `Target` and maybe `None Include=...` items in .csproj to instrument MSBuild to hook the building process of Zig into dotnet build and co.
Yes, P/Invoke should work, especially when you are targeting a single platform. However, for multiple platforms, there might be some unexpected obstacles I am not aware of.
The answer to this is to map the RID to the argument passed to Zig. Or just build on a target platform as an alternative, if possible. WASM is not a solution and would not work properly. It is the last resort effort in language with inferior interop capabilities.
I'm just putting a disclaimer that using WASM is a very wrong kind of suggestion, would likely not work the way you expect it to (you would have to use WASM for .NET too which is in many places experimental and is a huge performance killer) and no one does it - there are appropriate ways to target multiple platforms in a solution that splits logic between .NET and C/C++/Rust/Zig/Swift/etc., especially that Zig offers nice cross-compilation toolchain. Mind you, the use case for this is accessing language-specific libraries and for performance the solution really is writing faster C# instead.
It depends on the integration use case. For example, if I were writing a plugin system for my C# app, safety would take precedence over performance, and using WASM modules would make more sense. If I had some performance-critical code in Zig, then P/Invoke would be the way to go. However, in most cases, it's better to avoid P/Invoke, as C# is already a very performant language.
IMHO the advantage of zig isn’t performance but generating a minimal library that exports C headers, making it simple to integrate in any language. My use case is a custom document editor in zig, with a “bring your own renderer” approach”. It integrates in a C# desktop app, as a base for something like a modern RichEditBox (just in spirit - not RTF based, with way more advanced features).
I want the editor to be usable in other GUI stacks, a C-compatible library is the only approach that makes sense here
How it will work if you don't know target platforms in advance? Will you compile zig module for every possible native target you know? Is sorce code public or only compiled library? WASM is universal solution, compile once run it everywhere. There is a reson why Microsoft Flight Simultor choosed WASM modules for plugin system.
Yeah, that’s what I personally do but maintaining the PInvoke interface during development adds a good amount of overhead as things are changing around. It’s also a lot of boilerplate to deal with, and you only notice at runtime that something is wrong. It doesn’t feel like a well integrated solution
I strongly caution against WASM suggestions in a sibling comment - I’m not even sure if the author has actually done any C# at all, given how ridiculous it is.
Awesome, thanks for the link, that’s really useful!
WASM is definitely a strange suggestion here, I didn’t take it seriously. I’m already using a C-compatible zig library approach. Some details of the use case here:
https://news.ycombinator.com/item?id=41729059
Heh, I've been procrastinating on making a blog and writing a blog post on "C# for systems programming". Would be nice to read and provide feedback if someone beats me to it.
There was a port of the .NET Nano Framework for RP2040.
But I think the more interesting thing is that if you remove all features in C# that require heap allocations, the resulting subset is basically C with namespaces and generics, which is still useful, and certainly possible to compile efficiently even for very constrained platforms.
C# is quite a bit more than just enhanced C if you remove GC-reliant features as the generics and interface constraints enable a huge subset of features, alongside SIMD API, stack-allocated buffers and all sorts of memory wrappable in Span<T>s, which almost every method in the standard library that works on some sort of buffer accepts nowadays instead of plain arrays.
You can also manually allocate objects - there are multiple ways to go about it and even with the presence of GC, there is a "hidden" but supported API to register a NonGC heap that GC understands when scanning object references.
Though effective targeting is limited to much fewer count of platforms. Mono can target as low as ARMv6 but CoreCLR/NativeAOT mainly work with x86, x86_64, ARM and ARM64. For microcontrollers you are better off using Rust in my opinion. But for anything bigger .NET can be a surprisingly capable choice.
