[superfist]

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.

[neonsunset]

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.

[superfist]

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.

[neonsunset]

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.

[superfist]

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.

[dgellow]

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

[superfist]

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.

[dgellow]

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

[neonsunset]

If Zig can export C headers, you can easily generate the bindings out of them with CLangSharpPInvokeGenerator.

https://github.com/dotnet/ClangSharp

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.

[dgellow]

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

[superfist]

What is ridiculous in it?