5 ms·

I'm a fan of the Rx programming model, but is it really worth it to introduce such a library and model into a language with such an opinionated and built-in mod

by dtech 10y ago

I'm a fan of the Rx programming model, but is it really worth it to introduce such a library and model into a language with such an opinionated and built-in model for streaming/pipelining and concurrency?

bsaul 10y ago
especiallt when the type system is so weak that you'll have to use interface{} everywhere. This library sums up a lot of the language's problem : channels aren't the final word on concurrency, and go needs at least some way of making reusable code in a type safe manner.
- mevile 10y ago
  This isn't true. You could use the adapter pattern and require that your reactive elements implement some kind of sane interface and then you're not using interface{} everywhere. It's not as flexible as generics but it's possible. This is how you do promises in go, with the adapter pattern.
  - malcolmgreaves 10y ago
    But then that interface needs to specify the behavior. And -- crucially -- ONLY that behavior. It's not possible in Go to say "this thing is unknown, but it will have a specific behavior (type) at compile time." interface{} says it is known type that has no behavior.
    - chewxy 10y ago
      Is that not the definition of what a interface is? If you want something that prints you define a printer interface that has exactly one method. Go highly encourages small interfaces
    - grey-area 10y ago
      In go: An interface says this thing is unknown but it has at least these known methods The empty interface means this thing is unknown and its methods are unknown The first is preferable and the second is not often used.
      - bsaul 10y ago
        The problem is we need the distinction between "author of the code" unknown ( in which case whatever symbol such as T is enough), and "user of the code" unknown ( in which case relying on dynamic casting or interfaces is fine). What go doesn't provide is 1/ unknown but 2/ not. Which happens when you're creating a lib to be used later.
camus2 10y ago
The streaming/pipelining is the least of the issues here. The impossibility to define a generic compile time safe API makes these kind of projects useless in practice. It's just impossible to write abstractions in Go in a compile type safe way. These untyped API just feel dirty for a modern statically typed language.
- christophilus 10y ago
  Yep. 100% agree. I think you have to treat Go as a dynamically typed system with some static typing thrown in, if you want to use it beyond its core use case.
  - dgellow 10y ago
    Yes! Thank you for saying this. If you think of go as a typed (and modern) Bash (the language, not the shell) everything makes sense :)
mevile 10y ago
If you don't want to use this nobody will force you. The overwhelming and unfortunately predictable heap of negativity that comes bearing down on people sharing something cool they made is really awful. Well someone has made this, and now you can decide if it's worth it for you as an individual to decide whether you like it or not and then if you don't, then don't use it.
- jsiepkes 10y ago
  Do you mean to imply the parent is being negative? I think its a perfectly valid question. Unlike languages like Java which only have concurrent primatives Go is very opinionated how about to do concurrency.
- dtech 10y ago
  I find it incredibly ironic and hypocritical that you accuse me of creating a negative environment... in a negative reply to a fairly neutral question. I don't use Go, but am a contributor to a Rx project for a different language. As such I am not interested in using this but genuinely curious about the potential (non)benefits of Rx in Go, especially given that they both promise to solve similar problems in very different ways. From experience HN is the prime place for such discussions. I think HN would be a much worse place if we would only be allowed to cheerlead projects here.
- omginternets 10y ago
  You're right, let's not discuss the merits of any technical solutions. The purpose of a comments section is to shower people with praise. This is because negativity is bad and positivity is good. And whatever we do, let's avoid discussing software design choices at all costs. Surely the gains in positivity will make us better programmers.
mpweiher 10y ago
I was wondering the same thing. "Reactive" is really just (misnamed[1]) dataflow[2], as far as I can tell, and Go has dataflow in spades. Of course, it would be nicer if Go's dataflow mechanism were adaptable/extensible in a Open Implementation style[3]. [1] "Reactive" is a type of system not an implementation, and you implement reactive systems using pretty much any programming/architectural style. http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.html http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.htm... [2] https://twitter.com/headinthebox/status/739915645811228672 https://twitter.com/headinthebox/status/739915645811228672 , http://www.inf.fu-berlin.de/lehre/SS13/Sem-Prog/material/ESTEREL.pdf http://www.inf.fu-berlin.de/lehre/SS13/Sem-Prog/material/EST... [3] https://en.wikipedia.org/wiki/Open_implementation https://en.wikipedia.org/wiki/Open_implementation

by dtech 10y ago

bsaul 10y ago

especiallt when the type system is so weak that you'll have to use interface{} everywhere. This library sums up a lot of the language's problem : channels aren't the final word on concurrency, and go needs at least some way of making reusable code in a type safe manner.

mevile 10y ago
This isn't true. You could use the adapter pattern and require that your reactive elements implement some kind of sane interface and then you're not using interface{} everywhere. It's not as flexible as generics but it's possible. This is how you do promises in go, with the adapter pattern.
- malcolmgreaves 10y ago
  But then that interface needs to specify the behavior. And -- crucially -- ONLY that behavior. It's not possible in Go to say "this thing is unknown, but it will have a specific behavior (type) at compile time." interface{} says it is known type that has no behavior.
  - chewxy 10y ago
    Is that not the definition of what a interface is? If you want something that prints you define a printer interface that has exactly one method. Go highly encourages small interfaces
  - grey-area 10y ago
    In go: An interface says this thing is unknown but it has at least these known methods The empty interface means this thing is unknown and its methods are unknown The first is preferable and the second is not often used.
    - bsaul 10y ago
      The problem is we need the distinction between "author of the code" unknown ( in which case whatever symbol such as T is enough), and "user of the code" unknown ( in which case relying on dynamic casting or interfaces is fine). What go doesn't provide is 1/ unknown but 2/ not. Which happens when you're creating a lib to be used later.

camus2 10y ago

The streaming/pipelining is the least of the issues here. The impossibility to define a generic compile time safe API makes these kind of projects useless in practice. It's just impossible to write abstractions in Go in a compile type safe way. These untyped API just feel dirty for a modern statically typed language.

christophilus 10y ago
Yep. 100% agree. I think you have to treat Go as a dynamically typed system with some static typing thrown in, if you want to use it beyond its core use case.
- dgellow 10y ago
  Yes! Thank you for saying this. If you think of go as a typed (and modern) Bash (the language, not the shell) everything makes sense :)

mevile 10y ago

If you don't want to use this nobody will force you. The overwhelming and unfortunately predictable heap of negativity that comes bearing down on people sharing something cool they made is really awful. Well someone has made this, and now you can decide if it's worth it for you as an individual to decide whether you like it or not and then if you don't, then don't use it.

jsiepkes 10y ago
Do you mean to imply the parent is being negative? I think its a perfectly valid question. Unlike languages like Java which only have concurrent primatives Go is very opinionated how about to do concurrency.
dtech 10y ago
I find it incredibly ironic and hypocritical that you accuse me of creating a negative environment... in a negative reply to a fairly neutral question. I don't use Go, but am a contributor to a Rx project for a different language. As such I am not interested in using this but genuinely curious about the potential (non)benefits of Rx in Go, especially given that they both promise to solve similar problems in very different ways. From experience HN is the prime place for such discussions. I think HN would be a much worse place if we would only be allowed to cheerlead projects here.
omginternets 10y ago
You're right, let's not discuss the merits of any technical solutions. The purpose of a comments section is to shower people with praise. This is because negativity is bad and positivity is good. And whatever we do, let's avoid discussing software design choices at all costs. Surely the gains in positivity will make us better programmers.

mpweiher 10y ago

I was wondering the same thing. "Reactive" is really just (misnamed[1]) dataflow[2], as far as I can tell, and Go has dataflow in spades. Of course, it would be nicer if Go's dataflow mechanism were adaptable/extensible in a Open Implementation style[3]. [1] "Reactive" is a type of system not an implementation, and you implement reactive systems using pretty much any programming/architectural style. http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.html http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.htm... [2] https://twitter.com/headinthebox/status/739915645811228672 https://twitter.com/headinthebox/status/739915645811228672 , http://www.inf.fu-berlin.de/lehre/SS13/Sem-Prog/material/ESTEREL.pdf http://www.inf.fu-berlin.de/lehre/SS13/Sem-Prog/material/EST... [3] https://en.wikipedia.org/wiki/Open_implementation https://en.wikipedia.org/wiki/Open_implementation