3 ms·

I don't think the original Go authors ever truly thought that exceptions are "bad" per se. I think they just took it off the table because of the complexity it

I don't think the original Go authors ever truly thought that exceptions are "bad" per se. I think they just took it off the table because of the complexity it added to the language, both conceptually and implementation wise. A (the?) primary main goal of Go from the beginning has always been to make implementation as obvious as possible; in other words, to make it a slightly thicker layer on top of assembly than C was (they seemed to like Java 1's idea of interfaces), while still keeping in mind that it will map to assembly. The language's design is inherently tied to its compilation model. And to add exceptions would add complexity to it which for some reason they considered to be "too much". Same story with generics fwiw.

johncolanduoni 10y ago
To whom is the implementation of a generational, concurrent GC obvious? It requires a lot of compiler infrastructure and complex runtime support, much more than stack unwinding. I'm not a fan of, say C#'s, exception model, but it's far from the complexity of features Go already has in either implementation or programmer understanding. On top of that, unwinding isn't the only way to get something where errors have to be handled or the program dies. Look at Swift's error handling for example: it's basically sugar over returned errors with correctness checks. Dead simple implementation, and dead simple to explain to users. What I don't buy about the justifications for Go's design is that they were driven by the pure guiding hand of simplicity. It looks more to me like the designers simply treated language features they had seen done badly before as anathema and didn't try to think about how the mistakes could be corrected.