De l'avis même de Joe Armstrong, elixir est le langage qu'il aurait écrit s'il avait dû réécrire erlang.
La compatibilité avec les codes erlang existants est parfaite. Et surtout, la méta-programmation est "first-class citizen". Par exemple, pour définir une fonction "dictionnaire" à partir d'un fichier, on pourrait faire ceci:
for {key, value} <- CSV.read("myfile.csv") do
def get(unquote(key)), do: unquote(value)
end
Mais cela ne se limite pas à des macros de ce style, on peut vraiment écrire des langages complets.
J'ai longtemps utilisé emacs avec les modes erlang ou elixir, qui fonctionnent plutôt bien, surtout depuis l'arrivée du protocole LSP (Language Server Protocol). Malheureusement, si on veut la compilation à la volée, complétion de code, doc en ligne, etc, la config devient tellement touffue qu'on peut facilement s'y perdre :/
En ce qui concerne les perfs, le benchmark que je cite est un point départ, surtout pour les ordres de grandeur. Les 2-3% de perfs entre une plateforme et une autre ne sont pas significatifs, à mon avis, car il faut prendre l'écosystème dans son ensemble (tolérance aux pannes ? distribution ?).
Ceci dit, le benchmark identifie clairement 2 "familles": les threads légers gérés le runtime lui-même (Scala, Go, erlang) qui gèrent facilement des millions de threads et les langages qui laissent Linux gérer les threads: ceux-là (Linux en fait) ne passent pas l'échelle 103 ou 104.
Et sinon, si c'est de lui que tu parles, je garde effectivement un très bon souvenir de Marc Guyomard, qui m'a toujours inspiré dans mon métier :)
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: Comparatif avec d'autres langages orientés "actor model"
Posté par Jean Parpaillon . En réponse à la dépêche Sortie d’Erlang/OTP 24. Évalué à 3.
De l'avis même de Joe Armstrong, elixir est le langage qu'il aurait écrit s'il avait dû réécrire erlang.
La compatibilité avec les codes erlang existants est parfaite. Et surtout, la méta-programmation est "first-class citizen". Par exemple, pour définir une fonction "dictionnaire" à partir d'un fichier, on pourrait faire ceci:
for {key, value} <- CSV.read("myfile.csv") do
def get(unquote(key)), do: unquote(value)
end
Mais cela ne se limite pas à des macros de ce style, on peut vraiment écrire des langages complets.
J'ai longtemps utilisé emacs avec les modes erlang ou elixir, qui fonctionnent plutôt bien, surtout depuis l'arrivée du protocole LSP (Language Server Protocol). Malheureusement, si on veut la compilation à la volée, complétion de code, doc en ligne, etc, la config devient tellement touffue qu'on peut facilement s'y perdre :/
En ce qui concerne les perfs, le benchmark que je cite est un point départ, surtout pour les ordres de grandeur. Les 2-3% de perfs entre une plateforme et une autre ne sont pas significatifs, à mon avis, car il faut prendre l'écosystème dans son ensemble (tolérance aux pannes ? distribution ?).
Ceci dit, le benchmark identifie clairement 2 "familles": les threads légers gérés le runtime lui-même (Scala, Go, erlang) qui gèrent facilement des millions de threads et les langages qui laissent Linux gérer les threads: ceux-là (Linux en fait) ne passent pas l'échelle 103 ou 104.
Et sinon, si c'est de lui que tu parles, je garde effectivement un très bon souvenir de Marc Guyomard, qui m'a toujours inspiré dans mon métier :)
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier