5 ms·

If you know any other language, you basically already know Go (with the exception of the channels stuff). The biggest pain is the if err != nil stuff, which I k

If you know any other language, you basically already know Go (with the exception of the channels stuff). The biggest pain is the if err != nil stuff, which I know some people like but it is suboptimal in my view. While far better than C# and Java's exceptions, far worse than Zig's model.

pjmlp 2mo ago
Yeah, panic/defer/recover are so much better. /s
throwaway2037 2mo ago
> far better than C# and Java's exceptions What is wrong with them? When writing enterprise CRUD apps, they are very useful.
- wannabe44 2mo ago
  People don't understand exceptional control flow. They think they have to catch them at every point, instead of using them as intended (having a central boundary of error handling where you have enough context whether to retry or abort the operation). So they think Go errors are better. With exceptions you can 1. Set exception breakpoints. 2. Have real stack traces. 3. No need to write 3 lines of boiler plate every 1 line of code which interacts with outside world. Ironically this is the case in Go's niche - devopshit, cloud webshit - where the boilerplate error handling makes even less sense since because 1. You are making a network call or OS interactions every 2 lines which can err 2. The consequences of an unhandled exception are actually quite less severe. At worst your request will 500 or the application will restart - which is a consideration you can't escape in these environments. 3. I have seen indiscriminate error handling written by substandard developers which simply concatenates the full wrapped error string to API, leaking full details. At least with exceptions, you can designate different types of exception for 404s vs ayth errors vs bad requests vs Internal errors, and have a central handler which filters out. In go theoretically you can do this, but I have never seen someone utilize errors.As over stringy error handling. I like Go - it has nice stdlib, nice compiler and runtime, and actually dared to innovate away from the fat-ass LLVM monoculture and made green threads popular. But error handling and uninitialised values sticks out like a sore thumb. It's impossible to read code which does many API/network/OS interactions.
  - osigurdson 2mo ago
    There is a reason why Rust, Go and Zig don't have exceptions and it isn't because the language designers didn't understand them. While you can achieve the same thing using both approaches, errors as return values is generally simpler to reason about. Even in C# for example, exceptions are going to start taking a back seat with tagged unions which will be much better for expected failures. I agree that Go's approach is a little cumbersome however. Suggest checking out Zig's approach which I personally think really nails it.
    - win311fwg 2mo ago
      > Go [...] don't have exceptions What do you mean? Go has exceptions. Their use with errors is generally discouraged because exceptions, as the name literally implies, are technically designed for exceptional circumstances (programmer fault), not errors (environmental fault), but just like in every other language with exceptions you can do it, and even Go's own standard library uses exceptions for errors in some cases. The Go creators have even expressed openly that you should be pragmatic about it: use them for errors if it makes your code better. They are there to use.
      - osigurdson 2mo ago
        If you mean panic, it isn't really the same thing.
        win311fwg 2mo ago
        An exception is a data structure, usually comprised of a stack trace and some kind of related data, so that's true. panic produces an exception, though, just like throw, raise, etc. as found in some other popular languages do.
        wfn 2mo ago
        I'd strongly disagree, Go panic mechanism (but not just in the runtime sense but also in language feature sense) is quite distinct from what we typically understand "exceptions" to mean (which - esp. depending on language - are not at all just about handling programmer error). I think this is a decent article on exactly this: https://medium.com/@AlexanderObregon/why-go-panics-are-different-from-exceptions-bdf43a3957c0 https://medium.com/@AlexanderObregon/why-go-panics-are-diffe... But just imagine how exceptions typically have a whole propagation mechanism and type (=> catch) structure. Not so in Go. (Not implying some one model is better here, just flagging that panic vs exception are sufficiently distinct in meaningful (and deliberate) ways such that we can say they are "different", imho). edit p.s. s/panic/panic+defer+recover p.p.s. On exception control flow - good comment upstream by 'wannabe44, imho: https://news.ycombinator.com/item?id=49270430 https://news.ycombinator.com/item?id=49270430
- osigurdson 2mo ago
  If you reach a scenario that should crash your app, exceptions are fine. However, they are a pain (and brittle in the case of C#) when the intention is to handle them. This is the reason why many newer languages don't use exceptions.
  - Cthulhu_ 2mo ago
    They're also a "thinking error"; most errors are not exceptional and should instead be part of the regular flow of your application. But in 90's/2000's languages like Java and C#, they consider "this file does not exist" as an exception. Second issue is that they include a call stack and are generally pretty expensive to construct. To circumvent this, a lot of exception languages are written in a more defensive style.
    - throwaway2037 2mo ago
      It is interesting that you picked Java/C# and "they consider "this file does not exist" as an exception". Firstly, I know more about Java. It is not an exception when testing for the existance of a file that does not exist. However, it is an exception to attempt to open a file (for reading) that does not exist. Also, for those unaware, exception class FileNotFoundException is a subclass of IOException, which is "checked" and cannot be ignored. However, when calling the C function "open" (or "fopen") to open a file, the programmer can easily forget to check the return value. This is harder to do in Java, thanks to the checked exception. Here is some sample Java code to demonstrate: > try { > FileReader reader = new FileReader("file.txt"); > // Use 'reader' here. > } catch (FileNotFoundException e) { > // ... > } How do you propose to change class FileReader such that it will not throw an exception if the file does not exist? > To circumvent this, a lot of exception languages are written in a more defensive style. I don't understand this comment. Can you provide some examples?
  - throwaway2037 2mo ago
    > brittle in the case of C# Can you explain more? In my experience, exceptions in Java, C#, and Python are all very stable and not-at-all "brittle".

pjmlp 2mo ago

Yeah, panic/defer/recover are so much better. /s

throwaway2037 2mo ago

> far better than C# and Java's exceptions What is wrong with them? When writing enterprise CRUD apps, they are very useful.

wannabe44 2mo ago
People don't understand exceptional control flow. They think they have to catch them at every point, instead of using them as intended (having a central boundary of error handling where you have enough context whether to retry or abort the operation). So they think Go errors are better. With exceptions you can 1. Set exception breakpoints. 2. Have real stack traces. 3. No need to write 3 lines of boiler plate every 1 line of code which interacts with outside world. Ironically this is the case in Go's niche - devopshit, cloud webshit - where the boilerplate error handling makes even less sense since because 1. You are making a network call or OS interactions every 2 lines which can err 2. The consequences of an unhandled exception are actually quite less severe. At worst your request will 500 or the application will restart - which is a consideration you can't escape in these environments. 3. I have seen indiscriminate error handling written by substandard developers which simply concatenates the full wrapped error string to API, leaking full details. At least with exceptions, you can designate different types of exception for 404s vs ayth errors vs bad requests vs Internal errors, and have a central handler which filters out. In go theoretically you can do this, but I have never seen someone utilize errors.As over stringy error handling. I like Go - it has nice stdlib, nice compiler and runtime, and actually dared to innovate away from the fat-ass LLVM monoculture and made green threads popular. But error handling and uninitialised values sticks out like a sore thumb. It's impossible to read code which does many API/network/OS interactions.
- osigurdson 2mo ago
  There is a reason why Rust, Go and Zig don't have exceptions and it isn't because the language designers didn't understand them. While you can achieve the same thing using both approaches, errors as return values is generally simpler to reason about. Even in C# for example, exceptions are going to start taking a back seat with tagged unions which will be much better for expected failures. I agree that Go's approach is a little cumbersome however. Suggest checking out Zig's approach which I personally think really nails it.
  - win311fwg 2mo ago
    > Go [...] don't have exceptions What do you mean? Go has exceptions. Their use with errors is generally discouraged because exceptions, as the name literally implies, are technically designed for exceptional circumstances (programmer fault), not errors (environmental fault), but just like in every other language with exceptions you can do it, and even Go's own standard library uses exceptions for errors in some cases. The Go creators have even expressed openly that you should be pragmatic about it: use them for errors if it makes your code better. They are there to use.
    - osigurdson 2mo ago
      If you mean panic, it isn't really the same thing.
      - win311fwg 2mo ago
        An exception is a data structure, usually comprised of a stack trace and some kind of related data, so that's true. panic produces an exception, though, just like throw, raise, etc. as found in some other popular languages do.
        wfn 2mo ago
        I'd strongly disagree, Go panic mechanism (but not just in the runtime sense but also in language feature sense) is quite distinct from what we typically understand "exceptions" to mean (which - esp. depending on language - are not at all just about handling programmer error). I think this is a decent article on exactly this: https://medium.com/@AlexanderObregon/why-go-panics-are-different-from-exceptions-bdf43a3957c0 https://medium.com/@AlexanderObregon/why-go-panics-are-diffe... But just imagine how exceptions typically have a whole propagation mechanism and type (=> catch) structure. Not so in Go. (Not implying some one model is better here, just flagging that panic vs exception are sufficiently distinct in meaningful (and deliberate) ways such that we can say they are "different", imho). edit p.s. s/panic/panic+defer+recover p.p.s. On exception control flow - good comment upstream by 'wannabe44, imho: https://news.ycombinator.com/item?id=49270430 https://news.ycombinator.com/item?id=49270430
osigurdson 2mo ago
If you reach a scenario that should crash your app, exceptions are fine. However, they are a pain (and brittle in the case of C#) when the intention is to handle them. This is the reason why many newer languages don't use exceptions.
- Cthulhu_ 2mo ago
  They're also a "thinking error"; most errors are not exceptional and should instead be part of the regular flow of your application. But in 90's/2000's languages like Java and C#, they consider "this file does not exist" as an exception. Second issue is that they include a call stack and are generally pretty expensive to construct. To circumvent this, a lot of exception languages are written in a more defensive style.
  - throwaway2037 2mo ago
    It is interesting that you picked Java/C# and "they consider "this file does not exist" as an exception". Firstly, I know more about Java. It is not an exception when testing for the existance of a file that does not exist. However, it is an exception to attempt to open a file (for reading) that does not exist. Also, for those unaware, exception class FileNotFoundException is a subclass of IOException, which is "checked" and cannot be ignored. However, when calling the C function "open" (or "fopen") to open a file, the programmer can easily forget to check the return value. This is harder to do in Java, thanks to the checked exception. Here is some sample Java code to demonstrate: > try { > FileReader reader = new FileReader("file.txt"); > // Use 'reader' here. > } catch (FileNotFoundException e) { > // ... > } How do you propose to change class FileReader such that it will not throw an exception if the file does not exist? > To circumvent this, a lot of exception languages are written in a more defensive style. I don't understand this comment. Can you provide some examples?
- throwaway2037 2mo ago
  > brittle in the case of C# Can you explain more? In my experience, exceptions in Java, C#, and Python are all very stable and not-at-all "brittle".