4 ms·
I think providing a language construct to help you do something badly and covering up your mistakes by rebooting is a step in the wrong direction. Surely, you
by Jabbles 15y ago
I think providing a language construct to help you do something badly and covering up your mistakes by rebooting is a step in the wrong direction.
Surely, you can debug your programs, but catching slow leaks in complex software is hard, even in Go.
I don't think this warrants restarting your goroutines. Go is still a young language, who knows what tools for debugging will come along in the future.
- masklinn 15y agoIt depends what you're building. If what you're building is something which should never fall over and die, and you can afford to (because the interesting applicative state is stored elsewhere) kill-and-restart is a perfectly valid strategy. It is in fact one of the standard strategies in erlang supervision trees: a subtree crashed, log the signal somehow and spawn a new subtree. No point in interrupting the service if you don't absolutely have to. If you have memory leaks in a subtree, you can just kill it and let things recover in a standard manner, while you're investigating the cause of the leak (or not, you may have more important stuff to do) > Go is still a young language, who knows what tools for debugging will come along in the future. While that's true, Go has not exactly been at the forefront of language innovation so far and I've yet to see truly good tools for memleak investigation and debugging in more innovative languages...
- jganetsk 15y agoI think providing a language construct to help you do something badly and covering up your mistakes by rebooting is a step in the wrong direction. That's a huge part of the Erlang philosophy.