6 ms·

On a tangent line, one thing I dislike about Go is the error handling. I find it really annoying to have to check for errors at every single step. Erlang has pr

On a tangent line, one thing I dislike about Go is the error handling. I find it really annoying to have to check for errors at every single step. Erlang has probably the most elegant error handling mechanism. Just let if fail, and then restart the whole process/subsystem.

thezilch 12y ago
Certainly you can do this with Go by letting it panic and having your preferred supervisor (eg. supervisord) supervise the process?
- jacquesm 12y ago
  Yes, but that kills all the other go-routines in that process as well. In Erlang that would just affect the one thread.
  - lgas 12y ago
    You could build an erlang/OTP style supervision tree using recover at the top level to restart panic'd goroutines.
    - jacquesm 12y ago
      You're going to have a hard time maintaining consistent state but if you manage your bookkeeping very well that might work in a long lived process. If not you might end up leaking resources. Go routines and erlang processes are not mapping 1:1 with each other and I (maybe naively) assume that resources such as file descriptors and other subtle state modifications could easily survive a naive implementation of such a scheme causing eventual resource depletion. Erlang is bulletproof in this respect.
      - lgas 12y ago
        That is true, and I suppose the fact that third party go libraries won't be written with this philosophy in mind means that you would have to audit all third party library use pretty carefully, which would make using this approach on projects of significant size untenable.
      - pushrax 12y ago
        Defers are still called when the stack is unwound due to a panic. It's standard practise to clean up resources with a defer, so maybe it wouldn't be too unreasonable if you're mainly dealing with the standard libraries.
        jacquesm 12y ago
        Would you bet your phone switchboard, nuclear plant or assembly line to that strategy? Go is very much a work in development, it is a vast improvement over C but I highly doubt that this strategy will get you out of every corner case. It might get you from 'crash now' to 'crash a (little) while later' but I think you will still end up having an unpredictable element in there. It all depends on how ugly the crash is and once things become unpredictable leakage (even between go-routines) is not to be ruled out categorically. Think of erlang processes to be about as well isolated as unix processes and think of go processes to be a bit more isolated than unix threads but not much more. The trick here is that erlang is essentially an OS inside a process and that go-routines are co-operative multi-tasking inside a process aided by one or more cpu threads. That's a lot closer to the C multi-threading model than erlang and that implies there are some risks.
        troutwine 12y ago
        It's worth noting that Erlang is only a soft-realtime language. I wouldn't bet my nuclear plant and only some assembly lines on it. (There's plenty I do bet on Erlang, though.)
        jacquesm 12y ago
        That's valid, hard real time problems require guarantees that erlang can't give, that was an unwarranted exaggeration on my part. But anything that needs to be very long running (years or more) will need ironclad guarantees that it won't be leaking resources and I can't prove but suspect that erlang will do a lot better than go for those applications. Let's leave the nuclear plants and the assembly lines to RTos and QnX then :).
- orblivion 12y ago
  You'd also need to assert every time you called a function to make sure you got what you expected. I know basically nothing about Go, but I found this that says that it doesn't even have assertions: http://golang.org/doc/faq#assertions http://golang.org/doc/faq#assertions

thezilch 12y ago

Certainly you can do this with Go by letting it panic and having your preferred supervisor (eg. supervisord) supervise the process?

jacquesm 12y ago
Yes, but that kills all the other go-routines in that process as well. In Erlang that would just affect the one thread.
- lgas 12y ago
  You could build an erlang/OTP style supervision tree using recover at the top level to restart panic'd goroutines.
  - jacquesm 12y ago
    You're going to have a hard time maintaining consistent state but if you manage your bookkeeping very well that might work in a long lived process. If not you might end up leaking resources. Go routines and erlang processes are not mapping 1:1 with each other and I (maybe naively) assume that resources such as file descriptors and other subtle state modifications could easily survive a naive implementation of such a scheme causing eventual resource depletion. Erlang is bulletproof in this respect.
    - lgas 12y ago
      That is true, and I suppose the fact that third party go libraries won't be written with this philosophy in mind means that you would have to audit all third party library use pretty carefully, which would make using this approach on projects of significant size untenable.
    - pushrax 12y ago
      Defers are still called when the stack is unwound due to a panic. It's standard practise to clean up resources with a defer, so maybe it wouldn't be too unreasonable if you're mainly dealing with the standard libraries.
      - jacquesm 12y ago
        Would you bet your phone switchboard, nuclear plant or assembly line to that strategy? Go is very much a work in development, it is a vast improvement over C but I highly doubt that this strategy will get you out of every corner case. It might get you from 'crash now' to 'crash a (little) while later' but I think you will still end up having an unpredictable element in there. It all depends on how ugly the crash is and once things become unpredictable leakage (even between go-routines) is not to be ruled out categorically. Think of erlang processes to be about as well isolated as unix processes and think of go processes to be a bit more isolated than unix threads but not much more. The trick here is that erlang is essentially an OS inside a process and that go-routines are co-operative multi-tasking inside a process aided by one or more cpu threads. That's a lot closer to the C multi-threading model than erlang and that implies there are some risks.
        troutwine 12y ago
        It's worth noting that Erlang is only a soft-realtime language. I wouldn't bet my nuclear plant and only some assembly lines on it. (There's plenty I do bet on Erlang, though.)
        jacquesm 12y ago
        That's valid, hard real time problems require guarantees that erlang can't give, that was an unwarranted exaggeration on my part. But anything that needs to be very long running (years or more) will need ironclad guarantees that it won't be leaking resources and I can't prove but suspect that erlang will do a lot better than go for those applications. Let's leave the nuclear plants and the assembly lines to RTos and QnX then :).
orblivion 12y ago
You'd also need to assert every time you called a function to make sure you got what you expected. I know basically nothing about Go, but I found this that says that it doesn't even have assertions: http://golang.org/doc/faq#assertions http://golang.org/doc/faq#assertions