I had in mind a goroutine that receives commands for channel-like operations and implements them itself. So it would have a list to store the sent values, a sticky value variable, lists of receive commands (containing the channel to send a value back on), and lists of receive-full commands (containing the channel to send the values back on). It would loop on selecting for incoming commands, and behave accordingly. It’s not as efficient as having the behavior built in, no doubt, but probably simpler to implement.
> On Nov 2, 2025, at 5:34 PM, Jason E. Aten <[email protected]> wrote: > > On Sunday, November 2, 2025 at 10:42:50 PM UTC Will Faught wrote: > Looks interesting! Is there an article somewhere that explains why each > change to Go was necessary for DST? For example, why are sticky channel > values required for DST? > > Hi Will, > > Thanks! They aren't. Both are just things I wished for. :) Thanks for asking. > I may add a note to clarify that. > > Couldn’t sticky values be simulated with a goroutine that owns sending on a > channel that implements the sticky/unsticky/clear behavior? > > I'm not sure what you are thinking of with a goroutine somehow "owning" a > channel...? > > I certainly have been thinking about how to do ownership, since it is > clear that Go could benefit from Pony/Rust like ownership > checking to prevent data races, and having an "owner" type that the runtime > could > change and check would be an obvious approach. But I'm not sure how... let > me know if you have ideas. > > I did try to do "closing values" (in https://github.com/glycerine/loquet) > without > hacking on the runtime, but I got to many races. You > really do want the broadcast value to come "over the channel", not alongside > it. > > Isn’t it possible in general to arrange to not close a channel more than once? > > Of course -- I wrote https://github.com/glycerine/idem to do that in 2017. > > My feeling was it should not need to be that heavy weight. > > Any time you see a huge number of workarounds (all > of the sync package facilities, cannot substitute for condition variables, > integrates > poorly with wait groups and condition variables), it should be a sign that > your design > primitives are not strong or orthogonal enough-- you are only rally covering > a sub-space > (in the linear algebra sense) of the actual need-space. > > Cheers, > Jason > > > >> On Oct 30, 2025, at 12:48 AM, Jason E. Aten wrote: >> > >> If you ever wished for >> >> + better Deterministic Simulation Testing (DST) support, or >> >> + that channels could replace Condition Variables, or for >> >> + a sync.WaitGroup alternative that could be interrupted by a timeout, or >> that >> >> + channel close could be idempotent and broadcast a non-zero value, >> >> then I invite you to experiment with my superset-of-Go experiment, Pont. >> >> https://github.com/glycerine/pont >> >> Feedback welcome -- post an issue on the repo. >> >> Jason > > > -- > 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 [email protected] > <mailto:[email protected]>. > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/9d26d464-e322-4220-925a-1e933bbfe812n%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/9d26d464-e322-4220-925a-1e933bbfe812n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/90E0C795-84E4-47AA-BA62-24D2A61CEE80%40willfaught.com.
