[HN Gopher] Go beyond Goroutines: introducing the Reactive paradigm
___________________________________________________________________
Go beyond Goroutines: introducing the Reactive paradigm
Author : samber
Score : 18 points
Date : 2025-10-20 14:04 UTC (7 days ago)
(HTM) web link (samuelberthe.substack.com)
(TXT) w3m dump (samuelberthe.substack.com)
| skeptrune wrote:
| My understanding was that Go intentionally avoided patterns like
| this to improve readability.
| samber wrote:
| IMO, this is much more readable.
|
| So many Go developers ignore some tools because they consider
| them "not idiomatic".
|
| But why not use abstractions when available ??? Did we forget
| to be productive ?
| brudgers wrote:
| What makes sense depends on the agreement of the programming
| team.
|
| And the smallest possible team is the programmer and their
| future self.
|
| Even then the hard thing is to predict what will be better
| for our future selves. Maybe we will be rusty in our Go
| skills or maybe we will have embraced idiomatic Go, and the
| approach that makes sense now will require our future self to
| puzzle through the code.
|
| Of course maybe we will have kept programming the same way
| because it still feels like the better way and our future
| self will be efficient. But again that's only for the
| smallest possible team. If the team expands, then all bets
| are off.
| tuetuopay wrote:
| Sometimes it feels like that Go mistakes readability for
| comprehendability. Sure, I can read every single line of Go
| I've ever read. But can I comprehend the bigger picture? Can I
| understand why? Isn't the actual meat buried under piles of
| non-abstraction?
|
| This is precisely the premise for their library: I don't have
| the mental context to fit all the boilerplate in, nor do I have
| the brainpower to sift through it.
|
| Sure, assembly is readable: every line is one machine
| instruction. But that's way too many details. On the other
| hand, C++ templates are not enough details.
| Xeoncross wrote:
| I'm interested, but when I see a large coordination system
| sitting on top of any language's primitives, I'm immediately
| curious what kind of overhead it has. Please add some benchmarks
| and allocation reports.
| jzelinskie wrote:
| I'm curious if someone could chime in on the state of adoption of
| these these Rx libraries in other language's ecosystems.
|
| My poor memory seems to recall them gaining traction ~10 years
| ago, but they've fallen hard off my radar.
|
| My fear with adopting a library like this for Go is actually that
| it might end up being very unfriendly to the profiler once
| bottlenecks start occurring.
| mickael-kerjean wrote:
| I use rxjs day in day out for my oss work (eg:
| https://github.com/mickael-
| kerjean/filestash/blob/master/pub...) It's quite common to see
| job description where I live (Sydney) with rxjava but reactive
| libs are a bit of a niche thing mostly because it takes a bit
| of time to get used to it + not many people talk about it but
| it's not sexy
| candiddevmike wrote:
| This looks like it uses the unsafe library, proceed with caution
| dingdingdang wrote:
| Think this looks beautiful, any idea as to the performance
| penalty vs say the new wg.Go(func({doSomething()}) sugared syntax
| in Go 1.25?
| lelandbatey wrote:
| The explanation of RxGo being "wrong" or "out of order" seems
| very confusing? The case labeled "wrong" might aesthetically not
| look good, but from a data dependency perspective it seems
| totally valid to me. Why is it not valid to have the producer
| (map-A) resume and immediately do work "before" the consumer
| starts doing its work? Like, isn't that the point of breaking the
| "worker" bits up into separate functions? If I wanted the output
| of the `ro.Map()` example, wouldn't I just... not have map-A and
| map-B be separate functions?
___________________________________________________________________
(page generated 2025-10-27 23:00 UTC)