It's a weird one. The fact that callbacks in Go may be on a different thread means it's so damn easy to use a variable reference from an outer scope within in

It's a weird one. The fact that callbacks in Go may be on a different thread means it's so damn easy to use a variable reference from an outer scope within in a callback. This increases the chances that someone inadvertently causes a race condition. Something that requires additional awareness and screening during code reviews. This by itself isn't an indictment of the language as threading is essential to quality GUI applications and as such Go is a great language for writing client applications - which it is largely not used for. You really need to evaluate the value the overhead Go's thread management brings when used in the context of web servers - where we typically split processes up using container orchestration, making them functionally threaded any way. Comparatively, TypeScript running on Node or Deno is single threaded yet asynchronous. Using it as a web server means you have a better type system which follows a similar structural typing model to go (interfaces and such) and you don't have to screen for race conditions. In K8 or ECS, you spawn as many processes as you have CPUs and Bob's your unkle. Personally, I would love it if Go focused on GUI application development but I can _bearally_ write GTK apps with it. Windows and MacOS applications are near-to or impossible to write. Don't even talk to me about Web Assembly. Such a missed opportunity.