Ma vision des choses, à prendre avec autant de pincettes que les "potins" que tu cites :
Ruby est lent, c'est notable même par rapport à d'autres langages interprétés comme PHP7. Mais Python3 n'est pas un foudre de guerre non plus.
Un framework MVC avec ORM ralentit forcément par rapport à du code sur mesure. Rails est lourd, mais Django (Python) ou Symfony (PHP) sont du même ordre.
Ruby, comme beaucoup d'autres langages, date d'avant l'explosion des processeurs multi-core, et la nature du langage ne permet pas de parallélisation facile, d'où une programmation concurrente médiocre.
Mais, puisque l'accent est sur la performance :
Tout ceci est focalisé sur la performance, alors que ce n'est pas forcément crucial pour le projet concerné.
Pour un site web, si la quasi-totalité des pages peut se mettre en cache (cache global ou partiel de la page), alors tous les frameworks sont pertinents.
On peut optimiser au cas par cas les pages critiques, notamment en contournant l'ORM avec du SQL natif.
Il vaut mieux choisir un langage de base et un framework que l'on maîtrise, adapté au projet, quitte à l'interfacer avec un backend écrit dans un langage différent et plus performant. Par exemple, frontend en Rails utilisant des services en Java ou Go, voire déporter du code dans Postgresql.
Et côté programmation fonctionnelle :
La VM d'Erlang (et donc d'Elixir) est super pour créer des milliers de tâches concurrentes, éventuellement distribuées sur plusieurs serveurs. Reste à savoir si c'est adapté au projet.
Un langage peut être fonctionnel, mais difficilement compatible avec la programmation concurrente, comme OCaml (pour cause de GIL et parce que les fonctions impures ne sont pas explicites).
Certains langages fonctionnels privilégient une concurrence explicite (Erlang) d'autres implicite (Haskell).
De ce que je vois, Elixir est faiblement typé. Pour un projet où la fiabilité est critique, les langages fonctionnels de type ML (OCaml, Haskell) apportent la fiabilité de leur typage.
Il faut bien sur tenir compte des écosystèmes (bibliothèques, déploiement, communauté, professionnels, etc).
Bref, rien d'original, il faut voir en fonction du projet quel sont les outils les plus adaptés, et se focaliser sur les critères essentiels de l'application. Le passage à l'échelle n'est pas forcément important.
[^] # Re: Ruby et Elixir
Posté par rogo . En réponse à la dépêche Pendant ce temps, dans l’écosystème Ruby. Évalué à 6.
Ma vision des choses, à prendre avec autant de pincettes que les "potins" que tu cites :
Mais, puisque l'accent est sur la performance :
Et côté programmation fonctionnelle :
Bref, rien d'original, il faut voir en fonction du projet quel sont les outils les plus adaptés, et se focaliser sur les critères essentiels de l'application. Le passage à l'échelle n'est pas forcément important.