Re: [go-nuts] Re: Exposing newcoro/coroswitch

[Robert Engels]

Also, there’s this project in Go that looks interesting https://github.com/sourcegraph/conc On Feb 25, 2025, at 7:17 AM, Robert Engels <reng...@ix.netcom.com> wrote:  Hi Jason. I don’t think I was clear. I think a parser implementation is a natural fit for a generator - a generator being a specialization of a coroutine. The message I was responding to was the request to open the co routine facility that powers it. That’s what I was going against. I agree that managing the go routines for a generator case would be a pain - which is why I’ve come to agree with its inclusion. For the general concurrency case I think Go routines provide everything needed and co routines are unnecessary.  As for structured concurrency, I think the wiki gives a decent overview https://en.m.wikipedia.org/wiki/Structured_concurrency And for more in-depth, this is a great read (in Java but it’s fairly generic) exceptions make it a little more complex than needed in go. https://openjdk.org/jeps/453 On Feb 25, 2025, at 5:57 AM, Jason E. Aten <j.e.a...@gmail.com> wrote:  On Tuesday, February 25, 2025 at 4:29:44 AM UTC Robert Engels wrote: You don’t need co routines if you have real concurrency. The generator use case is simply an optimization that wouldn’t be necessary if the concurrency model was more efficient - and there was a more expressive way to use it. Hi Robert, I always enjoy your thoughts and perspective on these things. I certainly agree that, strictly speaking, you don't need coroutines when you have goroutines. But, having implemented a lexer and parser with goroutines instead of coroutines (e.g. https://github.com/glycerine/zygomys/blob/master/zygo/parser.go and lexer.go) I strongly suspect that coroutines would make for... a much "nicer" architecture.  The resulting lexer and parser back-and-forth I suspect, would be easier to read,  understand, modify, and use. In fact, I hope to re-write that code using coroutines in the near future because of this.  Having a ton of different parsing goroutines running in the background, and  shutting them down when not needed, and starting them up again, when needed again, simply makes for alot of "goroutine managment" hassle that it appears could be trivially avoided with coroutines. Or, perhaps there is a simpler way to use goroutines to do parsing that I did not discover--and that you have in mind. I'd be curious to see what that would look like.  Feel free to suggest how to refactor that lexer and parser code while still using only goroutines, if it helps to make the ideas less abstract  and more concrete. Best regards, Jason   I think the Java loom project has proved that the Go concurrency model is ideal. Reading up on “structured concurrency” is a great exercise.  p.s. if you have resources/links in mind about "structured concurrency", I'd be interested to look into them.  -- 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 visit https://groups.google.com/d/msgid/golang-nuts/8f12ea21-0d26-4864-8a08-a6c558a10ed7n%40googlegroups.com. -- 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 visit https://groups.google.com/d/msgid/golang-nuts/F90571DB-277A-443A-BDE4-0D7A614CF2F1%40ix.netcom.com. -- 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 visit https://groups.google.com/d/msgid/golang-nuts/E7368238-3921-4DB7-90C6-085B6E91A67E%40ix.netcom.com.