yeah, manual freeing of memory and being able to access kernel threads are probably the two biggest pain points for me with Go. the first is needed to eliminate spikes in memory utilization, the second is for background scheduling of bulk processing (eg, PoW mining nostr notes or converting media formats, etc).

when it comes to UI dev with Go, i also have done a lot of work with Gio and it was quite challenging to design a scheme that efficiently leveraged the CSP concurrency, without putting too much compute in the render threads on that single mandatory thread. but i did it - the framework i was building had a mechanism for scheduling background tasks with a simple queue (just passing a closure by a channel) which let me push all the compute into that and leave the render code to focus on the rendering and give it little slots of memory (hey, they didn't have to be atomic, because one thread) to render from, and the moment a signal comes back from a background thread or external resource it starts rendering that data.

yeah, for graphics rendering/compute, for bulk processing of any kind, the ability to manually create CPU threads is probably the other thing really missing from the language, other than being able to manually free memory.

there's a few other spots here and there where it could be a bit better but it's ok, those two points are just the main tangibles for me.