3 ms·

> For example, you can't recreate this in Go or Rust because `panic` will kill your entire program unconditionally. You can recover() panic() just fine in Go.

by ilyt 4y ago

dmitriid 4y ago
These are like sledgehammers when you need a screwdriver. It's very hard to build Erlang-like versions of supervision trees using those tools.
- masklinn 4y ago
  > These are like sledgehammers when you need a screwdriver. Also by the very nature of Go your application state is as likely as not to be fucked, so even if you did handroll monitors and links, and thus could build supervision trees, they wouldn’t be of much use.
ramchip 4y ago
Yeah, OP took a shortcut here :) The nuance is that most languages let you build reliable programs _if your code is correct_ - if you're using defers, context handlers, finalizer, cleaning up state in shared data structure, etc. Erlang's goal is to be reliable "in the presence of software errors", that is, even if your code is buggy. If a request handler process dies inside an Erlang web app, whatever file or socket it opened, memory it allocated, shared resource it acquired (e.g. a DB connection) will be reclaimed. This is true without having to write any error handling in your code. The way it's done is that the VM handles the basic stuff like memory and files, and it provides signals that libraries (like a DB connection pool for instance) can use to know if a process fails and clean up as needed. In other words the process that fails is not responsible for its own clean up. At some point some code must of course be correct for this to work. Like, if the DB connection pool library doesn't monitor processes that borrow connections, it could leak the connection when such a process dies. But the point is that this part (the "error kernel") can be a small, well-tested part of the overall system; whereas in a classic program, the entire codebase has to handle errors correctly to guarantee overall stability.
komadori 4y ago
> You can recover() panic() just fine in Go. You can catch_unwind() panic!() in Rust too :-).

> For example, you can't recreate this in Go or Rust because `panic` will kill your entire program unconditionally. You can recover() panic() just fine in Go.

by ilyt 4y ago

> For example, you can't recreate this in Go or Rust because `panic` will kill your entire program unconditionally. You can recover() panic() just fine in Go.

dmitriid 4y ago

These are like sledgehammers when you need a screwdriver. It's very hard to build Erlang-like versions of supervision trees using those tools.

masklinn 4y ago
> These are like sledgehammers when you need a screwdriver. Also by the very nature of Go your application state is as likely as not to be fucked, so even if you did handroll monitors and links, and thus could build supervision trees, they wouldn’t be of much use.

ramchip 4y ago

Yeah, OP took a shortcut here :) The nuance is that most languages let you build reliable programs _if your code is correct_ - if you're using defers, context handlers, finalizer, cleaning up state in shared data structure, etc. Erlang's goal is to be reliable "in the presence of software errors", that is, even if your code is buggy. If a request handler process dies inside an Erlang web app, whatever file or socket it opened, memory it allocated, shared resource it acquired (e.g. a DB connection) will be reclaimed. This is true without having to write any error handling in your code. The way it's done is that the VM handles the basic stuff like memory and files, and it provides signals that libraries (like a DB connection pool for instance) can use to know if a process fails and clean up as needed. In other words the process that fails is not responsible for its own clean up. At some point some code must of course be correct for this to work. Like, if the DB connection pool library doesn't monitor processes that borrow connections, it could leak the connection when such a process dies. But the point is that this part (the "error kernel") can be a small, well-tested part of the overall system; whereas in a classic program, the entire codebase has to handle errors correctly to guarantee overall stability.

komadori 4y ago

> You can recover() panic() just fine in Go. You can catch_unwind() panic!() in Rust too :-).