7 ms·

I really thought they were going to allow their idealism to win over pragmatism. Versioned modules, generics and exception handlers all going in is really going

I really thought they were going to allow their idealism to win over pragmatism. Versioned modules, generics and exception handlers all going in is really going to put the defenders of them being missing in a tough spot.

the_duke 8y ago
Edit: To clarify, the handle() system does indeed resemble an exception propagation system and is also the part I like least. Just "check" would be preferable, with an implicit handler of "if err != nil { return err }" Although I still would prefer something leaner like the "?" operator from Rust.
- quotemstr 8y ago
  > The draft design introduces two new syntactic forms. First, it introduces a checked expression check f(x, y, z) or check err, marking an explicit error check. Second, it introduces a handle statement defining an error handler. When an error check fails, it transfers control to the innermost handler, which transfers control to the next handler above it, and so on, until a handler executes a return statement. Sure. It's explicit error handling that just so happens to look exactly like a form of exception handling, c.f., the zero-overhead exceptions proposal in C++land. This is how you say, in language-design-ese, "I want to do what my critics have been saying for years is the right thing without admitting that they've been right all along".
  - heavenlyhash 8y ago
    I really don't know where people get on this high horse and imagine that there's been some kind of fighting attitude here. I saw a talk by James Gosling (of Java fame) a few months ago in which he said one of the most important things he's glad he did throughout the development of the language is "Decide... not to decide". The purpose of this "deciding not to decide" should sound familiar by now: once you commit to something, it's hard to backtrack. And once it's hard to backtrack, you have lost your ability to look for more optimal solutions than the one you've fixated on. This is why generics in Java took so long. And to this day, the developers of those generics do not regret taking their time to do so. I think that's interesting to note, don't you? It's okay to make decisions after deliberation. Deliberation does not imply a fight. --- Tone police aside, did you... read... the proposals? I don't think it's correct to dismissively say that the proposed handle/check syntax is identical to other checked exception syntaxes; it doesn't compose in the same way as traditional try-catch blocks; and it doesn't have the power to create arbitrary longjumps across multiple stack frames as exceptions do. In short, it's very little like traditional exceptions at all.
    - pjmlp 8y ago
      Actually they do, hence the ongoing work to add value types and reified generics to Java, which is again a multi-year project with no defined end date.
      - heavenlyhash 8y ago
        Sure, but just like there's a difference between "deliberation" and "a fight", there's also a difference between "hmm, there's more to do" and "we regret the thinking we invested so far".
  - rsc 8y ago
    If you are interested in learning why check-handle differs from traditional exception handling, you can read https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf.... If you just feel like snarking, then sorry for spoiling.
    - erik_seaberg 8y ago
      It looks like the only difference is that catch blocks precede try blocks and aren't indented to show how they nest. One could mechanically convert handle err { cleanup1() return 42, nil } handle err { cleanup2() } check dostuff() into try { try { dostuff(); } catch (Exception e) { cleanup2(); throw e; } } catch (Exception e) { cleanup1(); return 42; }
      - ianlancetaylor 8y ago
        That is not the only difference. Exceptions travel through calling functions if there is no catch clause. The check construct does not.
        spullara 8y ago
        The default handler just propagates the error up to the caller.
        ianlancetaylor 8y ago
        And then the caller has to either check or ignore the error. The error never propagates to the caller's caller without an explicit action in the caller. That is unlike exceptions.
        quotemstr 8y ago
        But it will propagate through a chain of unmarked check calls. If the requirement to mark potentially-throwing call sites is what disqualifies an error handling scheme as belonging to the class of exception systems, then we need a new term that includes both exceptions and this proposal and excludes everything else, because the proposed Go scheme very closely resembles exceptions.
- spullara 8y ago
  Ok, we won't call them exception handlers. Instead, call them "if anything goes wrong in this function do this" handlers.
  - SamWhited 8y ago
    Those are very different things, whatever you want to call them. check/handle doesn't involve unwinding the stack, and doesn't default to crashing your program if you forget to add a handle block.
    - tonyedgecombe 8y ago
      and doesn't default to crashing your program if you forget to add a handle block Is that a good thing?
      - grey-area 8y ago
        Is that a good thing? Yes, because instead your program won’t compile if you forget to handle an error ( except in the case of a function which only returns error, which you can ignore by mistake - I would like to see that fixed in go 2 as well).
        fwip 8y ago
        Expect to see a lot of `_, _ = fmt.Println(...)`, then.
        grey-area 8y ago
        Since they’re calling it go 2 perhaps they could just make an exception for println by having an alternative with no error (like map access with k,ok or just k).
- jerf 8y ago
  One of the key characteristics of exception handling is the ability to set a handler in one stack frame, but receive exceptions from deeper in the stack, causing error-handling-at-a-distance. Anything that does not have that is not an exception system. Proof: Any exception system that lacked the ability to catch exceptions from lower frames would be called a defective exception system. This check keyword does not implement an exception handling system.
  - spullara 8y ago
    This is the default behavior of the new check system. If you don't handle it at the bottom of the stack it is propagated up the stack to the caller automatically. Not sure how easy this will be to debug since it doesn't capture a stack trace at the bottom and it won't be obvious where the error started.
    - grey-area 8y ago
      But isn’t it only to the immediate caller using the explicitly declared error, not all the way up the stack? That’s very different behaviour and along with using the error interface avoids the main objections to exceptions ( unexpected throws handled far from the error location, unexpected errr types). This is just a small change to make it easier to annotate and easier to return without comment.
      - spullara 8y ago
        Assuming the caller uses check as well it will continue on. Seems the same as checked exceptions to me.
        grey-area 8y ago
        That’s an invalid assumption, as most functions will not use check (looking at my code there are just a few places I’d use it). It’s an addition to current error handling, not a replacement.
bradfitz 8y ago
Lack of generics was never part of "Go idealism". It has remained an open question for 9 years. It was added to the FAQ in 2010: https://web.archive.org/web/20101123010932/http://golang.org/doc/go_faq.html https://web.archive.org/web/20101123010932/http://golang.org... Ian has been thinking about the problem for the past 7+ years, since even before Go1 was out, when the language was frozen. I think this is about the seventh generics design doc that Ian has written. (This time he wrote it with Robert.) They keep getting better. Hopefully this one holds up.
- josefx 8y ago
  > Lack of generics was never part of "Go idealism". It has remained an open question for 9 years. You should read less is exponentially more by Pike. He made it clear back then that he didn't see a need for generics and Go was explicitly written to be a replacement for C++ without all the unnecessary features. Not having generics was at least initially a core part in justifying the existance of Go, just like not having any form of exception handling ( they had to add panic recover quite early ).
  - calcifer 8y ago
    You realize you are trying to explain Go's philosophy to one of the Go developers, right?
    - josefx 8y ago
      Are you claiming that Pike wasn't a core developer and driving force behind Go? Because my point is about the "never" being false when early statements quite clearly said something else.
      - calcifer 8y ago
        > Are you claiming that [...] No, I'm saying that the person you are replying to has no need of you reminding him of Pike's words, given that he actually knows Pike, unlike you.
reificator 8y ago
I've always been of the opinion that generics would be nice to have. But people were acting ridiculous about their exclusion. You can write plenty of useful programs without them.
- erik_seaberg 8y ago
  You can write any useful program in assembly, but compile time is dirt cheap so it's far more reasonable to automate anything that doesn't require thought and creativity. E.g., a large set of identical function bodies with similar but different types, where if I write them by hand the best I can do is not make any mistakes.
  - weberc2 8y ago
    I'm generally for generics, but there are tradeoffs. As soon as they debut, expect a flood of overly abstracted libraries. I'm actually pretty apprehensive because I could easily see the costs outweighing the gains.
    - yashap 8y ago
      Agreed that “excess abstraction entering the Go ecosystem” is probably the main danger, but even still, I’m not too worried. The Go community is all about simplicity, and I don’t see that changing. It’s not going to suddenly become the Enterprise Java community. Libraries with crazy abstract APIs won’t become popular. I expect it’ll be similar to Python, which supports generics, very powerful reflection, many programming paradigms, etc., but the popular libraries tend to have simple, easy to understand APIs, because that’s just the culture of the community.
      - weberc2 8y ago
        This last point isn’t true at all. Lots of popular libraries do weird things. Lots of popular library functions do completely different things based on the types and combinations of provided parameters (Pandas being one of the most egregious offenders, but the stdlib does this all over too) or they overload operators to make a clever, magical DSL (e.g., SQLAlchemy). Or they use metaclasses to programmatically generate APIs (e.g., AWS sdk, SQLAlchemy, etc). I take notice because I use Python professionally and spend so much more time pouring over docs and source code trying to grok APIs than I do with Go.
dnomad 8y ago
To some extent I almost wish they had stuck to their guns. The current brokenness actually serves as a much stronger argument for why exceptions are needed. There's a visceral understanding that comes from forcing people to handle every error immediately that is actually very hard to teach.
yashap 8y ago
Agreed! Go is the only language I’ve found that combines static typing, lightning fast compilation, great concurrency support, a lightweight runtime, a community that emphasizes simplicity over purity, a strong ecosystem, and nice tooling. However, ever churning dependency management, cumbersome error handling and the lack of generics were all huge drawbacks, that kept me reaching for Scala and Python for backends of personal projects. When Go 2 comes out, I think it’ll be my clear #1. It’ll bring the language to the level of power I like, while maintaining Go’s unique set of strengths (listed above).

the_duke 8y ago

Edit: To clarify, the handle() system does indeed resemble an exception propagation system and is also the part I like least. Just "check" would be preferable, with an implicit handler of "if err != nil { return err }" Although I still would prefer something leaner like the "?" operator from Rust.

quotemstr 8y ago
> The draft design introduces two new syntactic forms. First, it introduces a checked expression check f(x, y, z) or check err, marking an explicit error check. Second, it introduces a handle statement defining an error handler. When an error check fails, it transfers control to the innermost handler, which transfers control to the next handler above it, and so on, until a handler executes a return statement. Sure. It's explicit error handling that just so happens to look exactly like a form of exception handling, c.f., the zero-overhead exceptions proposal in C++land. This is how you say, in language-design-ese, "I want to do what my critics have been saying for years is the right thing without admitting that they've been right all along".
- heavenlyhash 8y ago
  I really don't know where people get on this high horse and imagine that there's been some kind of fighting attitude here. I saw a talk by James Gosling (of Java fame) a few months ago in which he said one of the most important things he's glad he did throughout the development of the language is "Decide... not to decide". The purpose of this "deciding not to decide" should sound familiar by now: once you commit to something, it's hard to backtrack. And once it's hard to backtrack, you have lost your ability to look for more optimal solutions than the one you've fixated on. This is why generics in Java took so long. And to this day, the developers of those generics do not regret taking their time to do so. I think that's interesting to note, don't you? It's okay to make decisions after deliberation. Deliberation does not imply a fight. --- Tone police aside, did you... read... the proposals? I don't think it's correct to dismissively say that the proposed handle/check syntax is identical to other checked exception syntaxes; it doesn't compose in the same way as traditional try-catch blocks; and it doesn't have the power to create arbitrary longjumps across multiple stack frames as exceptions do. In short, it's very little like traditional exceptions at all.
  - pjmlp 8y ago
    Actually they do, hence the ongoing work to add value types and reified generics to Java, which is again a multi-year project with no defined end date.
    - heavenlyhash 8y ago
      Sure, but just like there's a difference between "deliberation" and "a fight", there's also a difference between "hmm, there's more to do" and "we regret the thinking we invested so far".
- rsc 8y ago
  If you are interested in learning why check-handle differs from traditional exception handling, you can read https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf.... If you just feel like snarking, then sorry for spoiling.
  - erik_seaberg 8y ago
    It looks like the only difference is that catch blocks precede try blocks and aren't indented to show how they nest. One could mechanically convert handle err { cleanup1() return 42, nil } handle err { cleanup2() } check dostuff() into try { try { dostuff(); } catch (Exception e) { cleanup2(); throw e; } } catch (Exception e) { cleanup1(); return 42; }
    - ianlancetaylor 8y ago
      That is not the only difference. Exceptions travel through calling functions if there is no catch clause. The check construct does not.
      - spullara 8y ago
        The default handler just propagates the error up to the caller.
        ianlancetaylor 8y ago
        And then the caller has to either check or ignore the error. The error never propagates to the caller's caller without an explicit action in the caller. That is unlike exceptions.
        quotemstr 8y ago
        But it will propagate through a chain of unmarked check calls. If the requirement to mark potentially-throwing call sites is what disqualifies an error handling scheme as belonging to the class of exception systems, then we need a new term that includes both exceptions and this proposal and excludes everything else, because the proposed Go scheme very closely resembles exceptions.
spullara 8y ago
Ok, we won't call them exception handlers. Instead, call them "if anything goes wrong in this function do this" handlers.
- SamWhited 8y ago
  Those are very different things, whatever you want to call them. check/handle doesn't involve unwinding the stack, and doesn't default to crashing your program if you forget to add a handle block.
  - tonyedgecombe 8y ago
    and doesn't default to crashing your program if you forget to add a handle block Is that a good thing?
    - grey-area 8y ago
      Is that a good thing? Yes, because instead your program won’t compile if you forget to handle an error ( except in the case of a function which only returns error, which you can ignore by mistake - I would like to see that fixed in go 2 as well).
      - fwip 8y ago
        Expect to see a lot of `_, _ = fmt.Println(...)`, then.
        grey-area 8y ago
        Since they’re calling it go 2 perhaps they could just make an exception for println by having an alternative with no error (like map access with k,ok or just k).
jerf 8y ago
One of the key characteristics of exception handling is the ability to set a handler in one stack frame, but receive exceptions from deeper in the stack, causing error-handling-at-a-distance. Anything that does not have that is not an exception system. Proof: Any exception system that lacked the ability to catch exceptions from lower frames would be called a defective exception system. This check keyword does not implement an exception handling system.
- spullara 8y ago
  This is the default behavior of the new check system. If you don't handle it at the bottom of the stack it is propagated up the stack to the caller automatically. Not sure how easy this will be to debug since it doesn't capture a stack trace at the bottom and it won't be obvious where the error started.
  - grey-area 8y ago
    But isn’t it only to the immediate caller using the explicitly declared error, not all the way up the stack? That’s very different behaviour and along with using the error interface avoids the main objections to exceptions ( unexpected throws handled far from the error location, unexpected errr types). This is just a small change to make it easier to annotate and easier to return without comment.
    - spullara 8y ago
      Assuming the caller uses check as well it will continue on. Seems the same as checked exceptions to me.
      - grey-area 8y ago
        That’s an invalid assumption, as most functions will not use check (looking at my code there are just a few places I’d use it). It’s an addition to current error handling, not a replacement.

bradfitz 8y ago

Lack of generics was never part of "Go idealism". It has remained an open question for 9 years. It was added to the FAQ in 2010: https://web.archive.org/web/20101123010932/http://golang.org/doc/go_faq.html https://web.archive.org/web/20101123010932/http://golang.org... Ian has been thinking about the problem for the past 7+ years, since even before Go1 was out, when the language was frozen. I think this is about the seventh generics design doc that Ian has written. (This time he wrote it with Robert.) They keep getting better. Hopefully this one holds up.

josefx 8y ago
> Lack of generics was never part of "Go idealism". It has remained an open question for 9 years. You should read less is exponentially more by Pike. He made it clear back then that he didn't see a need for generics and Go was explicitly written to be a replacement for C++ without all the unnecessary features. Not having generics was at least initially a core part in justifying the existance of Go, just like not having any form of exception handling ( they had to add panic recover quite early ).
- calcifer 8y ago
  You realize you are trying to explain Go's philosophy to one of the Go developers, right?
  - josefx 8y ago
    Are you claiming that Pike wasn't a core developer and driving force behind Go? Because my point is about the "never" being false when early statements quite clearly said something else.
    - calcifer 8y ago
      > Are you claiming that [...] No, I'm saying that the person you are replying to has no need of you reminding him of Pike's words, given that he actually knows Pike, unlike you.

reificator 8y ago

I've always been of the opinion that generics would be nice to have. But people were acting ridiculous about their exclusion. You can write plenty of useful programs without them.

erik_seaberg 8y ago
You can write any useful program in assembly, but compile time is dirt cheap so it's far more reasonable to automate anything that doesn't require thought and creativity. E.g., a large set of identical function bodies with similar but different types, where if I write them by hand the best I can do is not make any mistakes.
- weberc2 8y ago
  I'm generally for generics, but there are tradeoffs. As soon as they debut, expect a flood of overly abstracted libraries. I'm actually pretty apprehensive because I could easily see the costs outweighing the gains.
  - yashap 8y ago
    Agreed that “excess abstraction entering the Go ecosystem” is probably the main danger, but even still, I’m not too worried. The Go community is all about simplicity, and I don’t see that changing. It’s not going to suddenly become the Enterprise Java community. Libraries with crazy abstract APIs won’t become popular. I expect it’ll be similar to Python, which supports generics, very powerful reflection, many programming paradigms, etc., but the popular libraries tend to have simple, easy to understand APIs, because that’s just the culture of the community.
    - weberc2 8y ago
      This last point isn’t true at all. Lots of popular libraries do weird things. Lots of popular library functions do completely different things based on the types and combinations of provided parameters (Pandas being one of the most egregious offenders, but the stdlib does this all over too) or they overload operators to make a clever, magical DSL (e.g., SQLAlchemy). Or they use metaclasses to programmatically generate APIs (e.g., AWS sdk, SQLAlchemy, etc). I take notice because I use Python professionally and spend so much more time pouring over docs and source code trying to grok APIs than I do with Go.

dnomad 8y ago

To some extent I almost wish they had stuck to their guns. The current brokenness actually serves as a much stronger argument for why exceptions are needed. There's a visceral understanding that comes from forcing people to handle every error immediately that is actually very hard to teach.

yashap 8y ago

Agreed! Go is the only language I’ve found that combines static typing, lightning fast compilation, great concurrency support, a lightweight runtime, a community that emphasizes simplicity over purity, a strong ecosystem, and nice tooling. However, ever churning dependency management, cumbersome error handling and the lack of generics were all huge drawbacks, that kept me reaching for Scala and Python for backends of personal projects. When Go 2 comes out, I think it’ll be my clear #1. It’ll bring the language to the level of power I like, while maintaining Go’s unique set of strengths (listed above).