Je fais actuellement de l'ingénierie cloud et des programmes de type sauvegarde de BDD ou migration de schéma etc., et de l'automatisation pour AWS. Et je fais tout en OCaml ;)
La situation des GUIs est assez problématique mais on peut facilement faire des interfaces simplettes avec LablTk. Il y a des gens qui utilisent Electron pour faire des programmes plus avancés mais je ne me suis jamais penché sur cette technique.
En ce qui concerne la gestion du parallélisme, il y a plusieurs cas à distinguer. Je mettrais d'un côté la parallélisme de calcul scientifique lourd par exemple utilisant 192+ cœurs ou bien des circuits programmables, dans ce cas on passe en général par des outils spécialisés qu'on contrôle avec OCaml (ou Go, ou autre), par exemple en écrivant un binding ou un programme externe. D'un autre côté il y a le parallélisme de traitement où les entrées-sorties sont le facteur limitant. Par exemple le classique server web ou bien la recherche dans une grosse base de donnés. Ici je trouve que la question du support de ce genre de parallélisme est un peu "90s" car aujourd'hui l'approche consistant à écrire des programmes à un seul fil d'exécution dont on lance de multiples copies en ajoutant un ou plusieurs processus de synchronisation (comme un répartiteur de charge ou une queue de travail) est très populaire. Les avantages de cette approche sur les fils multiples dans un même programme est que l'application est logiquement plus simple et l'augmentation de capacité se fait selon une seule variable, le nombre de processus vs. le nombre de processus * le nombre de fils. Cette technique introduit cependant des difficultés liées à la décentralisation de l'information, la mettre en œuvre peut donc mener à des problèmes difficiles de partage d'information.
Pour OCaml il existe la bibliothèque Lwt qui utilise la même approche que NodeJS où deux fils d'exécution invisibles à l'utilisateur existent, l'un s'occupe du bytecode ou de la logique du programme et l'autre s'occupe des entrées-sorties. Ainsi l'utilisateur peut penser à son application comme à un processus monofil tout en bénéficiant du parallélisme d'exécution. Combinée à des bibliothèques comme Cohttp (client et seveur HTTTP) ou webmachine, on peut facilement écrire des micro-services HTTP/JSON en OCaml.
PS.: La communauté OCaml monte en activité ces dernières années. Elle est maintenant solidement implantée dans l'industrie, ce qui présage de nombreux développements positifs pour le futur!
[^] # Re: futur
Posté par Michaël (site web personnel) . En réponse à la dépêche OCaml 4.04 et 4.05. Évalué à 3. Dernière modification le 21 août 2017 à 16:06.
Je fais actuellement de l'ingénierie cloud et des programmes de type sauvegarde de BDD ou migration de schéma etc., et de l'automatisation pour AWS. Et je fais tout en OCaml ;)
La situation des GUIs est assez problématique mais on peut facilement faire des interfaces simplettes avec LablTk. Il y a des gens qui utilisent Electron pour faire des programmes plus avancés mais je ne me suis jamais penché sur cette technique.
En ce qui concerne la gestion du parallélisme, il y a plusieurs cas à distinguer. Je mettrais d'un côté la parallélisme de calcul scientifique lourd par exemple utilisant 192+ cœurs ou bien des circuits programmables, dans ce cas on passe en général par des outils spécialisés qu'on contrôle avec OCaml (ou Go, ou autre), par exemple en écrivant un binding ou un programme externe. D'un autre côté il y a le parallélisme de traitement où les entrées-sorties sont le facteur limitant. Par exemple le classique server web ou bien la recherche dans une grosse base de donnés. Ici je trouve que la question du support de ce genre de parallélisme est un peu "90s" car aujourd'hui l'approche consistant à écrire des programmes à un seul fil d'exécution dont on lance de multiples copies en ajoutant un ou plusieurs processus de synchronisation (comme un répartiteur de charge ou une queue de travail) est très populaire. Les avantages de cette approche sur les fils multiples dans un même programme est que l'application est logiquement plus simple et l'augmentation de capacité se fait selon une seule variable, le nombre de processus vs. le nombre de processus * le nombre de fils. Cette technique introduit cependant des difficultés liées à la décentralisation de l'information, la mettre en œuvre peut donc mener à des problèmes difficiles de partage d'information.
Pour OCaml il existe la bibliothèque Lwt qui utilise la même approche que NodeJS où deux fils d'exécution invisibles à l'utilisateur existent, l'un s'occupe du bytecode ou de la logique du programme et l'autre s'occupe des entrées-sorties. Ainsi l'utilisateur peut penser à son application comme à un processus monofil tout en bénéficiant du parallélisme d'exécution. Combinée à des bibliothèques comme Cohttp (client et seveur HTTTP) ou webmachine, on peut facilement écrire des micro-services HTTP/JSON en OCaml.
PS.: La communauté OCaml monte en activité ces dernières années. Elle est maintenant solidement implantée dans l'industrie, ce qui présage de nombreux développements positifs pour le futur!