tutorial rxjava programming español scala observer-pattern reactive-programming

scala - rxjava - rxjs



¿Qué pasó con Scala.React? (2)

Citando a Li Haoyi,

Quien ha usado Scala.React, sus observaciones son:

  • "Es extremadamente difícil de configurar y comenzar".
  • "Requiere una buena cantidad de configuración global"
  • "Me tomó varios días hacer funcionar un gráfico de flujo de datos básico (...)".

Tenía muchas preguntas pero no logró ponerse en contacto con el autor de la publicación ...

Li también implementó un Scala.RX que aborda estos y otros problemas. El código está en buen estado, pero no puedo observar ninguna acción de insertarlo en la biblioteca Standard Scala. Además, Li es el impulsor del esfuerzo actual de Scala y Javascript, por lo que está más ocupado con ese proyecto.

Contestando tus preguntas:

¿Es la biblioteca JavaRx basada en Observable aconsejable?

JavaRx se basa en el patrón Observer que Martin Odersky intentó desaprobar ...

https://github.com/Netflix/RxJava/blob/master/rxjava-core/src/main/java/rx/Observer.java https://github.com/Netflix/RxJava/blob/master/rxjava-core/src/main/java/rx/Observable.java

Si bien cada cuestión que Martin señaló en el documento es verdadera y válida, Netflix había explotado una propiedad importante de Observables:

Futuros y observables comparten un isomorfismo, por lo tanto son compostables. En JavaRx, un Observable devuelve una secuencia de eventos. Sin embargo, un futuro, por otro lado, puede verse como un observable especializado que solo devuelve un singleton. En este caso, Futures y Observables se pueden componer asincrónicamente siempre que tenga sentido.

¿Hay una historia detrás de esto?

No tengo idea, pero quizás Netflix hizo algún patrocinio. Puede haber notado el logotipo de Netflix que aparece en los ejemplos de RX Diamonds ....

¿O podemos esperar algo similar o mejor de Typesafe?

Honestamente lo dudo. ¿Por qué deberían ellos? Typesafe está ocupado con empujar su pila en la industria y avanzar aún más Akka. Scala.React es una buena idea, pero no produce dinero en efectivo, mientras que Akka les ofrece clientes que pagan ...

En su lugar, me preguntaría qué es exactamente lo que Scala.React, después de todo, intenta resolver.

En mi humilde opinión, JavaRx ya hace un buen trabajo, está en producción y las mejoras que Scala.React podría agregar posiblemente no son suficientes para un cambio importante.

Leí el documento escrito por Odersky, "Deprecating the Observer Pattern with Scala.React"

El github parece abandonado:

https://github.com/ingoem/scala-react

Además, la reciente clase de Coursera de programación reactiva, utilizó la biblioteca JavaRx Observable (con soporte de Scala, por supuesto).

¿Hay una historia detrás de esto? Puedo suponer que scala.react simplemente no llegó muy lejos. ¿Es aconsejable la biblioteca JavaRx basada en Observable? ¿O podemos esperar algo similar o mejor de Typesafe?


RxJava: Reactive Extensions tiene muy poco en común con scala.react. RxJava se ocupa de los observadores y la concurrencia, pero ayuda muy poco de la exactitud del orden de evaluación. Básicamente se trata solo de flujos de eventos, y si los eventos se dividen en varios efectos, esos nunca serán coherentes de nuevo. Básicamente es un desastre y solo se puede usar para GUI donde la precisión en el cálculo no es tan crítica. Nunca se sabe cuándo se obtiene una actualización adicional o una actualización adicional.

scala.react es un modelo de computación con un único hilo y trata con el orden de cálculo con un orden de evaluación estricto que se define por las dependencias funcionales entre los cálculos.

Akka, o actores, de nuevo, es un tercer modelo y algo completamente diferente. Simplemente son hilos con una sintaxis y scheduli de lujo, realmente.

No es de extrañar que todos estén confundidos. Lamentablemente, scala.react no se ha movido a ningún lado, lo que es malo ya que es el único modelo innovador de estos tres.