Pendant ce temps, dans l’écosystème Ruby

Posté par Thomas J. (site web personnel) le 17 novembre 2016 à 03:30. Édité par Davy Defaud, ZeroHeure, Pierre Jarillon et Nils Ratusznik. Modéré par Pierre Jarillon. Licence CC By‑SA.

Étiquettes :

nov.

2016

Même si les analystes le positionnent toujours comme un langage à la popularité limitée, il n’empêche que depuis l’arrivée du cadriciel Rails, le langage Ruby est utilisé par de nombreux services qui partagent notre quotidien : GitHub, Airbnb, Twitch, Zendesk, LinuxFr.org, etc.

Petit tour d’actualité de ce langage qui va bientôt fêter ses 20 ans !

Ruby 3×3

Dès sa création, le langage Ruby s’est focalisé sur la productivité et la joie procurée par la programmation. Les performances n’ont jamais été une caractéristique essentielle de ce langage. Les choses ont néanmoins évolués en février 2013 avec l’arrivée de la version 2. Cette version majeure incluait une toute nouvelle machine virtuelle bien plus performante. Aujourd’hui, le créateur du langage, Yukihiro Matsumoto (aka Matz), souhaite aller encore plus loin et a fixé à la communauté l’objectif de sortir une version 3, trois fois plus rapide que la version 2.0.

Pour mesurer cela, il a été décidé de se baser sur un émulateur NES écrit exclusivement en Ruby : optcarrot. Néanmoins, Matz reste conscient que Ruby on Rails reste l’application vitrine du langage et, à ce titre, il a décidé d’ajouter quelques analyses comparatives autour de ce cadriciel.

Concernant les performances en elles‐mêmes, plusieurs pistes sont actuellement à l’étude :

la compilation à la volée (JIT) qui permettrait un gain performance important. C’est une piste sérieuse, néanmoins Matz ne souhaite pas utiliser le compilateur à la volée du projet LLVM, car il est considéré comme étant trop jeune (par rapport à Ruby). Il faudra donc trouver une solution alternative ;
une première expérimentation a été réalisée avec un compilateur anticipé et permet déjà de faire gagner jusqu’à 30 % de performance ;
plusieurs optimisations autour du ramasse‐miettes sont déjà en cours, même si cela ne représente que 10 % du temps passé dans l’interpréteur Ruby ;
une nouvelle approche de la programmation concurrente via des guilds devrait également améliorer les performances d’ensemble.

Mais pas d’emportement, tout cela n’est pas prévu avant un ou deux ans.

Sortie de Ruby on Rails 5

Une nouvelle version majeure du framework Ruby on Rails est sortie cet été. Cette version 5 comporte beaucoup de nouveautés dont les plus intéressantes sont :

Action Cable, un nouveau module pour manipuler les WebSockets dans votre application ;
le mode API pour créer des applications qui ne communiquent qu’à travers du JSON ;
Turbolinks 5 pour accélérer la navigation sur votre site ;
et plusieurs améliorations sous le capot (comme celle‐ci ou celle‐là).

Néanmoins, les migrations peuvent être relativement délicates car, comme à son habitude, la Rails Core Team n’hésite pas à remettre en cause certains choix du passé (pour ne citer qu’eux : la méthode belongs_to a été revue, de même que le comportement de la fonction de rappel).

C’est peut‐être pour cela que notre site préféré est toujours sur la branche 4 ?

En tout cas, je vous invite à vous initier à ce cadriciel qui fait des merveilles en vous plongeant dans l’ouvrage de référence !

Pourquoi Ruby ?

Toujours pas convaincu de l’utilité de ce langage ?
Alors, jetez un œil à cette Keynote de l’insolent David Heinemeier‐Hansson, créateur du cadriciel Ruby on Rails, qui vous expliquera que Ruby est un ami, ce n’est pas tes parents. Il trouve même une relation entre la pyramide de Maslow et la programmation et, bien entendu, utiliser Ruby s’apparente à un accomplissement de soi. ☺

Aller plus loin

Ruby (352 clics)
Ruby on Rails (175 clics)
Les nouvelles toutes fraîches du projet Ruby 3x3 (185 clics)
Keynote « Why Ruby? » (167 clics)

# Ruby <3

Posté par CrEv (site web personnel) le 17 novembre 2016 à 08:07. Évalué à 10.

Ça fait 10 ans que je code en ruby… et ça reste toujours mon langage préféré (même si clojure et go ne sont pas bien loin).
Mes dernières apps sont en rails 5 (avec turbolinks, action cable, etc) et des services gravitant autour qui eux sont en Go. C'est un mix assez agréable.

le langage Ruby s'est focalisé sur la productivité et la joie procurée par la programmation

Je pense que c'est clairement le point qui me plait le plus. Certes ruby n'est pas du tout le plus performant, ni le plus pointu. Mais coder en ruby reste un grand plaisir, la richesse du langage et de la lib standard fait qu'on a un langage très expressif et relativement naturel (dur à définir). Mon code reste souvent très concis, simple et lisible. Sur ce point même Go fait moins bien je trouve, avec souvent des grands enchainements de if err != nil à la pelle.

J'y ai retrouvé un perl mais en mieux :-)

Le seul point qui me chagrine un peu avec ruby, c'est que faire de la programmation fonctionnelle avec n'est pas évident. Si ce point était plus avancé ce serait top.

Bref, à chaque fois que je dois écrire un nouveau programme je me pose la question de la plateforme, et en général je reviens vers ruby, avec rails si j'ai besoin, ou du Go si je veux juste faire un petit service. Ce qui me manque est de pouvoir faire une app isomorphique à base de ruby…
- [^] # Re: Ruby <3
  
  Posté par barmic le 17 novembre 2016 à 10:21. Évalué à 5.
  
  J'y ai retrouvé un perl mais en mieux :-)
  
  C'est clairement celui au quel je pense quand je lis : « le langage […] s'est focalisé sur la productivité et la joie procurée par la programmation ».
  
  Je n'ai jamais joué avec ruby, mais j'aime bien le langage :)
  Par contre Rail (comme django ou symphony) ne me donne pas du tout envie.
  
  Ce qui me manque est de pouvoir faire une app isomorphique à base de ruby…
  
  Qu'entends-tu par là ?
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Ruby <3
    
    Posté par CrEv (site web personnel) le 17 novembre 2016 à 10:46. Évalué à 3.
    
    Par contre Rail (comme django ou symphony) ne me donne pas du tout envie
    
    Ni django ni symfony ne me font envie, par contre rails toujours. Ça juste marche dans un max de cas et c'est l'exemple même d'extension du langage. On ne fait en général pas la différence entre ce qui provient du framework ou du langage ce qui est super agréable.
    
    Ce qui me manque est de pouvoir faire une app isomorphique à base de ruby…
    
    Qu'entends-tu par là ?
    
    Que l'application réponde aussi bien en front qu'en back. Si l'app est chargée dans mon browser c'est une app client-side, je navigue dans mon browser. Mais si j'arrive sur n'importe quelle url directement elle est rendue par mon back. Et je ne parle pas d'avoir une pseudo génération du front dans mon back, mais bien que l'app soit exécutée aussi bien côté front que back.
    Pour le moment le plus agréable (mais pas simple) que j'ai trouvé est de faire ça en clojurescript. Parce que franchement je n'ai pas envie de faire ça en js.
    - [^] # Re: Ruby <3
      
      Posté par whity le 17 novembre 2016 à 11:01. Évalué à 3.
      
      Que l'application réponde aussi bien en front qu'en back. Si l'app est chargée dans mon browser c'est une app client-side, je navigue dans mon browser. Mais si j'arrive sur n'importe quelle url directement elle est rendue par mon back. Et je ne parle pas d'avoir une pseudo génération du front dans mon back, mais bien que l'app soit exécutée aussi bien côté front que back.
      
      Désolé mais je n’ai toujours pas compris. Dans les deux cas l’application s’exécute et s’affiche dans le navigateur, non ?
      
      Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
      - [^] # Re: Ruby <3
        
        Posté par CrEv (site web personnel) le 17 novembre 2016 à 11:30. Évalué à 4.
        
        Pour faire simple, aujourd'hui pour avoir une "expérience utilisateur" correcte on fait des applications client-side. On navigue en ajax/fetch, on modifie que des morceaux de l'UI pour aller plus vite, avoir de la perf et que l'utilisateur ait une navigation confortable.
        Mais en vrai dans ce cas les pages n'existent pas en statique. Donc pas de référencement par exemple (même s'il existe des gruges de ce côté ci).
        Mais surtout, si on veut arriver directement sur une page précise, le serveur va rendre la base puis le client vas modifier ce qu'il faut pour afficher le contenu (car l'app n'est pas gérée côté serveur, en général côté serveur ce sont plutôt des api). Donc c'est lent.
        Si on ne fait pas client-side, le serveur calcul tout à chaque fois, c'est sympa car en général la page demandée arrive très vite, mais la navigation est plus lente, le serveur re-rend chaque page et le client aussi.
        
        Des technos comme turbolinks dont il est question dans Rails font un mix, les pages sont crées côté serveur et on fusionne body/header des pages côté client, avec une gestion de cache. C'est un intermédiaire assez sympa.
        
        La "vrai" solution est donc que l'app tourne aussi bien côté serveur que côté client.
        Côté serveur car cela permet d'arriver rapidement n'importe où (et même de faire du sans js).
        Côté client car cela permet de naviguer agréable et rapidement dans l'app.
        
        [^] # Re: Ruby <3
        
        Posté par whity le 17 novembre 2016 à 14:33. Évalué à 2.
        
        Merci pour l’explication, c’est plus clair. Hormis la problématique du référencement (je t’avoue que je n’ai pas encore regardé comment on faisait le référencement pour une appli angularjs, pour parler de technos que je connais), j’ai du mal à voir l’intérêt de faire un rendu serveur.
        
        Les arguments contre que je vois sont :
        - la charge sur le serveur est celle qui coûte, celle sur le client est gratuite (sauf exceptions)
        - les dimensions du client sont connues par… le client, qui saura donc le mieux faire le layouting qui va bien (adaptation mobile / tablette, par exemple)
        
        J’ai presque envie de dire que si la problématique est une problématique de cache / rapidité, la solution est peut-être plus à chercher dans un moteur de rendu html tournant au sein d’un reverse proxy que directement dans le code du site.
        
        Après, il faut dire que j’ai tendance à structurer mes applications webs en tant que un front angular, et un back en json (soit jsonrpc, soit api http), ce qui fait que côté « serveur » la notion même de html n’existe plus. De mon point de vue, le templating côté serveur n’est pas l’avenir, mais plutôt restreint à des niches (clients avec très peu de puissance de calcul). Je ne connais pas du tout turbolinks dont tu parles, il faudra que j’y jette un œil à l’occasion (mais l’écosystème rails m’est complètement étranger).
        
        Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
        
        [^] # Re: Ruby <3
        
        Posté par CrEv (site web personnel) le 17 novembre 2016 à 15:34. Évalué à 6.
        
        j’ai du mal à voir l’intérêt de faire un rendu serveur.
        
        L'intérêt est dans la performance permettant à arriver au premier rendu utilisable côté utilisateur.
        En général avec des app client side ça se passe en deux temps : chargement de l'app côté client avec tout le js qui va bien puis appel au serveur pour des datas qui ensuite sont rendues.
        Mais c'est quand même un peu con car les datas étaient déjà connues lors de l'appel à la page côté serveur, pour l'utilisateur ça aurait été plus rapide d'avoir la page contenant déjà les bonnes infos.
        
        la charge sur le serveur est celle qui coûte
        
        Oui, c'est certains que ça coûte.
        
        celle sur le client est gratuite (sauf exceptions)
        
        Ha ben non, c'est pas gratuit du tout. Si par exemple tu fais un site de vente en ligne, tu verra que chaque seconde (ou dixième de) fait en réalité perdre des ventes. Un site qui rame est un site qui ne vent pas, mais aussi un site qui donne envie d'aller voir le concurrent plus rapide par exemple. Donc avoir une expérience utilisateur qui n'est pas bonne risque même de coûter plus cher que ton serveur.
        
        la solution est peut-être plus à chercher dans un moteur de rendu html tournant au sein d’un reverse proxy que directement dans le code du site.
        
        Pourquoi ? Ça me parait justement tordu voir super consommateur de ressources. Certains faisaient par exemple ça avec des phantomjs tournant côté serveur, je suis pas certains que ça ait laissé un super souvenir à beaucoup.
        
        Pour ceux que ça intéresse il y a cette conférence de François Zaninotto sur "l'expérience utilisateur ultime" qui est vraiment sympa : https://www.youtube.com/watch?v=tIlQCIz9XF8
        
        [^] # Re: Ruby <3
        
        Posté par whity le 17 novembre 2016 à 18:16. Évalué à 2.
        
        En général avec des app client side ça se passe en deux temps : chargement de l'app côté client avec tout le js qui va bien puis appel au serveur pour des datas qui ensuite sont rendues.
        Mais c'est quand même un peu con car les datas étaient déjà connues lors de l'appel à la page côté serveur, pour l'utilisateur ça aurait été plus rapide d'avoir la page contenant déjà les bonnes infos.
        
        Mais les deux ne sont pas même pas forcément sur le même serveur. Servir les templates statiques et le js est très peu coûteux en charge serveur. C’est clair qu’il y a un peu de latence supplémentaire, puisque tu ne peux pas charger le contenu côté serveur sans avoir chargé celui côté client.
        
        Ha ben non, c'est pas gratuit du tout. Si par exemple tu fais un site de vente en ligne, tu verra que chaque seconde (ou dixième de) fait en réalité perdre des ventes.
        
        C’est vrai que j’ai tendance à oublier que certains réussissent à faire des horreurs comme rueducommerce qui rame horriblement côté client. Mais mon expérience (côté dev) est quand même souvent que quand ça rame, c’est parce que le serveur est lent à répondre, et au contraire, je trouve que le chargement asynchrone des données améliore l’« expérience utilisateur », car le site s’affiche, même partiellement, tandis que dans un templating côté serveur, le plus souvent tant que les données n’ont pas été récupérées rien ne s’affiche (pas pour rien qu’on recourt quasiment systématiquement à un cache du html dans ce cas).
        
        Ça reste subjectif cela dit, je manque de données objectives de comparaison. Si tu en as je suis intéressé.
        
        Pourquoi ? Ça me parait justement tordu voir super consommateur de ressources.
        
        Je pense pas que ça soit significativement plus consommateur de ressources qu’un moteur de templating classique (en gros, c’est juste manipuler du dom avec du js). phantomjs, c’est beaucoup plus bourrin, ça fait le rendu image.
        
        Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
        
        [^] # Re: Ruby <3
        
        Posté par CrEv (site web personnel) le 17 novembre 2016 à 21:37. Évalué à 3.
        
        Mais les deux ne sont pas même pas forcément sur le même serveur.
        
        Par serveur j'entendais juste côté serveur, sur le même, pas sur le même, dans un cluster ou autre ne change rien au principe ;-)
        
        C’est clair qu’il y a un peu de latence supplémentaire, puisque tu ne peux pas charger le contenu côté serveur sans avoir chargé celui côté client.
        
        C'est plus que de la latence, c'est aussi parfois juste le temps de démarrage de l'app côté client
        
        souvent que quand ça rame, c’est parce que le serveur est lent à répondre
        
        Ça me semble assez simpliste ;-)
        
        c’est juste manipuler du dom avec du js
        
        Oué enfin justement, ce dont on parle c'est bien d'avoir du js et du dom des deux côtés. On serait pas en train de boucler là ? Après le but c'est d'avoir ça de manière bien intégrée, et même code côté client et serveur.
        
        phantomjs, c’est beaucoup plus bourrin, ça fait le rendu image.
        
        Ça peut aussi juste être utilisé pour pouvoir exécuter du js, donc app client side mais server side
- [^] # Re: Ruby <3
  
  Posté par BAud (site web personnel) le 18 novembre 2016 à 00:19. Évalué à 2. Dernière modification le 18 novembre 2016 à 00:20.
  
  J'y ai retrouvé un perl mais en mieux :-)
  
  merci, tu viens de me faire comprendre pourquoi la lecture du code Ruby de LinuxFr.org me semblait agréable et pourquoi j'ai été en mesure de proposer quelques patchs, même si je n'ai pas pratiqué réellement le langage :-) (bon, NoNo< les a amélioré ou simplifié généralement).
  Je comprends l'impression que perl pouvait me donner mal à la tête parfois, mais que la lecture de code RoR me donne l'impression d'être élégante (bon, faut rentrer dans le modèle MVC, mais ce n'est pas très compliqué).
- [^] # Re: Ruby <3
  
  Posté par Bruno Michel (site web personnel) le 18 novembre 2016 à 11:54. Évalué à 3.
  
  Le seul point qui me chagrine un peu avec ruby, c'est que faire de la programmation fonctionnelle avec n'est pas évident. Si ce point était plus avancé ce serait top.
  
  Tu n'es pas tenté par Elixir/Phoenix du coup ?
  - [^] # Re: Ruby <3
    
    Posté par CrEv (site web personnel) le 18 novembre 2016 à 12:07. Évalué à 3.
    
    Si, c'est ce que je devrais faire :-)
    C'est plus une question de temps pour le moment, sur mes derniers devs j'ai repris un rails parce que beaucoup de choses marchent simplement directement. Et pour avancer très rapidement sur un domaine complexe c'est agréable comme première approche.
    
    Mais en effet ça pourrait être une solution élégante pour faire du fonctionnel sans pour autant sortir du LFE ou du Clojure.
  - [^] # Re: Ruby <3
    
    Posté par lepieru le 20 novembre 2016 à 13:55. Évalué à 1.
    
    Qu'est-ce qui vous manque dans Ruby au niveau de la programmation fonctionnelle ? Et pourquoi plutôt se diriger vers Elixir/Phoenix ?
    - [^] # Re: Ruby <3
      
      Posté par lepieru le 26 novembre 2016 à 03:03. Évalué à 3.
      Après avoir vu cette vidéo, la réponse pourrait être « pas grand chose » ;)
      
      Dans cette vidéo, on peut voir que Ruby se débrouille plutôt bien en ce qui concerne :
      
      les high-order functions :
      
      map = proc { |f, coll| # definition of a map function coll.map(&f) # using Enumerable#map… } inc = proc { |x| x + 1 } # proc that adds 1 to input nums = [2, 3, 4] # data for us to map over map.call(inc, nums) # returns [3, 4, 5] map.(inc, nums) # syntactic sugar to hide the `call`
      
      le currying :
      
      add = proc { |x, y| x + y }.curry # native currying add.(2, 3) # returns 5 inc = add.(1) # returns an add function with first argument pre-set as 1 inc.(2) # returns 3 map.(inc, [2, 3, 4]) # returns [3, 4, 5]
      
      la composition (de fonctions bien sûr) :
      
      compose = proc { |x, y| proc { |*args| x.(y.(*args)) } } inc = add.(1) # a inc function add2 = add.(2) # a dec function add3 = compose.(inc, add2) # returns a composition of inc and dec add3.(4) # returns 7, equivalent to `add2(inc(4))` # Personal bonus, or how to be more Haskel friendly class Proc # Proc class monkey patched, MER IL ET FOU def >>(f) return proc { |*args| f.(self.(*args)) } end end inc = add.(1) # an inc function add2 = add.(2) # a dec function add3 = inc >> add2 # Haskel friendly composition ;D add3.(4) # returns 7, equivalent to `add2(inc(4))`
# [HS] Traduction à la québecoise

Posté par Zenitram (site web personnel) le 17 novembre 2016 à 08:15. Évalué à 5. Dernière modification le 17 novembre 2016 à 08:17.

cadriciel

Je pense que vous devriez mettre comme "juste-à-temps (JIT)" pour "cadriciel", bref la version usité entre parenthèse à défaut d'être juste affichée, genre "cadriciel (framework)".
Personnellement j'ai dû chercher la signification de ce mot ("mais de quoi ils parlent?") comme quand je tombe sur "Danse lascive" ou "Ferrovipathes" pour un titre de film (je me demande de quel film tu parles alors que je le connais ces films, sous un autre nom en France/français utilisé).
- [^] # Re: [HS] Traduction à la québecoise
  
  Posté par CrEv (site web personnel) le 17 novembre 2016 à 10:42. Évalué à 10.
  
  cadriciel
  
  Oué, enfin pour le coup ça fait des années que c'est employé dans moultes dépêches et journaux ici même ;-)
  - [^] # Re: [HS] Traduction à la québecoise
    
    Posté par Old Geek le 18 novembre 2016 à 09:42. Évalué à -2.
    
    haaa linuxFR, une visite de temps en temps et on repart aussitôt…, cela me fait penser à la théorie des bulles de filtrage tiens.
# 3x3

Posté par barmic le 17 novembre 2016 à 10:27. Évalué à 6.

[…] sortir une version 3, trois fois plus rapide que la version 2.0

C'est super. Je ne suis pas pour la performance à tout prix, mais c'est important de ne pas trop le perdre de vue. Par contre il n'y a rien de prévu en terme de d'évolution du langage ? Je pense en particulier au fait qu'il est souvent possible d'avoir un gain de performance important en faisant évoluer le langage lui-même, c'est une piste envisagée ? Si c'est le cas, plus c'est sû tôt plus les développeurs peuvent se préparer (en ne s'appuyant plus sur une fonctionnalité qui va sauter/évoluer dans la prochaine version).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: 3x3
  
  Posté par Marc Quinton le 17 novembre 2016 à 15:14. Évalué à 5.
  
  Crystal est un sous-ensemble de Ruby qui est compilé, soit à la volée, soit en executable. Ses performances sont très bonnes. Mais c'est un sous-ensemble de Ruby.
# Ruby-GNOME2

Posté par cedlemo le 17 novembre 2016 à 16:28. Évalué à 5.

J'aimerais bien présenter le projet ruby-GNOME2 (qui devrait peut être retrouver le nom ruby-GNOME) ici quand j'aurais le temps avec l'historique, l'introduction de GObject-Introspection, les perspectives (Gtk4).
- [^] # Re: Ruby-GNOME2
  
  Posté par BAud (site web personnel) le 18 novembre 2016 à 00:24. Évalué à 6.
  
  tu as l'espace de rédaction qui t'est complètement ouvert et te permettra de rédiger à plusieurs en collaboratif (c'est fou, non ?)
  
  Tu peux démarrer la dépêche en donnant le plan et des liens vers des sujets en anglais que tu souhaiterais réutiliser comme base (si possible sous licence libre, sinon faut reformuler/synthétiser pas simplement traduire), puis t'apercevoir que certains auront écrit pour toi :-)
  - [^] # Re: Ruby-GNOME2
    
    Posté par cedlemo le 18 novembre 2016 à 10:00. Évalué à 3.
    
    tu as l'espace de rédaction qui t'est complètement ouvert et te permettra de rédiger à plusieurs en collaboratif (c'est fou, non ?)
    
    C'est idiot mais je viens toujours ici en mode lurker et je ne me suis jamais demandé comment les articles ou dépêches étaient co-réalisée. Je pense que tu viens de me sauver une bonne demi-heure.
    
    Merci.
# Ruby et Elixir

Posté par Sevechjo le 19 novembre 2016 à 00:12. Évalué à 2.
Ce que j'ai retenu de Medium et des podcasts, c'est :
- que Ruby c'est pour le script et le prototypage rapide des petites et moyennes applications web.
- que pour le backend d'un projet potentiellement massif, le passage à l'échelle serait coûteux, et on conseille plutôt : Java EE (et on cite Twitter et Scala) ou autres (.net, Go, nodeJS, php7?).
- que le paradigme fonctionnelle est plus adapté à la programmation concurrente. Et l'on conseille notamment des solutions à base de machine virtuelle Erlang (BEAM, rendu célèbre par WhatsApp) et d'un nouveau langage, ELixir (dont la syntaxe s'inspire en partie de Ruby).
Un exemple de ces potins (en anglais) : The free lunch is over.
http://www.huffingtonpost.com/jose-valim/concurrent-and-distribute_b_4350533.html
C'est sérieux tout ça ?
- [^] # Re: Ruby et Elixir
  
  Posté par rogo le 21 novembre 2016 à 11:16. Évalué à 6.
  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.
# Volt framework

Posté par dzecniv le 19 novembre 2016 à 15:26. Évalué à 3.

Ce qui me ferait passer à Ruby de suite, ce serait le framework Volt en version utilisable: http://voltframework.com/
Volt, c'est la possibilité d'écrire du Ruby pour le backend… et le client.
Ça a l'air génial, mais il est au point mort, le projet cherche un nouveau lead développer.