I think at the end of the day it was about forcing CSP-style concurrency on the majority of Google services. You can make a pretty good argument that CS programs don't do a great job at teaching multithreaded programming (even though it's pretty dang straightforward on the JVM and CLR). Race conditions are often painful to track down. Exceptions are also tough to get right, and many services require several hardening updates because of missing catch blocks or overly thoughtless "catch and log" behavior. Multi-return, despite the verbosity, may be a win on the operations side here.
Like you, I wish Google was more ambitious with their language design though. Honestly I'd rather stick to the JVM, especially with Virtual Threads now in preview.
Re:The Problem with Go
by zozbot234 on Wednesday November 02, 2022 @04:59PM
(#33442837)
Go does not force CSP-style concurrency. There's a lot of Go code that uses shared memory with concurrent tasks, even leading to possibe data races and violations of memory safety. (In fact, purely sequential Go is memory safe.)
Like you, I wish Google was more ambitious with their language design though. Honestly I'd rather stick to the JVM, especially with Virtual Threads now in preview.