Any program with a lot of concurrent stuff going on, like a multi user server.

No, it'll remain that way. It was a deliberate design decision, and it does make the code pretty verbose. I actually like the effect it has on the code I write though. When I was forced to deal with all potential errors, or rather at least think about them, it made my code more robust. Before Go, I would think "this is never going to fail, and if it does, it'll all just crash anyway" way too often.

It's probably compounded by the type of programs I use Go for. They tend to be important, very long running programs with many things going on at once, where strange errors have a much larger chance of occurring, and where the effect of a crash would be serious. Generic exception handling wouldn't cut it, and if I had to catch all individual exceptions and write specific error handling for them, I would end up with worse code than the Go alternative.

Go is definitely not for every project though. At least not for me.

Go. It got me back into systems programming, and renewed my interest in C as well.

That's a good, but disturbing point. Not to mention, there are plenty of managed languages out there that might copy the data around too.

Is there even a way to deal with this without having the kernel get involved at program exit?