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

11–20 of 43 posts

Re: Go beyond Goroutines: introducing the Reactive paradigm

#11

Post by tuetuopay »

skeptrune wrote: post #2

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

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.

Re: Go beyond Goroutines: introducing the Reactive paradigm

#12

Post by teeray »

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.

Re: Go beyond Goroutines: introducing the Reactive paradigm

#13

Post by schmichael »

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/22b84c8296c01c4085e8913944...

Not to mention heaps of reflection and panics: https://github.com/samber/ro/blob/22b84c8296c01c4085e8913944...

The functionality and expressiveness might be fantastic, but I would evaluate it very carefully before use.

Re: Go beyond Goroutines: introducing the Reactive paradigm

#15

Post by jonathrg »

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 supposedly good examples. It contains the kind of constructions I expect to see when working on a Go codebase, and it will be easier to modify correctly for another Go developer coming in later. Please, work with the language instead of forcing it to wear a programming paradigm it doesn't like.

Re: Go beyond Goroutines: introducing the Reactive paradigm

#16

Post by taeric »

lelandbatey wrote: post #9

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 am curious on this. My reading was largely that this seemed to be a side effect of the format message, and not something that is in your control?

Re: Go beyond Goroutines: introducing the Reactive paradigm

#17

Post by imiric »

tuetuopay wrote: post #11
skeptrune wrote: post #2

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

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. Su…

> But can I comprehend the bigger picture? Can I understand why? Isn't the actual meat buried under piles of non-abstraction?

The way you approach this in Go (and I would argue in any other language) is by building small abstractions when and if it makes sense to do so. Not by introducing abstractions early, or in order to make a piece of code slightly easier to follow. A simple comment might help to explain tricky logic, but otherwise you shouldn't need explanations about core language features.

Abstractions are not free. They can be poorly written, leaky, abstract too much or too little, inflexible, increase overall complexity and thus cognitive load, impact performance, introduce bugs, etc.

So relying on them only when absolutely necessary is often the sensible choice.

Also, if possible, building your own bespoke abstraction is often preferable to using an external package. You can tailor it to your exact use case, without adding another dependency, which carries its own risks and problems.

This specific package seems designed to be syntax sugar over language features, which is not a good idea for future maintainers of the code that uses it. They would need to understand how this 3rd-party library works, even if the author claims it to be more readable, ergonomic, or what have you.

Re: Go beyond Goroutines: introducing the Reactive paradigm

#18

Post by alain_gilbert »

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 how he kept "tabs" (and display it as 9 spaces) to make it as ugly as possible for the bad example, then proceed to use 4 spaces for the other examples.

Re: Go beyond Goroutines: introducing the Reactive paradigm

#19

Post by eikenberry »

Decent idea, but much to big a library. Would have been better to just have the core primitives/plumbing w/o the library of all the different operators/filters/etc. Allow the user to implement the logic, use the library for the piping to hook them together.

Re: Go beyond Goroutines: introducing the Reactive paradigm

#20

Post by schmichael »

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 of its GC and preemptive scheduler. Seems like the sort of thing an LLM would slip in because it sounds good and nails that 3 item cadence.

> Built on top of Go channels → broken backpressure.

But then the example is about ordering. Maybe I'm being pedantic or missing the specific nomenclature the ReactiveX community uses, but backpressure and ordering are different concerns to me.

Then the Key Takeaways at the end just seems like an LLMism to me. It's a short article! Do we really need another 3 item list to summarize it?

I'm not anti-LLM, but the sameness of the content it generates grates on me.

Post reply on HN