Go beyond Goroutines: introducing the Reactive paradigm
samuelberthe.substack.com
Go beyond Goroutines: introducing the Reactive paradigm
1–10 of 43 posts
Re: Go beyond Goroutines: introducing the Reactive paradigm
#2My understanding was that Go intentionally avoided patterns like this to improve readability.
Re: Go beyond Goroutines: introducing the Reactive paradigm
#3My understanding was that Go intentionally avoided patterns like this to improve readability.
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 ?
Re: Go beyond Goroutines: introducing the Reactive paradigm
#4My understanding was that Go intentionally avoided patterns like this to improve readability.
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 ?
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.
Re: Go beyond Goroutines: introducing the Reactive paradigm
#5I'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.
Re: Go beyond Goroutines: introducing the Reactive paradigm
#6I'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.
Re: Go beyond Goroutines: introducing the Reactive paradigm
#7This looks like it uses the unsafe library, proceed with caution
Re: Go beyond Goroutines: introducing the Reactive paradigm
#8Think this looks beautiful, any idea as to the performance penalty vs say the new wg.Go(func({doSomething()}) sugared syntax in Go 1.25?
Re: Go beyond Goroutines: introducing the Reactive paradigm
#9The 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?
Re: Go beyond Goroutines: introducing the Reactive paradigm
#10I'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.
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 be proficient at it + not many people talk about it but it's not sexy