Elixir par construction se base sur le système à acteurs d'erlang qui est une manière évènementielle de coder.
Je suis un peu perdu, mais pour des serveurs, si les systèmes à base d'acteurs/goroutines/green threads sont des manières événementielles de coder, qu'est-ce qui ne l'est pas ?
De mon point de vue, il y a d'un côté la programmation événementielle, avec un seul thread, une boucle événementielle et des callbacks (potentiellement abstraits via des promises, futures, observables). Et de l'autre côté, on a des modèles qui s'exécutent sur plusieurs threads et du parallélisme. Nodejs est dans la première catégorie, Elixir et Go dans la seconde.
Pour les serveurs où les performances (et notamment la latence) sont importantes, j'ai l'impression que le premier modèle est nettement en déclin (la hype, c'était plutôt vers 2010-2013), avec notamment beaucoup de Go. Nodejs a plutôt l'air de survivre auprès des développeurs Front (que ce soit pour des outils à la webpack, browserify, babel, etc. ou pour avoir le même code Angular/React/Vue qui tourne côté client et côté serveur).
Ç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).
Par contre, pour ce qui passe dans une interface graphique ou dans le navigateur, oui, là, je trouve que le modèle de programmation événementielle colle bien. Et ça a l'air plus vivant. Mais les raisons ne sont pas les mêmes et l'historique non plus (JavaScript en 1995, mais je crois que les débuts datent des bibliothèques graphiques de Smalltalk dans les années 80).
Il dit lui même que l'introduction du mot clef "async" doit avoir changer ce problème.
Non, il dit que JavaScript a fait des progrès, notamment avec le mot clef async, mais que le modèle du JavaScript reste inférieur pour les serveurs à celui de Go.
[^] # Re: Retour vers le passé
Posté par Bruno Michel (site web personnel) . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 5. Dernière modification le 06 mars 2018 à 18:51.
Je suis un peu perdu, mais pour des serveurs, si les systèmes à base d'acteurs/goroutines/green threads sont des manières événementielles de coder, qu'est-ce qui ne l'est pas ?
De mon point de vue, il y a d'un côté la programmation événementielle, avec un seul thread, une boucle événementielle et des callbacks (potentiellement abstraits via des promises, futures, observables). Et de l'autre côté, on a des modèles qui s'exécutent sur plusieurs threads et du parallélisme. Nodejs est dans la première catégorie, Elixir et Go dans la seconde.
Pour les serveurs où les performances (et notamment la latence) sont importantes, j'ai l'impression que le premier modèle est nettement en déclin (la hype, c'était plutôt vers 2010-2013), avec notamment beaucoup de Go. Nodejs a plutôt l'air de survivre auprès des développeurs Front (que ce soit pour des outils à la webpack, browserify, babel, etc. ou pour avoir le même code Angular/React/Vue qui tourne côté client et côté serveur).
Par contre, pour ce qui passe dans une interface graphique ou dans le navigateur, oui, là, je trouve que le modèle de programmation événementielle colle bien. Et ça a l'air plus vivant. Mais les raisons ne sont pas les mêmes et l'historique non plus (JavaScript en 1995, mais je crois que les débuts datent des bibliothèques graphiques de Smalltalk dans les années 80).
Non, il dit que JavaScript a fait des progrès, notamment avec le mot clef
async, mais que le modèle du JavaScript reste inférieur pour les serveurs à celui de Go.