> If this is what you're referring to, this is just a return value. There isn't really an exception system here.
Yes, which is awesome.
> If you think about how return values work in C you'll note that it's usually some subset of the range which is defined for an actual value and some subset defined for an error condition.
This would be an 'in-band' error, as opposed to 'out-of-band.' It's terminology borrowed from communications theory. You also see it used to describe an 'out-of-band' console that is a secondary way to SSH into your machine if your network is hosed.
> Also, I didn't mean that Go should have innovated in PLT, only took advantage of innovations already established.
I think the point is that this is intentional. I love super high-level languages, but they're experimental for a reason -- things haven't 'settled down yet' and until they do, it will be difficult for the average person to reason about what is going on. Take garbage collection: this was technology that had been around for decades, but computers and garbage collection algorithms had to be sped up and tuned before general adoption. Large systems demand predictability and integrity on nearly every dimension. Luckily as time goes on, the experimental stuff becomes the expected; advanced programming language theory gets built into larger systems and we all benefit. Go is part of that evolution.
I think the point is that this is intentional. I love super high-level languages, but they're experimental for a reason -- things haven't 'settled down yet' and until they do, it will be difficult for the average person to reason about what is going on.
No, sorry, I should have been even more explicit: it looks like the designers were not even aware of new advances in PLT. As far as I can see, defer/panic/recover is objectively worse than an exception system for all of the goals which they lay out in their paper.
You like return values--ok, I can see that. I prefer that the type checker actually enforce error checking when using error return values, but fine.
Adding defer/panic/recover is an attempt to add a simpler and more constrained exception-like system to the language, but I think it is objectively (both from a PLT perspective and compiler-design perspective) worse than a more traditional exception system. Breaking beta-reduction is very unfortunate and I can't see a good reason to do it in this case.
Yes, which is awesome.
> If you think about how return values work in C you'll note that it's usually some subset of the range which is defined for an actual value and some subset defined for an error condition.
This would be an 'in-band' error, as opposed to 'out-of-band.' It's terminology borrowed from communications theory. You also see it used to describe an 'out-of-band' console that is a secondary way to SSH into your machine if your network is hosed.
> Also, I didn't mean that Go should have innovated in PLT, only took advantage of innovations already established.
I think the point is that this is intentional. I love super high-level languages, but they're experimental for a reason -- things haven't 'settled down yet' and until they do, it will be difficult for the average person to reason about what is going on. Take garbage collection: this was technology that had been around for decades, but computers and garbage collection algorithms had to be sped up and tuned before general adoption. Large systems demand predictability and integrity on nearly every dimension. Luckily as time goes on, the experimental stuff becomes the expected; advanced programming language theory gets built into larger systems and we all benefit. Go is part of that evolution.