I don’t think that is relevant. It is very difficult to do chaining with Go’s error model. You can pass a shared context to every node and store the error in the context and protect against concurrent access. It’s doable but not easy.
Map/reduce and most functional patterns are easily represented using chains. But like I said, I would use panic/recover in the framework to make it easier. > On Aug 11, 2022, at 3:27 PM, Jan Mercl <0xj...@gmail.com> wrote: > > > > >> On Thu, Aug 11, 2022, 21:36 Robert Engels <reng...@ix.netcom.com> wrote: >> I’d say it certainly highlights a problem with Go’s error model. Exceptions >> would fit nicely here - instead it seems you needed to ignore all error >> handling - because chaining is impossible with error returns. > > > It's okay if someone prefers the way Java does things, but the best thing > about Go is IMHO that it is not Java. And I still hope it stays away from > becoming Java as long as possible. > >> >> A streams api with panic/recover is needed. >> >>> On Aug 11, 2022, at 12:55 PM, K. Alex Mills <k.alex.mi...@gmail.com> wrote: >>> >>> >>> Hello Gophers, >>> >>> I recently had an opportunity to try out Go generics on a small pipelines >>> package, along with some of my coworkers. >>> >>> The overall goal of this package is to provide helpers for separating >>> concurrency from the core logic of the computation. The result was intended >>> for I/O bound computations, and so it's likely inappropriate for managing >>> short-lived goroutines. It takes a functional programming approach, >>> providing helpers with familiar names seen in other APIs like Map, FlatMap, >>> OptionMap, etc. One feature which I am particularly happy with is that >>> concurrency concerns like worker pool size and channel buffers are >>> configurable with minimal disruption to the rest of the code. >>> >>> Take a look at the library and its accompanying blog post. I'm open to any >>> of your thoughts, suggestions, and issue reports. >>> >>> Sincerely, >>> >>> K. Alex Mills >>> -- >>> 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 on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/CALJzkY_zASs-YOukv6ciSO45b93jz39DmjAWA915kfBuwimkgQ%40mail.gmail.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 on the web visit >> https://groups.google.com/d/msgid/golang-nuts/6954C3FB-0E78-4922-8889-90FA58BA3F16%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 on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAA40n-WfWSMbV8p79xXGbS2%2BQ0M8pQfUPupqGnzGAdbo%2BTx0JA%40mail.gmail.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 on the web visit https://groups.google.com/d/msgid/golang-nuts/04C53843-FD4F-4701-A546-33DBCB9C259B%40ix.netcom.com.
