Embedded systems benefit substantially from decreased GC, especially in the context of non-relocating collectors (as with Go) in machines without memory management units. The problem is not the overhead, it is the effect of memory fragmentation.

The OP article here is nice because it allows selective enforcement of allocation free code. If you have code that has some discipline about heap allocation such as having all small allocations then you are OK on the fragmentation front.

I worked on a project with a network server written in Go with soft realtime requirements. In theory Go should be very good fit for it especially given GC tuning towards low latency, not throughoutput. In practice the latency spikes from GC were bad and there were no good options to resolve those given the deployment constrains and the amount of third-party libraries used.

This is a viable approach for many scenarios. Uniffi is a tool/library from Mozilla that makes this a lot easier across platforms.

After a few rounds of this though it might end up seeming like it's not worth the hassle and it's easier to build the whole application in Rust.

I agree. If the use-case requires no GC then Rust or Zig or C++ is a better fit.

I don't see much point in choosing a language just to bypass it's features.

Go really sucks at calling into C code.