"I'd have to say your idea of supervisors misses the point."
I think it's unfair to explain how I "missed the point" to me when I'm the one who brought it to your attention in the first place, when I called it out explicitly as a weakness, in the context of a post explaining how OTP can not be completely ported into Go without loss. I did after all explain in a parenthetical that I tried to fix it, realized the fix wasn't really a fix, and decided just to go simple and idiomatic after that.
The thing is, while it is sad that we lose that characteristic of supervisors, there are still other useful characteristics: Sensible restarts; naive restart code has a lot of pathological cases. I rather expect my library to ship with a couple at first too, but we (yay open source) can fix it in one place, once. Composition of supervisors is a great way to build applications, with self-contained pieces; the whole "hierarchy" still applies, though I find with the elimination of the restart strategies it gets a lot simpler, for better and for worse. It's still nice to be able to build code and easily slot it into a management system, even if it can't quite be as powerful.
A complete translation is impossible, but an idiomatic one may be, and I'm already finding it useful even in my little coding efforts.
As for the REPL... yes, that is an unmitigated loss, no question. I'm mitigating it in my personal app with a lot more flexible logging and some more external controls, but there is no true replacement for a REPL. Though... we may get a REPL someday, it just may be either a mere subdialect of Go or a separate scripting language. I've resisted putting a dependency on one of the very young Go scripting languages in my project, but theoretically in another year or two this might at least be mitigated.
I think it's unfair to explain how I "missed the point" to me when I'm the one who brought it to your attention in the first place, when I called it out explicitly as a weakness, in the context of a post explaining how OTP can not be completely ported into Go without loss. I did after all explain in a parenthetical that I tried to fix it, realized the fix wasn't really a fix, and decided just to go simple and idiomatic after that.
The thing is, while it is sad that we lose that characteristic of supervisors, there are still other useful characteristics: Sensible restarts; naive restart code has a lot of pathological cases. I rather expect my library to ship with a couple at first too, but we (yay open source) can fix it in one place, once. Composition of supervisors is a great way to build applications, with self-contained pieces; the whole "hierarchy" still applies, though I find with the elimination of the restart strategies it gets a lot simpler, for better and for worse. It's still nice to be able to build code and easily slot it into a management system, even if it can't quite be as powerful.
A complete translation is impossible, but an idiomatic one may be, and I'm already finding it useful even in my little coding efforts.
As for the REPL... yes, that is an unmitigated loss, no question. I'm mitigating it in my personal app with a lot more flexible logging and some more external controls, but there is no true replacement for a REPL. Though... we may get a REPL someday, it just may be either a mere subdialect of Go or a separate scripting language. I've resisted putting a dependency on one of the very young Go scripting languages in my project, but theoretically in another year or two this might at least be mitigated.