Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go beyond Goroutines: introducing the Reactive paradigm

samuelberthe.substack.com

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Go beyond Goroutines: introducing the Reactive paradigm

#21

Post by api »

schmichael wrote: post #13

The supposedly bad example is perfectly readable to anyone familiar with Go. A bit of refactoring into first class functions, and you'd have an easy to read, idiomatic, easy to test, well typed code base with obvious places to adjust useful behaviors like concurrency limits. Meanwhile the samber/ro example is incomplete (Subscribe(...)?), and the source includes some weird stuff: https://github.com/samber/ro/blob/22b…

I’ve come to believe that a direct implementation of something in the language is, where possible, more readable and maintainable in the long term.

Libraries that enable terse seemingly magical things tend to just hide a lot and make code harder to read. You end up having to become an expert in what amounts to a DSL on top of the language.

Re: Go beyond Goroutines: introducing the Reactive paradigm

#22

Post by adamwk »

I think this article does an alright job selling ro over RxGo, but doesn’t really explain why using a reactive library is better than plain go. The channel/goroutine example is fine, as they say, but they hand wave how this will fall apart in a more complex project. Conversely, their reactive example is mapping and filtering an 4 item array and handwave how the simplicity will remain no matter the size of the codebase.

I’ve worked in a few complex projects that adopted reactive styles and I don’t think they made things simpler. It was just as easy to couple components with reactive programming as it was without.

Re: Go beyond Goroutines: introducing the Reactive paradigm

#23

Post by jvans »

schmichael wrote: post #13

The supposedly bad example is perfectly readable to anyone familiar with Go. A bit of refactoring into first class functions, and you'd have an easy to read, idiomatic, easy to test, well typed code base with obvious places to adjust useful behaviors like concurrency limits. Meanwhile the samber/ro example is incomplete (Subscribe(...)?), and the source includes some weird stuff: https://github.com/samber/ro/blob/22b…

i like reactive programming in other languages but it is at odds with Go's philosophy of simplicity and avoiding big abstractions

Re: Go beyond Goroutines: introducing the Reactive paradigm

#24

Post by jvans »

jzelinskie wrote: post #6

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.

it's used extensively in java and it would be my first choice when starting a java project. I don't think I'd use it in Go though.

Re: Go beyond Goroutines: introducing the Reactive paradigm

#26

Post by [deleted] »

teeray wrote: post #12
skeptrune wrote: post #2

My understanding was that Go intentionally avoided patterns like this to improve readability.

It wasn’t to improve readability—it was for performance. There is no question what is happening in a triple-nested for loop. Once you start hiding it behind deeply-nested function calls, you get hidden performance penalties. If you have a functional language that is actually able to do some of this lazily, great, but that’s not Go.

[deleted]

Re: Go beyond Goroutines: introducing the Reactive paradigm

#28

Post by mindcrime »

schmichael wrote: post #20
jonathrg wrote: post #15

It's really tough to read through a text where you can't go more than a few sentences without having something be described as *an adjective, a second adjective, and a third adjective*. Just let the code example speak for itself, man. Speaking of the code examples, I am not convinced at all. The supposedly bad example is idiomatic and understandable to me, and I have a much better idea of what's going on than in the…

It has to be AI generated or at least edited right? The reliance on bulleted lists. The endless adjectives and declarations. ...but also the subtle... well not exactly errors, but facts I think are open to dispute? Such as: > Together, these tools make Go perfect for microservices, real-time systems, and high-throughput backends. Real-time systems?! I have never heard of anyone using Go for realtime systems because o…

I have never heard of anyone using Go for realtime systems because of its GC and preemptive scheduler.

I don't know. I've seen "realtime" used quite often in a sort of colloquial sense, where it means something fairly different from "hard realtime system" as an embedded systems person might use the term. I think there's a pretty large base of people who use "realtime" to mean something that others might call "near real-time" or just "continually updating" or something along those lines, where's there's no implication of needing nanosecond level predictable scheduling and what-not.

That's not to say that the article isn't AI generated, or whatever. Just that I wouldn't necessarily see the use of the "realtime" nomenclature as strong support for that possibility.

Re: Go beyond Goroutines: introducing the Reactive paradigm

#29

Post by maxpert »

I am sorry I might be a little naive here. The hardest thing about RxJava or RxJS was actually understanding the reactor pattern and then the nuances of threading (in Java) and how it made simple linear looking code callback hell. Go from ground up was built on promise of having the simple no-callback hell code that will be easy to read on eyes. Why do we keep going back to these pattern that over long term have proven to be hard to debug, thus hard to maintain well. Go is not even good at syntactic sugar like couple of other languages that might make it easy, why are people so excited about this? Should the reactivity and yielding of a go routine be taken care of under the hood?

Edit: I've maintained a full codebase with R2DBC and I can assure you many developers came scratching their heads to me sometimes on tell me why are we doing this again when we can only have finite connections to DB and those connections can be 1-1 mapped to worker threads.

Re: Go beyond Goroutines: introducing the Reactive paradigm

#30

Post by rileymichael »

jvans wrote: post #24
jzelinskie wrote: post #6

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.

it's used extensively in java and it would be my first choice when starting a java project. I don't think I'd use it in Go though.

reactive is on the decline in the java world post-loom (virtual threads) and should be nobody's first choice. writing plain old imperative code is vastly simpler to write / debug / reason about.

Brian Goetz even went as far as saying loom is going to kill reactive entirely: https://www.youtube.com/watch?v=9si7gK94gLo&t=1165s

Post reply on HN