9 ms·

Go looks like a really nice language, but then I discovered that they don't _want_ to have exceptions. Crazy. I'm sticking with Erlang, "Let It Crash" (and han

Go looks like a really nice language, but then I discovered that they don't _want_ to have exceptions. Crazy. I'm sticking with Erlang, "Let It Crash" (and handle the crash) is better than "add if(err) after everything and good luck with that"

nolok 13y ago
> "Let It Crash" (and handle the crash) panic() and recover() does that. It's not exceptions, but it does exactly that.
- lazyjones 13y ago
  It's the supervisor trees that are missing and cannot currently be implemented though.
  - AeroNotix 13y ago
    As a built-in language feature they are missing, but you can and some codebases do implement a kill channel for child goroutines.
  - jerf 13y ago
    As it happens, I've spent the last two days implementing supervision trees for Go, as I'm looking to port some stuff out of Erlang into Go. (There are a couple of existing libraries out there, but they are pretty weak tea, no offense to the authors in question, one of which is kind enough to label their effort with "this is my first Go code".) You can't implement Erlang-style trees without loss, and it's tricky due to some other things, but it can be done and you do get a substantial portion of the benefits, but also certainly not all. When I pop it up on github here soon, I'm planning on accompanying it by a blog post that will probably end up being longer than the entire library (including test suite and documentation) discussing all the whats and whys of how much you can and can not bring over of Erlang's approach.
  - JulianMorrison 13y ago
    Can be, easily. Your goroutine defers a function that calls recover and notifies the supervisor if it was panicking. It's exactly what Erlang does, just done slightly more manually.
  - dragonwriter 13y ago
    > It's the supervisor trees that are missing and cannot currently be implemented though. On a language level the support seems to be there, and not radically different from what Erlang offers. The pre-built libraries that make up OTP for Erlang aren't there and you have to build your own, but the underlying structure seems to be there.
AeroNotix 13y ago
Go solves a completely different problem to Erlang. Erlang is built for fault-tolerance and its dependence on concurrency stems from the want of having fault tolerance. Go does not strive to be Erlang, it doesn't even strive to be fault tolerant. Hell, you can deference a null pointer in Go! What Go is, is an incredibly simplistic language which can be picked up very easily by even mediocre developers. The language looks and feels like an updated and refreshed C. Whilst Erlang has a much more rich computation model when it comes to using the concurrent actor system, it also comes at a higher price of complexity. I'm an Erlang developer myself and even I wouldn't like to bestow OTP on a complete newbie. Go doesn't have this, the concurrency features are simple, they're not perfect but they work for their intended use-case. I'm thoroughly enthralled with Erlang as a language but I know that it has some extremely rough edges. You would know what these are yourself and so I won't enumerate them. Go doesn't (yet) have a lot of rough edges as it feels a lot of careful thought and planning has gone into every feature change. Does this mean that you don't have whizzbang features? Yes. Does it reduce the complexity by a huge factor? Yes!
- pjmlp 13y ago
  > What Go is, is an incredibly simplistic language which can be picked up very easily by even mediocre developers. Every enterprise manager's dream!
  - bsg75 13y ago
    Nope, that is Visual Basic. Edit: VB6 - The only Real VB
    - pjmlp 13y ago
      I agree with you if you are speaking about VB 6.
dchest 13y ago
Not this again.
asdasf 13y ago
>I discovered that they don't _want_ to have exceptions. Crazy That isn't the crazy part. Exceptions are bad, and should not exist. The crazy part is that they don't want to put in useful error handling, so we're stuck with crappy "if (err)" everywhere.
- adsche 13y ago
  Curious, what would you consider to be more useful error handling?
  - asdasf 13y ago
    I would like haskell without exceptions. Haskell has Maybe, Either, etc and a useful standard library to make the Monad instances of those useful. Which allows for libraries like this: http://hackage.haskell.org/package/errors http://hackage.haskell.org/package/errors
    - mason55 13y ago
      Similar to Option/Some/None in Scala which is immensely useful

nolok 13y ago

> "Let It Crash" (and handle the crash) panic() and recover() does that. It's not exceptions, but it does exactly that.

lazyjones 13y ago
It's the supervisor trees that are missing and cannot currently be implemented though.
- AeroNotix 13y ago
  As a built-in language feature they are missing, but you can and some codebases do implement a kill channel for child goroutines.
- jerf 13y ago
  As it happens, I've spent the last two days implementing supervision trees for Go, as I'm looking to port some stuff out of Erlang into Go. (There are a couple of existing libraries out there, but they are pretty weak tea, no offense to the authors in question, one of which is kind enough to label their effort with "this is my first Go code".) You can't implement Erlang-style trees without loss, and it's tricky due to some other things, but it can be done and you do get a substantial portion of the benefits, but also certainly not all. When I pop it up on github here soon, I'm planning on accompanying it by a blog post that will probably end up being longer than the entire library (including test suite and documentation) discussing all the whats and whys of how much you can and can not bring over of Erlang's approach.
- JulianMorrison 13y ago
  Can be, easily. Your goroutine defers a function that calls recover and notifies the supervisor if it was panicking. It's exactly what Erlang does, just done slightly more manually.
- dragonwriter 13y ago
  > It's the supervisor trees that are missing and cannot currently be implemented though. On a language level the support seems to be there, and not radically different from what Erlang offers. The pre-built libraries that make up OTP for Erlang aren't there and you have to build your own, but the underlying structure seems to be there.

AeroNotix 13y ago

Go solves a completely different problem to Erlang. Erlang is built for fault-tolerance and its dependence on concurrency stems from the want of having fault tolerance. Go does not strive to be Erlang, it doesn't even strive to be fault tolerant. Hell, you can deference a null pointer in Go! What Go is, is an incredibly simplistic language which can be picked up very easily by even mediocre developers. The language looks and feels like an updated and refreshed C. Whilst Erlang has a much more rich computation model when it comes to using the concurrent actor system, it also comes at a higher price of complexity. I'm an Erlang developer myself and even I wouldn't like to bestow OTP on a complete newbie. Go doesn't have this, the concurrency features are simple, they're not perfect but they work for their intended use-case. I'm thoroughly enthralled with Erlang as a language but I know that it has some extremely rough edges. You would know what these are yourself and so I won't enumerate them. Go doesn't (yet) have a lot of rough edges as it feels a lot of careful thought and planning has gone into every feature change. Does this mean that you don't have whizzbang features? Yes. Does it reduce the complexity by a huge factor? Yes!

pjmlp 13y ago
> What Go is, is an incredibly simplistic language which can be picked up very easily by even mediocre developers. Every enterprise manager's dream!
- bsg75 13y ago
  Nope, that is Visual Basic. Edit: VB6 - The only Real VB
  - pjmlp 13y ago
    I agree with you if you are speaking about VB 6.

dchest 13y ago

Not this again.

asdasf 13y ago

>I discovered that they don't _want_ to have exceptions. Crazy That isn't the crazy part. Exceptions are bad, and should not exist. The crazy part is that they don't want to put in useful error handling, so we're stuck with crappy "if (err)" everywhere.

adsche 13y ago
Curious, what would you consider to be more useful error handling?
- asdasf 13y ago
  I would like haskell without exceptions. Haskell has Maybe, Either, etc and a useful standard library to make the Monad instances of those useful. Which allows for libraries like this: http://hackage.haskell.org/package/errors http://hackage.haskell.org/package/errors
  - mason55 13y ago
    Similar to Option/Some/None in Scala which is immensely useful