On Thursday, 18 February 2021 at 04:01:47 UTC ren...@ix.netcom.com wrote: > Go - whether people like this or not - is VERY close to Java (because of > the “runtime”) - and both suffer from “runtime overhead/startup cost” >
I have used one-shot Java CLI tools that take literally 4 or 5 seconds to start up (Kafka CLI for example); Go tools are more like 5ms in my experience, thanks to being compiled ahead-of-time into native code. So I don't think that's a fair comparison. I think we may be discussing a different use case here. In the Unix world, if you want something to be resilient against a total process crash, then you spawn it as a child, you supervise it, and restart it if necessary. What you get back is not so much an exception, as an exit code. Among programming languages, the one I can think of with a similar concept is Erlang, which provides for a process supervision tree. Erlang processes <https://erlang.org/doc/reference_manual/processes.html> are the equivalent of goroutines. A process terminates with an exit reason <https://erlang.org/doc/reference_manual/processes.html#process-termination>. You can link <https://erlang.org/doc/reference_manual/processes.html#links> related processes together. Patterns in go which provide for similar supervision trees of goroutines would be an interesting area of study. (Note that in Erlang you tend to use processes for more than just concurrency. There is no variable rebinding, so you need a function to call itself recursively to model mutable state: so you stick that function in a process and send messages to it) However, I think the types of errors being discussed in this thread are just part of sequential code operation. For example, when you open a file: * it may be successful, you get back a file handle * there may be a "normal" failure because of user-supplied data, e.g. "a file with that name does not exist" * there may be a "system" failure, e.g. "I/O error on disk" When you read from the open file, similarly there are other errors: e.g. "I expected that file to contain valid JSON, but it doesn't". These cases need to be distinguished and handled somewhere. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/08ab4673-ae1c-4f24-9890-0805ed4f4dd8n%40googlegroups.com.
