Hacker News Reader

Comment by enneff | Hacker News Reader

The reason we didn't include exceptions in Go is not because of expense. It's because exceptions thread an invisible second control flow through your programs making them less readable and harder to reason about.

In Go the code does what it says. The error is handled or it is not. You may find Go's error handling verbose, but a lot of programmers find this a great relief.

In short, we didn't include exceptions because we don't need them. Why add all that complexity for such contentious gains?

View on HN

I'm with the grandparent. Every language that I've used that was created after C has included exceptions, and never once have I missed checking errno.

I can understand why, coming from a C++ context, you'd want to avoid them like the plague, but other languages (Python, Java, Smalltalk, ...) do a good job of making them a first-class citizen in the language, which saves a LOT of boilerplate typing. Seeing call stacks implementing a half-assed exception catching mechanism makes me sad. (Okay, Java only gets half credit here, since its checked exceptions inflict a different kind of boilerplate, but my larger point remains.)

Lack of exceptions is half the reason I'm not interested in writing Go code yet. The other half is that anything that seriously intends to replace C++ does need an escape hatch to allow manual memory management for when the GC's one-size-fits-all approach is simply a poor fit. For a language whose goal was explicitly to replace C++, this is an odd place to be tone deaf. I'm disappointed to see an attitude of "haha stupid C++ programmers don't understand that programmer efficiency is more important than CPU efficiency," instead of realizing that there are valid use cases where you do need to care about this and addressing them.

Which is unfortunate.

Did you miss the part where he says: "We weren't trying to design a better C++, or even a better C. It was to be a better language overall for the kind of software we cared about."

You're missing the forest for the trees. The topic of the article is about how good was motivated by creating a better language for systems software than C++, and hypothesizing why it's nevertheless getting more traction with the scripting crowd than C++ programmers.

"We—Ken, Robert and myself—were C++ programmers when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote. It seems almost paradoxical that other C++ programmers don't seem to care."

> In Go the code does what it says. The error is handled or it is not. You may find Go's error handling verbose, but a lot of programmers find this a great relief.

I'm sorry but you are on the wrong side of history on this question (and I happen to think you're also wrong in your characterization of exceptions).

Forcing callers to deal with error numbers right here right now only gives you the illusion of clarity and robustness but it gives you neither.

Every Go program I read is littered with "err,ok := Foo(); if err {}" every ten lines or so. It's brutally verbose and hides the intent of the code.

And it also forces callers to handle error codes that they might not be able to, while a caller a few stack frames above would do a much better job at it.

We learned all these lessons in the 90's, pity Go chose to ignore them.

I just want to point out that just because go lacks a good way of handling error conditions, doesn't mean exceptions are the best way. Haskell has exceptions, and I wish it didn't. Because it has better options for dealing with error conditions, like Maybe and Either. If you are checking for an error condition every ten lines, those are by far nicer than using exceptions.

> In short, we didn't include exceptions because we don't need them.

I would say that not only I don't need exceptions, I absolutely don't want them.

A really annoying thing about languages with exceptions is how they contaminate code, exceptions are (often hidden and badly documented) part of the interface of libraries and packages which you have to deal with when you least expect it.

> harder to reason about.

I hear this from Rich Hickey about Clojure all the time. I'm certainly not at the brain-power level to fully absorb all the implications of that phrase, but I'm starting to "get it". I think this is probably one of the most compelling things to strive for in a medium that is used to "make stuff", like a programming language.

Reply on news.ycombinator.com