L'objectif était justement de faire le lien entre tout ce qu'on peut lire aujourd'hui sur le réactif et le fait que ça prend ses racines dans des choses qui ne sont pas particulièrement récent (j'ai bien décris à quel moment chacun de ses appels est apparu justement).
Aucun de ces deux exemples n'utilisent de la programmation événementielle.
Elixir par construction se base sur le système à acteurs d'erlang qui est une manière évènementielle de coder.
Pour MigratoryData, c'est basé sur du publish-subscribe qui est classé dans l'event driven programming sur wikipedia.
Après je n'ai pas caché qu'il y a d'autres solutions, j'ai dis explicitement que je m'intéressais à l'une d'entre elles.
Je me rappelle qu'il y a quelques années, vers 2010-2012, je m'intéressais à la programmation événementielle, d'abord avec EventMachine en Ruby, puis avec Node.js. Mais, ça donnait du code compliqué[...]
Ça peut devenir plus compliqué, je suis d'accord, mais les API comme Rx sont très populaires aujourd'hui et je trouve que les Functional Reactive Programming sont plutôt lisible (voir elm par exemple, même si ça n'est pas pour du serveur).
D'ailleurs, je trouve intéressant l'entretien avec Ryan Dahl, créateur de Node.js, où il explique que Go a un meilleur modèle d'IO que nodejs pour les serveurs. Voici une citation rapide, mais il y a plus de détails dans l'entretien complet :
That said, I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever.
Tout ce que je vois dans l'article c'est de dire que les coroutines c'est mieux que les callback-hell, mais il y a bien d'autres API sur de l'asynchrones (les futures, les promesses, les observables,...). Il dit lui même que l'introduction du mot clef "async" doit avoir changer ce problème.
[^] # Re: Retour vers le passé
Posté par barmic . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 7.
L'objectif était justement de faire le lien entre tout ce qu'on peut lire aujourd'hui sur le réactif et le fait que ça prend ses racines dans des choses qui ne sont pas particulièrement récent (j'ai bien décris à quel moment chacun de ses appels est apparu justement).
Elixir par construction se base sur le système à acteurs d'erlang qui est une manière évènementielle de coder.
Pour MigratoryData, c'est basé sur du publish-subscribe qui est classé dans l'event driven programming sur wikipedia.
Après je n'ai pas caché qu'il y a d'autres solutions, j'ai dis explicitement que je m'intéressais à l'une d'entre elles.
Ça peut devenir plus compliqué, je suis d'accord, mais les API comme Rx sont très populaires aujourd'hui et je trouve que les Functional Reactive Programming sont plutôt lisible (voir elm par exemple, même si ça n'est pas pour du serveur).
Tout ce que je vois dans l'article c'est de dire que les coroutines c'est mieux que les callback-hell, mais il y a bien d'autres API sur de l'asynchrones (les futures, les promesses, les observables,...). Il dit lui même que l'introduction du mot clef "async" doit avoir changer ce problème.