Tu peux quasiment tout faire dans tous les langages, donc demander ce que Java n'est pas capable de faire n'a que peu de sens. A la limite, on peut s'interroger sur l'implémentation de la machine virtuelle. Le langage n'est en revanche qu'une syntaxe.
Maitenant, suivant ce que tu souhaites développer, c'est plus où moins difficile à faire avec certains outils et plus facile avec d'autres. C'est pour l'environnement Erlang (baptisé OTP) qu'Erlang va au-delà de la simple syntaxe.
Développer une application robuste, distribuée, tolérante aux pannes en Erlang est facilité par le fait que c'est un langage conçu pour la concurrence ( quand je dis concurrence, je pense à plusieurs dizaines, voire centaines de milliers de processus simultanés sur une machine de base d'aujourd'hui. La limite est purement matérielle) et une approche fonctionnelle qui limite les effets de bords et donc facilite la conception d'applications concurrentes.
Pour te donner un exemple, le design le plus logique d'un serveur web consiste à suivre le modèle suivant: Lorsqu'un client web se connecte, je crée un nouveau processus pour traiter les échanges avec ce client. Les requêtes peuvent ainsi être satisfaites simultanément et la conception est correcte quel que soit le nombre de clients qui se connectent.
Maintenant, si tu utilises un langage qui limite l'utilisation des processus (parce qu'ils sont trop gros ou trop couteux à lancer), ce design n'est plus valable. Tu va devoir limiter le nombre de processus simultanément lancés. Et donc modifier ton design parce que l'environnement d'exécution ne supporte pas ta conception.
Joe Armstrong, le créateur du langage Erlang, a coutume de faire l'anologie suivante: Utiliser un langage qui limite la concurrence de l'application (par le biais de la limite du nombre de processus), c'est comme utiliser un langage objet qui limiterait le nombre d'objets qu'il est possible d'instancier. Erlang utilise la notion de processus d'une manière que l'on peut comparer à l'utilisation des objets dans d'autres langages).
Tu peux d'ailleurs jeter un oeil sur le serveur Web dynamique Yaws, développé en Erlang: Il est superperformant (tu obtiens facilement 800/1000 pages secondes pour du code dynamique) et occupe au max 10 à 20 mégas de RAM (Personnellement, je ne l'ai jamais vu dépasser 20 mégas).
Donc, avec la machine Java actuelle, ce que tu ne peux pas faire: Atteindre un haut niveau de concurrence. Erlang est fait pour cela. C'est un langage orienté concurrence et c'est pour cela qu'il est très adapté au développement d'applications serveurs.
En plus, tu disposes d'un grand nombre de facilités pour mettre à jour le code d'une application à chaud, sans interrompre les connexions en cours de traitement, pour distribué une application sur un ensemble de noeud pour des objectifs de montée en charge ou de tolérance aux pannes, etc. Tu peux éventuellement, peut-être recoder cela en Java, mais ne sous-estime pas la tâche. C'est non trivial. Erlang fait cela depuis 10 ans et c'est très bien testé et robuste. Bref, j'entrevois un grand avenir pour Erlang pour le développement d'applications côté serveur.
[^] # Re: Erlang est un environnement INDUSTRIEL !
Posté par Mickaël Rémond . En réponse à la dépêche Interview d'auteurs: Erlang, Services Web, J2EE, ASP.net. Évalué à 4.
Maitenant, suivant ce que tu souhaites développer, c'est plus où moins difficile à faire avec certains outils et plus facile avec d'autres. C'est pour l'environnement Erlang (baptisé OTP) qu'Erlang va au-delà de la simple syntaxe.
Développer une application robuste, distribuée, tolérante aux pannes en Erlang est facilité par le fait que c'est un langage conçu pour la concurrence ( quand je dis concurrence, je pense à plusieurs dizaines, voire centaines de milliers de processus simultanés sur une machine de base d'aujourd'hui. La limite est purement matérielle) et une approche fonctionnelle qui limite les effets de bords et donc facilite la conception d'applications concurrentes.
Pour te donner un exemple, le design le plus logique d'un serveur web consiste à suivre le modèle suivant: Lorsqu'un client web se connecte, je crée un nouveau processus pour traiter les échanges avec ce client. Les requêtes peuvent ainsi être satisfaites simultanément et la conception est correcte quel que soit le nombre de clients qui se connectent.
Maintenant, si tu utilises un langage qui limite l'utilisation des processus (parce qu'ils sont trop gros ou trop couteux à lancer), ce design n'est plus valable. Tu va devoir limiter le nombre de processus simultanément lancés. Et donc modifier ton design parce que l'environnement d'exécution ne supporte pas ta conception.
Joe Armstrong, le créateur du langage Erlang, a coutume de faire l'anologie suivante: Utiliser un langage qui limite la concurrence de l'application (par le biais de la limite du nombre de processus), c'est comme utiliser un langage objet qui limiterait le nombre d'objets qu'il est possible d'instancier. Erlang utilise la notion de processus d'une manière que l'on peut comparer à l'utilisation des objets dans d'autres langages).
Tu peux d'ailleurs jeter un oeil sur le serveur Web dynamique Yaws, développé en Erlang: Il est superperformant (tu obtiens facilement 800/1000 pages secondes pour du code dynamique) et occupe au max 10 à 20 mégas de RAM (Personnellement, je ne l'ai jamais vu dépasser 20 mégas).
Donc, avec la machine Java actuelle, ce que tu ne peux pas faire: Atteindre un haut niveau de concurrence. Erlang est fait pour cela. C'est un langage orienté concurrence et c'est pour cela qu'il est très adapté au développement d'applications serveurs.
En plus, tu disposes d'un grand nombre de facilités pour mettre à jour le code d'une application à chaud, sans interrompre les connexions en cours de traitement, pour distribué une application sur un ensemble de noeud pour des objectifs de montée en charge ou de tolérance aux pannes, etc. Tu peux éventuellement, peut-être recoder cela en Java, mais ne sous-estime pas la tâche. C'est non trivial. Erlang fait cela depuis 10 ans et c'est très bien testé et robuste. Bref, j'entrevois un grand avenir pour Erlang pour le développement d'applications côté serveur.
Mickaël