5 ms·

Golang should have async/await and exceptions, both of which can be implemented as syntactic sugar on top of existing features.

throwaway894345 2y ago
Having used both async/await and goroutines, I much prefer the latter. But yes, goroutines and channels are powerful tools that require understanding and discipline.
randomdata 2y ago
Go has exceptions. Always has.
- shepherdjerred 2y ago
  Yes, but when writing idiomatic Go one would prefer error types over using panic (panic is Go's term for an exception). The parent is really complaining about idiomatic Go. Which is fair, because idiomatic Go feels like writing Java 6 (that is to say, making lots of compromises due to limitations of the language).
  - randomdata 2y ago
    > panic is Go's term for an exception No. An exception is a datatype. Not completely unlike an error type in concept, but intended for erroneous conditions that could have theoretically been caught at compile time (i.e. the programmer screwed up), as opposed to conditions that are not decidable at compile time (i.e. something happened in the outside world). In Go, panic creates an exception, which may be the source of your confusion. The exception contains any metadata you passed to panic along with other data, like a stack trace. This is not panic in and of itself, though. > but when writing idiomatic Go one would prefer error types over using panic Not really. Idiomatic Go says that errors are in no way special and is faulty to think of them as being special. They are just values like any other. Go exceptions allow attaching any value as metadata. The official line is that panic stack traversal should not cross package boundaries, but internal use is perfectly acceptable. Even the Go standard library does it.
    - hot_gril 2y ago
      This is confusing, so I'll put it this way, Golang doesn't have exceptions the way someone coming from Javascript, Java, Python, ObjC... would understand: thrown anywhere and automatically propagated up the call stack unless caught.
      - randomdata 2y ago
        There is nothing to be confused about. The syntax may be slightly different to other languages, but there is no meaningful difference in the design. If you understand exceptions and exception handlers in those other languages, you understand them in Go. There is no exactly a lot you can do with exceptions to see them differ in any big way. Why is it that Go attract so many "experts" who have clearly never used the language even just once?
        hot_gril 2y ago
        I understand how to use them in Golang, it's just annoying to have to keep checking and returning errors everywhere.
        randomdata 2y ago
        The language doesn't impose this upon you. You can use the exception handling system to pass values around, just like you might in the aforementioned languages. Even Go's standard library does it. Read the encoding/json source sometime. You might impose it upon yourself when you start to understand the pitfalls of using exceptional handlers for anything other than exceptions, but such is engineering. Everything comes with tradeoffs.
        hot_gril 2y ago
        What's imposed on a Golang user is two choices, panic/recover or regular error handling, and almost always you take the latter. There's no option of using exceptions the same way you would in most other languages.
tptacek 2y ago
Colored functions are a huge hit to take, and the things you do to make colored functions tolerable are also things you can do to mask off the complexity of channels from library callers. Async/await for Go seems like it would not be a win. I think exceptions are pretty much a dead letter in new language designs at this point? You could get people on board for real algebraic types and matching.
- hot_gril 2y ago
  Since the boat has already sailed for Golang having async/await from the start, adding it now would require maintaining compatibility with uncolored functions. Waiting for a channel to have data from a go func is similar. JS has similar compatibility with uncolored code using Promises. Python's migration to async/await is a lot worse because it didn't have coherent parallelism features to begin with. Exceptions are a smaller deal than async/await. Basically instead of manually writing "if err" everywhere, it's implicit if you aren't catching it. The most popular languages do this. Rust "?" syntax is also a decent compromise.
  - deleted 2y ago
    [deleted]
psanford 2y ago
Every go developer I know who likes the language disagrees with this sentiment (including myself). If you really want async/await Go is probably not the language for you. Thats ok! There are a lot of languages that other people like that I do not want to use. We don't need to have one language to rule them all. Its fine for languages to make different choices and trade-offs.
- AtlasBarfed 2y ago
  And yet they keep adding features that golang devs scream in unison aren't needed, until they are added. It's a weird cult-like thing. And go is reaching the point where like Java it gets crammed down your throat. Which is probably why golang should start adding even more features
  - hot_gril 2y ago
    Lots of Golang users told me generics aren't needed until they were added. But let's leave "cult" accusations out of this.
- hot_gril 2y ago
  Nowhere did I suggest one language should rule them all. Golang has advantages like efficiency and greenthreading, but that's not because they omitted async/await and exceptions. I just think that was a mistake. And I do use Golang on my team.
bborud 2y ago
I used languages with exceptions for 16-17 or so years and I've been using Go for 7-8 years. It took me quite a while (years) to go from thinking that returning error (conventionally as the last return value) was a bit clunky to thinking that this is actually a very good idea. I don't mind the if err != nil pattern. I can't think of a single experienced Go programmer that is sufficiently annoyed by this to complain. I sometimes see people new to the language complain about this, but it tends to fade as they adapt. With the ability to join errors, do sensible comparisons etc, errors work well for me when needing to express high level errors and their low level root causes. (eg the high level error may be "failed to read configuration" and the root cause might be "permission denied when opening file X"). I've come to realize that I like Go style errors better than exceptions for two reasons. First off, a lot of code in, for instance, Java uses unchecked exceptions. Which means that the whole idea that you have to handle exceptions goes out the window. This, of course, varies from codebase to codebase, but the it is common enough that having exceptions available in a language doesn't mean people will use them in a way that forces discipline. Which kind of makes exceptions pointless. They just become syntax for emitting and handling errors. And awkward syntax at that. Which is the second reason. Exceptions tend to introduce extra scopes you have to deal with. This is annoying and in some cases it can get somewhat complicated. Exceptions, the way they are commonly used, are a weak enforcement mechanism made more dangerous by people pretending it isn't. If you want discipline, neither exceptions nor Go errors are the way to go. You probably want to look to something like Rust. I have a hard time seeing how exceptions would make Go better. Yes, if someone could come up with some syntactic sugar for Go 2 to deal with errors, that would be nice, but I have seen no proposals for this that represent actual improvement. `if err != nil` is actually extremely readable and to justify new syntax for expressing this it would have to be a _lot_ better. I'm open to listening if people can come up with something. Exceptions didn't end up doing what people hoped it would do in Java. We should learn from that and try not to pointlessly repeat this mistake. Besides, Go has already made its choice. Retrofitting it is only going to do harm.
- hot_gril 2y ago
  The entire difference is whether or not you have to type "if err != nil { return err }" repeatedly. Some languages force you to handle exceptions, and some force you to handle non-exception errors.

throwaway894345 2y ago

Having used both async/await and goroutines, I much prefer the latter. But yes, goroutines and channels are powerful tools that require understanding and discipline.

randomdata 2y ago

Go has exceptions. Always has.

shepherdjerred 2y ago
Yes, but when writing idiomatic Go one would prefer error types over using panic (panic is Go's term for an exception). The parent is really complaining about idiomatic Go. Which is fair, because idiomatic Go feels like writing Java 6 (that is to say, making lots of compromises due to limitations of the language).
- randomdata 2y ago
  > panic is Go's term for an exception No. An exception is a datatype. Not completely unlike an error type in concept, but intended for erroneous conditions that could have theoretically been caught at compile time (i.e. the programmer screwed up), as opposed to conditions that are not decidable at compile time (i.e. something happened in the outside world). In Go, panic creates an exception, which may be the source of your confusion. The exception contains any metadata you passed to panic along with other data, like a stack trace. This is not panic in and of itself, though. > but when writing idiomatic Go one would prefer error types over using panic Not really. Idiomatic Go says that errors are in no way special and is faulty to think of them as being special. They are just values like any other. Go exceptions allow attaching any value as metadata. The official line is that panic stack traversal should not cross package boundaries, but internal use is perfectly acceptable. Even the Go standard library does it.
  - hot_gril 2y ago
    This is confusing, so I'll put it this way, Golang doesn't have exceptions the way someone coming from Javascript, Java, Python, ObjC... would understand: thrown anywhere and automatically propagated up the call stack unless caught.
    - randomdata 2y ago
      There is nothing to be confused about. The syntax may be slightly different to other languages, but there is no meaningful difference in the design. If you understand exceptions and exception handlers in those other languages, you understand them in Go. There is no exactly a lot you can do with exceptions to see them differ in any big way. Why is it that Go attract so many "experts" who have clearly never used the language even just once?
      - hot_gril 2y ago
        I understand how to use them in Golang, it's just annoying to have to keep checking and returning errors everywhere.
        randomdata 2y ago
        The language doesn't impose this upon you. You can use the exception handling system to pass values around, just like you might in the aforementioned languages. Even Go's standard library does it. Read the encoding/json source sometime. You might impose it upon yourself when you start to understand the pitfalls of using exceptional handlers for anything other than exceptions, but such is engineering. Everything comes with tradeoffs.
        hot_gril 2y ago
        What's imposed on a Golang user is two choices, panic/recover or regular error handling, and almost always you take the latter. There's no option of using exceptions the same way you would in most other languages.

tptacek 2y ago

Colored functions are a huge hit to take, and the things you do to make colored functions tolerable are also things you can do to mask off the complexity of channels from library callers. Async/await for Go seems like it would not be a win. I think exceptions are pretty much a dead letter in new language designs at this point? You could get people on board for real algebraic types and matching.

hot_gril 2y ago
Since the boat has already sailed for Golang having async/await from the start, adding it now would require maintaining compatibility with uncolored functions. Waiting for a channel to have data from a go func is similar. JS has similar compatibility with uncolored code using Promises. Python's migration to async/await is a lot worse because it didn't have coherent parallelism features to begin with. Exceptions are a smaller deal than async/await. Basically instead of manually writing "if err" everywhere, it's implicit if you aren't catching it. The most popular languages do this. Rust "?" syntax is also a decent compromise.
- deleted 2y ago
  [deleted]

psanford 2y ago

Every go developer I know who likes the language disagrees with this sentiment (including myself). If you really want async/await Go is probably not the language for you. Thats ok! There are a lot of languages that other people like that I do not want to use. We don't need to have one language to rule them all. Its fine for languages to make different choices and trade-offs.

AtlasBarfed 2y ago
And yet they keep adding features that golang devs scream in unison aren't needed, until they are added. It's a weird cult-like thing. And go is reaching the point where like Java it gets crammed down your throat. Which is probably why golang should start adding even more features
- hot_gril 2y ago
  Lots of Golang users told me generics aren't needed until they were added. But let's leave "cult" accusations out of this.
hot_gril 2y ago
Nowhere did I suggest one language should rule them all. Golang has advantages like efficiency and greenthreading, but that's not because they omitted async/await and exceptions. I just think that was a mistake. And I do use Golang on my team.

bborud 2y ago

I used languages with exceptions for 16-17 or so years and I've been using Go for 7-8 years. It took me quite a while (years) to go from thinking that returning error (conventionally as the last return value) was a bit clunky to thinking that this is actually a very good idea. I don't mind the if err != nil pattern. I can't think of a single experienced Go programmer that is sufficiently annoyed by this to complain. I sometimes see people new to the language complain about this, but it tends to fade as they adapt. With the ability to join errors, do sensible comparisons etc, errors work well for me when needing to express high level errors and their low level root causes. (eg the high level error may be "failed to read configuration" and the root cause might be "permission denied when opening file X"). I've come to realize that I like Go style errors better than exceptions for two reasons. First off, a lot of code in, for instance, Java uses unchecked exceptions. Which means that the whole idea that you have to handle exceptions goes out the window. This, of course, varies from codebase to codebase, but the it is common enough that having exceptions available in a language doesn't mean people will use them in a way that forces discipline. Which kind of makes exceptions pointless. They just become syntax for emitting and handling errors. And awkward syntax at that. Which is the second reason. Exceptions tend to introduce extra scopes you have to deal with. This is annoying and in some cases it can get somewhat complicated. Exceptions, the way they are commonly used, are a weak enforcement mechanism made more dangerous by people pretending it isn't. If you want discipline, neither exceptions nor Go errors are the way to go. You probably want to look to something like Rust. I have a hard time seeing how exceptions would make Go better. Yes, if someone could come up with some syntactic sugar for Go 2 to deal with errors, that would be nice, but I have seen no proposals for this that represent actual improvement. `if err != nil` is actually extremely readable and to justify new syntax for expressing this it would have to be a _lot_ better. I'm open to listening if people can come up with something. Exceptions didn't end up doing what people hoped it would do in Java. We should learn from that and try not to pointlessly repeat this mistake. Besides, Go has already made its choice. Retrofitting it is only going to do harm.

hot_gril 2y ago
The entire difference is whether or not you have to type "if err != nil { return err }" repeatedly. Some languages force you to handle exceptions, and some force you to handle non-exception errors.