J'adore Ocaml, et j'aurais aimé continuer à l'utiliser grâce à son système de type, sa création/ parcours d'arbre très simple, le tagless final (présenté par kantien). C'est un outil parfait pour un "filtre unix", un programme que l'on lance une fois et donne un résultat (compilateur, transformation, documentation, calcul....).
Mais si on veut faire de la GUI, il y avait au dernière nouvelle que du gtk 2.0 de disponible qui n'utilise pas les arbres typés qui serait pourtant géniaux dans le cas d'une GUI. Bref, c'est peu conseillé.
Pour faire un serveur, il n'y a pas l'air d'avoir grand chose d'aboutis. Le projet Ocsygen avait l'air prometteur, mais si vous comprenez leur exemple, c'est que vous avais un BAC+9 en sémantique des langages ML, et ce n'est plus de l'Ocaml mais un dialecte à eux. De plus, je ne suis pas sûr que le GC se limite à des pauses courtes (<100ms) même avec 16 Go de ram, ce qui est handicapant pour un serveur. Ils ont auss un bon compilateur de Ocaml vers javascript pour l'execution du code dans le navigateur.
D'un point de vue performance, Ocaml n'utilise toujours pas le SIMD, ce qui sera possible avec l'unboxing de tableau de flottant.
Ce qui est plus problématique, surtout dans les serveurs, est le manque de gestion du parallélisme. Aujourd'hui, chaque système dispose de 4 cores minimum. "golang" peut être plus rapide que Ocaml grâce à sa bonne gestion du multi-cpu. Ocaml ne dispose toujours pas d'un bon modèle sur ce sujet (genre message passing sans copie).
Je suis passé à "Go" pour toutes ses raisons. La lib http est ultrabasique à utiliser, les performances sont bonnes et ont peu espérer faire des interfaces en HTML avec les limites que l'on connait des interfaces web. Go manque cruellement des types union, mais son typage structurel allège beaucoup le code et les dépendances.
Mozilla arrive avec Rust, qui se veut un remplaçant de C++ pour les clients lourds, avec 90% des fonctionnalités d'Ocaml et une bonne api pour la GUI.
EML (http://elm-lang.org/) est un nouveau langage ML qui se veut un moyen de forcer l'usage correct des paradigmes à la mode de javascript (react, ...). Franchement, il ne lui manque que les modules pour pouvoir faire du "tagless final" pour être un sacré écosystème pour écrire des SPA (application web) (de mon point de vue).
Les développeurs d'Ocaml sont sans doute entrain de faire un choix entre combler les manques de l'écosystème ou renforcer ses points forts (on choisit souvent un outil, car c'est le meilleur dans un domaine).
# futur
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche OCaml 4.04 et 4.05. Évalué à 9.
J'adore Ocaml, et j'aurais aimé continuer à l'utiliser grâce à son système de type, sa création/ parcours d'arbre très simple, le tagless final (présenté par kantien). C'est un outil parfait pour un "filtre unix", un programme que l'on lance une fois et donne un résultat (compilateur, transformation, documentation, calcul....).
Mais si on veut faire de la GUI, il y avait au dernière nouvelle que du gtk 2.0 de disponible qui n'utilise pas les arbres typés qui serait pourtant géniaux dans le cas d'une GUI. Bref, c'est peu conseillé.
Pour faire un serveur, il n'y a pas l'air d'avoir grand chose d'aboutis. Le projet Ocsygen avait l'air prometteur, mais si vous comprenez leur exemple, c'est que vous avais un BAC+9 en sémantique des langages ML, et ce n'est plus de l'Ocaml mais un dialecte à eux. De plus, je ne suis pas sûr que le GC se limite à des pauses courtes (<100ms) même avec 16 Go de ram, ce qui est handicapant pour un serveur. Ils ont auss un bon compilateur de Ocaml vers javascript pour l'execution du code dans le navigateur.
D'un point de vue performance, Ocaml n'utilise toujours pas le SIMD, ce qui sera possible avec l'unboxing de tableau de flottant.
Ce qui est plus problématique, surtout dans les serveurs, est le manque de gestion du parallélisme. Aujourd'hui, chaque système dispose de 4 cores minimum. "golang" peut être plus rapide que Ocaml grâce à sa bonne gestion du multi-cpu. Ocaml ne dispose toujours pas d'un bon modèle sur ce sujet (genre message passing sans copie).
Je suis passé à "Go" pour toutes ses raisons. La lib http est ultrabasique à utiliser, les performances sont bonnes et ont peu espérer faire des interfaces en HTML avec les limites que l'on connait des interfaces web. Go manque cruellement des types union, mais son typage structurel allège beaucoup le code et les dépendances.
Mozilla arrive avec Rust, qui se veut un remplaçant de C++ pour les clients lourds, avec 90% des fonctionnalités d'Ocaml et une bonne api pour la GUI.
EML (http://elm-lang.org/) est un nouveau langage ML qui se veut un moyen de forcer l'usage correct des paradigmes à la mode de javascript (react, ...). Franchement, il ne lui manque que les modules pour pouvoir faire du "tagless final" pour être un sacré écosystème pour écrire des SPA (application web) (de mon point de vue).
Les développeurs d'Ocaml sont sans doute entrain de faire un choix entre combler les manques de l'écosystème ou renforcer ses points forts (on choisit souvent un outil, car c'est le meilleur dans un domaine).
"La première sécurité est la liberté"