Elixir, Phoenix et Membrane

Posté par  (site web personnel) . Édité par Davy Defaud et ZeroHeure. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes :
47
30
juil.
2018
Programmation fonctionnelle

Elixir est un langage de programmation dont la version 1.7 vient de sortir. Il est notamment utilisé par deux cadriciels : Phoenix pour le Web et Membrane Framework pour la diffusion multimédia. Ces trois projets sont présentés dans la seconde partie de la dépêche.

Elixir

Elixir est un langage de programmation fonctionnelle et dynamique. Il s’appuie sur la machine virtuelle d’Erlang, avec une syntaxe inspirée de Ruby et pas mal de bonnes idées prises d’autres langages (les docstrings de Python par exemple).

Elixir profite de la machine virtuelle d’Erlang, connue pour ses aspects distribués, sa résistance aux erreurs et sa faible latence. En particulier, il reprend les processus légers (l’équivalent des goroutines de Go) :

current_process = self()

# Crée un nouveau processus léger d’Elixir
spawn_link(fn ->
  send current_process, {:msg, "Hello world!"}
end)

# Attend jusqu’à la réception d’un message
receive do
  {:msg, contents} -> IO.puts contents
end

Un autre point fort d’Elixir est son outillage, avec notamment mix, l’outil de construction, hex, le gestionnaire de paquets, et iex, la console interactive. ExUnit, le cadriciel de test, profite des macros d’Elixir, qui permettent d’écrire des DSL, pour avoir des tests concis avec des rapports d’erreur compréhensibles :

defmodule SampleTest do
  use ExUnit.Case, async: true

  test "test the truth" do
    assert "fox jumps over the lazy dog" == "brown fox jumps over the dog"
  end
end

Rapport d’erreur d’ExUnit

Phoenix

Phoenix est un cadriciel Web, l’équivalent de Ruby on Rails pour Elixir. Par rapport à Rails, il a abandonné le côté magique tout en ayant quand même réussi à garder le sentiment de productivité que l’on peut avoir en développant avec. En particulier, Ecto, la bibliothèque de persistance des données, est souvent vue comme plus solide qu’ActiveRecord. Enfin, Phoenix bénéficie d’Elixir et de la plate‐forme Erlang : ses temps de réponse pour des pages avec peu d’interactions avec la base de données sont généralement sous la milliseconde, là où on est plutôt à quelques dizaines de millisecondes avec Rails.

Membrane Framework

Membrane Framework sert à construire des applications côté serveur pour les flux multimédias. Il met l’accent sur la fiabilité et la concurrence, et ce n’est donc pas très étonnant qu’il soit développé en Elixir (avec un peu de C, toutefois).

Membrane Framework se compare à GStreamer. D’après les dires de leurs développeurs, ils ne cherchent pas à couvrir tous les cas et formats que GStreamer peut couvrir et préfèrent se concentrer sur la qualité.

N. D. A. : J’ai déjà utilisé un peu Elixir et Phoenix, mais je ne fais que relayer des informations lues sur le site officiel de Membrane Framework car le projet me semble intéressant. Si des lecteurs ont un avis plus éclairé, je les encourage à le faire partager dans les commentaires.

Aller plus loin

  • # Je confirme

    Posté par  (site web personnel) . Évalué à 8.

    Pour avoir utilisé erlang, puis elixir depuis de nombreuses années en production, je confirme que cette plate-forme est vraiment extraordinaire.
    Du côté performance/parallélisme, si vous construisez une application web avec phoenix (ou au moins le serveur web qu'il utilise cowboy), vous pouvez tout simplement oublier les load balancer, les serveurs web type nginx à rajouter devant, etc.

    Et côté expressivité du langage, elixir a apporté un tas de DSL qui simplifient vraiment la vie des développeurs.

    Enfin, parmi les frameworks qui gagnent à être connus, il faut citer le projet Nerves qui est un vrai OS pour l'IoT entièrement en erlang/elixir.

    "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

    • [^] # Re: Je confirme

      Posté par  (site web personnel) . Évalué à 8. Dernière modification le 30 juillet 2018 à 14:06.

      Pareil, pour le peu que j'ai pratiqué (en hobbyiste), j'ai pris un plaisir fou à utiliser Elixir et ses millions de processus légers, son OTP, son pattern matching, sa documentation aux petits oignons, sa
      communauté bienveillante…
      Je ne comprends pas qu'on ne parle pas plus de cette plateforme.
      Je rêve de remplacer le backend nodejs au boulot par ça.

    • [^] # Re: Je confirme

      Posté par  (site web personnel) . Évalué à 10.

      Enfin, parmi les frameworks qui gagnent à être connus, il faut citer le projet Nerves qui est un vrai OS pour l'IoT entièrement en erlang/elixir.

      Je t'encourage très fortement à écrire une dépêche sur Nerves. Ça a l'ait d'être un projet qui t'a plu et il n'y aura personne de mieux placé que toi pour le faire !

    • [^] # Re: Je confirme

      Posté par  . Évalué à 2.

      Comment trouves-tu le déploiement ? Utilise-t-on des exécutables, doit-on récupérer les dépendances au déploiement (comme en js ou python), en ce cas l'écosystème est-il stable ?

      • [^] # Re: Je confirme

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 30 juillet 2018 à 19:58.

        Le système de dépendances est assez similaires à celui d'un nodejs dans l'esprit : on spécifie les dépendances dans le fichier de configuration du projet avec des directives au niveau des versions des dépendances souhaitées. mix (le couteau suisse elixir) va servir à installer (ou mettre à jour) ces dépendances (par défaut essentiellement sous forme de fichiers binaires beam erlang).
        Ensuite, j'ai pas trop l'expérience de la prod, donc je ne saurai pas répondre sur les problématiques d'installation de dépendances dans ce contexte, mais je pense que le système est assez souple pour répondre à un bon nombre de problématiques.

      • [^] # Re: Je confirme

        Posté par  (site web personnel) . Évalué à 3.

        Depuis le début, OTP (= la langage erlang, la vm BEAM et les libs standards) sur lequel repose Elixir ont été conçu comme un OS et pour l'embarqué.

        Du coup, pour le déploiement, une application elixir est packagée avec tout ce qu'il faut pour qu'elle tourne y compris la VM, les scripts de démarrage, etc.

        Comme beaucoup d'applications ne sont maintenant plus embarquées, on peut exclure la VM de la release. Ceci dit, une application typique elixir avec la VM va faire 30-40 Mo, exclus bien sûr les ressources (images, docs, etc).

        Pour créer les releases, elixir fournit un outil très simple, mix (https://elixir-lang.org/getting-started/mix-otp/introduction-to-mix.html), qui gère le download des dépendances, la compilation, la création de la release, etc. On peut même très facilement l'intégrer dans une intégration continue avec (https://github.com/edeliver/edeliver), etc.

        "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

      • [^] # Re: Je confirme

        Posté par  (site web personnel) . Évalué à 3.

        Je me rend compte que je n'ai répondu qu'à la moitié de la question :)

        Utilise-t-on des exécutables ?

        Il y a des exécutables pour compiler (c'est un langage compilé). On peut écrire des (pas trop grosses) applications sous forme de scripts.
        Enfin et surtout, il y a un shell qui sert à la fois à tester du code mais également (et c'est un vrai plus pour débugger) à interagir avec une application qui tourne. Le shell se "connecte" à une application et vous directement appeler des fonctions de l'application ou des librairies embarquées par l'application.

        L'écosystème est-il stable ?

        En ce qui concerne erlang et OTP, l'écosystème est un des plus stables que je connaisse (bien que vivant :) ). Vous pouvez facilement trouver sur librairies qui n'ont pas été touchées depuis 10 ans, qui compilent et fonctionnent très bien.

        En ce qui concerne elixir, c'est beaucoup plus mouvant. Au doigt mouillé, je dirais que toutes les 3 versions d'elixir, il y a des changement incompatibles (par exemple une appli en 1.6 pourrait lever des warnings en 1.3). Toutefois le code erlang pouvant être appelé depuis elixir et inversement, on peut facilement utiliser erlang pour le code stable et elixir quand la contrainte est moins forte.

        CECI DIT, dans tous les cas, la stabilité est largement meilleure que Python, Ruby ou Node et la compilation rend les migrations beaucoup plus faciles.

        "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

        • [^] # Re: Je confirme

          Posté par  . Évalué à 0.

          CECI DIT, dans tous les cas, la stabilité est largement meilleure que Python, Ruby ou Node et la compilation rend les migrations beaucoup plus faciles.

          De quelle stabilité parle-t-on?

          • [^] # Re: Je confirme

            Posté par  . Évalué à 2.

            CECI DIT, dans tous les cas, la stabilité est largement meilleure que Python, Ruby ou Node et la compilation rend les migrations beaucoup plus faciles.

            De quelle stabilité parle-t-on?

            Stabilite des API?

            • [^] # Re: Je confirme

              Posté par  (site web personnel) . Évalué à 1.

              Oui, stabilité des API = pendant combien de temps un code écrit dans une version du langage pourra être compilé sans nécessiter une réécriture.

              "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

  • # Première fois que je vois le langage

    Posté par  . Évalué à 2.

    Il me semble assez simple, et je vois que des gens l'utilisent pour faire un peu de code en réseau, et je suppose que c'est très bien pour le web (pour remplacer node de ce que je vois des autres commentaires). Mais je ne vois pas trop ce qu'il apporte aux langages un peu plus connus. J'ai fait un peu de Haskell et j'aimerai bien savoir ce qu'Erlang et Elixir peuvent m'apporter, et je n'ai rien vu de tout ça sur les sites que j'ai vu.

    Et également, le "documentaire" est vraiment creux : il y a des gens qui disent "c'est génial" et expliquent que "c'est génial" parce qu'ils arrivent à faire appel à un code distant… j'ai dû raté quelque-chose, ou alors c'est juste complètement con.

    • [^] # Re: Première fois que je vois le langage

      Posté par  . Évalué à 3.

      Je n'ai pas touché ni à Elixir, ni à Erlang, mais de ce que j'en sais les gros points forts :

      • grâce au runtime (entre autre) la possibilité de faire de la mise à jour à chaud de ton logiciel en prod
      • un système à acteur qui permet une programmation parallèle efficace et plutôt souple
    • [^] # Re: Première fois que je vois le langage

      Posté par  (site web personnel) . Évalué à 3.

      La plupart des fonctionnalités du langage se retrouvent dans d'autres langages, mais éparpillées.

      Par exemple:
      - langage compilé: assez rare dans les langages "haut niveau" (js, ruby, python…)
      - méta-langage: directement inspiré de ruby. Par exemple, le projet Phoenix fait un grand usage des DSL qui permettent d'exprimer très simplement des pipelines de traitement de requêtes web, des requêtes en base de données, etc.
      - robustesse (unique, à ma connaissance): les applications sont écrites comme un "système" de services supervisés, avec des politiques de supervision configurables. Ceci permet d'isoler les services les uns des autres.
      - une machine virtuelle vraiment adaptée au parallélisme: variable read-only, gestion de la mémoire et des processus ultra-efficace (vous pouvez faire aisément tourner des millions de processus sur 4 cores).
      - par rapport à d'autres langages fonctionnels, les librairies de base (OTP) sont vraiment orientées vers la production en incluant : supervision de processus, gestion de configuration, services réseau (SSH, FTP, DNS, SNMP), debugger (graphique), gestion de release, etc

      "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

      • [^] # Re: Première fois que je vois le langage

        Posté par  . Évalué à 1.

        Je ne suis pas des masse convaincu, niveau bibliothèques Haskell est plutôt chargé. Pas assez utilisé dans la pratique pour me faire un avis pertinent, mais ça m'a pas l'air bien différent de ce que vous décrivez.

  • # pour ma part je n'aime pas trop elixir

    Posté par  . Évalué à 3.

    Pourtantj'aime bien ruby, et je trouve la syntaxe d'Erlang parfois un peu lourde, mais je trouve qu'Elixir a dévoyé un peu certains avantages d'Erlang, et a notamment perdu en cohérence par rapport à celui-ci.

    Par exemple, je trouve que les variables immuables sont un gros avantage d'Erlang pour éviter les bugs, et le fait qu'Elixir permette la multiple réaffectation me pose problème. Et au final on se retrouve avec un langage gloubiboulga, qui reprend un concept par-ci, un concept par-là et qui perd de sa cohérence( un peu comme Python, ou dans une mesure un peu moindre java).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.