I CI test and deploy on bare metal debian and fedora systems without issue. It just has less of those performance tuning things in comparison. Like socket structure reuse in the kernel. just because they have a totally different kernel model, which is partially why polling is highly used on Linux in comparison.

I think it's worth pointing out that technically C# and .NET are separate. Using ms tools generally target .NET.

You can use any ELF library, and even C# + .NET supports mixed managed C++ code as well. Meaning you can use a few pragmas and link against the .NET runtime library and now you can intermix C++ and C# classes without any Pinvoke overhead. I had been told that mono (an alterntaive to .NET) that can run C# actually supports calling native code without any pinvoke overhead, but it has too many shortcomings for my work that I haven't switched to mono. Pinvoke has gotten much more performant in that past releases.

So technically it supports rust or whatever supports dlopen();

Reply to this note

Please Login to reply.

Discussion

Downsides though, if you want to write aforementioned mixed C# and C++ code, it's not really documented well. Generally .NET wants you to use pinvoke instead.

May stick with Go and Java for now but sounds interesting.

I also like java, I just found tooling and C-ish syntax more appealing when starting out. Ring me up if you ever want to try some fun things out like breaking the GC guarantees with unmanaged code ;)

That is something I want to try in Go, actually. Possible but risky :)

Though I find the GC performance with Go isn’t getting in the way.

May want it for some large off-heap stuff.

visual studio build tools also supports mixed code debugging, so if you need to jump into a dll or read assembly as your debugging your managed code, you can step through it as long as debug symbols are available.