Hacker News new | ask | show | jobs
by MetaCosm 4444 days ago
... having channels doesn't have anything to do with Reactive Programming (http://en.wikipedia.org/wiki/Reactive_programming). The implication that channels were added to Go to support it seems dishonest.

There is a very long thread on the Go list of a guy who is a fan of dataflow grumbling about how design decisions made in Go make it a poor fit for dataflow.
2 comments
bkirwi 4444 days ago
Sadly, 'reactive' -- like OOP -- seems to be one of those words that gets reinterpreted to meaninglessness. The definition I'm most familiar with, from the Reactive Manifesto,[0] seems like it would fit Go's channels just fine... but anything that puts Go and Erlang and Node.js in the same box might be too broad to be useful.

[0] http://www.reactivemanifesto.org/#reactive-applications

link
pauldino 4444 days ago
Maybe I'm missing something but that manifesto doesn't seem to have anything at all to do with reactive programming, except that maybe you could use reactive programming to help build "reactive applications".
link
amirouche 4444 days ago
> having channels doesn't have anything to do with Reactive Programming

Mostly agree, in the sens that, from my limited pratical experience & knowledge of Reactive Programming (RP), I understand that RP isn't bound to a particular "parallel execution model" (maybe s/parallel execution model/threading model/ ?).

> There is a very long thread on the Go list of a guy who is a fan of dataflow grumbling about how design decisions made in Go make it a poor fit for dataflow.

I can't find it in https://groups.google.com/forum/#!searchin/Golang-nuts/React...

A blog post might be better fit for that (so far I was unsuccessful getting constructive feedback that way). Anyway here are more thought, based on my experience dealing with GUI app:

- "parallelism", even if simpler with an event-loop, is still a significant burden especially when performance matters

- Class based OOP, especially not JavaScript, is very helpful to group a sequence of callbacks to help fight spaghetti code.

- Explicit State Machines are a praised black art wrongfully dubbed useless overhead because "it's possible to do otherwise"

- «yield/await/async» as been recently recognized broadly as the way forward cf. https://news.ycombinator.com/item?id=4732924

All the points mentionned above have in common that they try to handle correctly with fine grained priority and different "paralellism" patterns with ease.

RP mean to provide much more than "yield", it's pattern that is similar to the explicit state machine intent. The declarative paradigm/syntax arguably provides an ease of use that is competitive both in terms of performance and dev efforts even if mileage may vary. See by yourself:

>>> HackerNewsPost.rank = HackerNews.upvote_count * MAGIC_NUMBER

This one might be better expressing the actual behavior, even if the ranking algorithm is "hidden":

>>> HackerNewsPost.on_change(HackerNewsPost.position).update(HackerNewsPost.rank).maximum_frequency(timedelta(seconds=60*60))

The above can not be expressed in "one line" using "yield" and whatnot.

May be of interest to you:

- https://speakerdeck.com/ryanartecona/a-unified-model-of-asyn...

- http://swannodette.github.io/2013/12/17/the-future-of-javasc...

- Observable/Observer, pub/sub & signaling patterns

- Search for "AngularJS performance issues"

- http://en.wikipedia.org/wiki/UI_data_binding

Reactive Programing can abstract the underlying "threading model" and all the above patterns... I am biased.

edit: typo & more rigorous "API" in second one-liner

link