Status of go-sup?

[marco-m]

Hello, coming from Erlang, I naturally looked for Go equivalents of Erlang supervisors, so I found also this package. I would like to know its status: are you using it or aware of somebody using it? According to pkg.go.dev, it seems not imported by any (public) project. Would you suggest another approach/package today? Thanks

[warpfork]

I have some code which uses it and has worked well enough I've never rebuilt it.

I don't know of anything better. Not for lack of wanting it.

I've also kicked around other variations of this code periodically in spare time over the years, trying to get a more ergonomic API / better debugging under all cases (including in response to SIGQUIT) / trying to make it more foolproof. That's been... easier said than done.

I'll be happy to push my latest to a branch if someone else wants to run with it.

I'm not sure I'm too likely to keep working on this topic, otherwise. I'm writing considerably less golang now than I did a few years ago. The type system and the error handling has just be too recurrently painful to me, in general. This topic of supervisors, more specifically, seems extremely difficult to solve ergonomically without the use of macros (you really need a select in a lot of places to be fully correct, and those are a huge amount of syntax-heavy boilerplate to throw at a user... and you if you want to do it as a library, you can do it with reflection, kindasorta, but now your syntax is getting even farther from the norm, and generating tons of garbage objects, and and and... it's just... oof), or some other language features that we simply don't have.

it's very difficult to have nice things in golang :sweat_smile:

[warpfork]

I've just pushed my last work to the https://github.com/warpfork/go-sup/tree/v6-dev branch, in case it's of interest.

It was a pretty total rewrite, and perhaps not entirely finished, but I think improved on a lot of things. I'd probably pick up from there if trying to get further on this.

It looks like the "pingpong_noguards" test completely works and demonstrates how to use it.

There's also something called "pingpong_guarded" which was... trying to go the way of having those reflect-based features I mentioned, aiming to save some boilerplate and be more resilient against bad constructions. It's... unfinished.

The "promise" feature looks really nice! (I'm... sort of mentally paging this back in myself, right now. :)) It looks complete, and stands alone nicely. It supports generics. It's quite efficient. It looks like it's well tested and also plays nicely with the race detector. I think I'd use this! And the documentation seems very complete about how to avoid problematic compositions (e.g. what hooks need to avoid blocking, etc).

There's probably a lot of other rough edges, though. I've fixed a few todos already in the last few minutes just dusting it off, so no doubt there's more.

[marco-m]

Thanks a lot for the update and the rationale within. I'll come back with my feedback once I have played a bit with this package. I plan at least to propose an example for a newcomer to get started or to get a feeling of how to approach the API.

Sometimes Go frustrates me too, but I stick to it because it frustrates me less than other languages or because I find that it still has the best trade-offs wrt complexity at scale...

[warpfork]

Sounds good :) Honestly, if you come back holding some strong opinions about the ergonomics and naming you'd want, but otherwise interested with the approach, I'd probably be nerd-snipe'able into helping get it where you want it to be. (Looks like half the things tiring me out last time I put that branch down were just API naming decisions, heh...)