I find the use of Go for the userland pretty cool. It makes sense in this case considering if you disable cgo the only external dependency you have is the Linux

I find the use of Go for the userland pretty cool. It makes sense in this case considering if you disable cgo the only external dependency you have is the Linux syscall table. I've implemented a number of system tools in Go and it is pretty well suited to this sort of job IMHO. One particular case that I've struggled with however, is when I've needed to modify some characteristic of my running thread using an OS mechanism. For instance, say I have a number of go-routines running and then I want to make sure a filesystem is unmounted from all mount namespaces the kernel has. My only pure-Go option right now, is to execute another go program (or re-execute the same program with some arguments) that will enter the namespace via syscall, do the work in that namespace and then quit. If you have a bunch of namespaces this seems wasteful. This is because you don't have complete control over what Go does with the OS-thread you are working in. Yes, you can lock your go-routine to a particular OS thread but you can't stop Go from using that somewhat special and potentially more privileged thread, to create other OS threads to service go-routines. Thereby potentially sprinkling your go-routines with different capabilities and/or namespaces. I ended up using cgo, which was a shame. Perhaps someone knows some neat trick to work around this?