How do you propose to make exceptions work in the presence of large number of cooperating goroutines? As in, there's no implicit control flow the way you have it in "less-threaded" languages.
Go has exceptions already: panic and recover. These are equivalent to exceptions (formally so even, in that exceptions could be macro-expanded to panic and recover, and also the other way round).
I don't believe that's a problem; goroutines still have a stack, they just aren't always assigned to an OS thread. At least that's my understanding.
Go even has exceptions, it just doesn't usually use them.
Can you explain what you think the problem is with supporting exceptions?
You raise a good point though, in that there is a valid question of "how would you introduce exceptions into the language / runtime". I think the answer is that the err return value can become implicit. Throwing an exception is the equivalent of "return _, err". Invoking a function that can throw an exception is done by not checking the err return; if an exception is thrown/returned and not checked then it is immediately rethrown (return _,err) in an implicit method. try/catch should be easy to introduce, although the semantics of e.g. "defer" could be tricky.
> How do you propose to make exceptions work in the presence of large number of cooperating goroutines?
Exceptions propagate up the call stack within a goroutine, and then, if not recovered within the goroutine that raised them, crash the whole program.
(I cheated a bit -- that's how go already handles exceptions, which it calls "panics". The difference between go and, say, Java is that the core and standard library don't panic as much as Java's throws exceptions, leaving the decision to panic to user code more often.)
