Erlang est un peu différent, erlang est né d'un besoin venant de l'industrie.
Ce langage a été créé pour pour répondre à des problématique bien précises.
Les plus notables sont:
- La tolérance au panne,
- La rapidité de maquettage,
- La haute disponibilité.
Le langage est fonctionnel ce qui signifie pour nous programmeurs (en simplifié :) que les closures et la récurrence sont omniprésents. Que les travaux sur les listes ou les arbres sont courants.
Malheureusement pour parler de erlyweb je dirais que ce projet tente de recopier RoR, alors que RoR est bati sur un langage complètement différent.
Erlang c'est de la programmation concurrente, et c'est bien là toute la différence avec les autres langage objets (Python, Ruby, Php) ou pas (Php) disponibles... Erlang rejette la notion d'objet, il mets en avant la notion de clients serveurs.
De son point de vue, un objet et un serveur et ses méthodes sont simplement des requètes faites à ce serveur.
L'énorme avantage d'Erlang est aussi sa plus grande difficulté d'accès est le 'share anything paradigm'.
Aucune donnée n'est partagée, tout se fait à travers des messages.
(imaginer une rue commercante où tout les marchants crieraient pour discuter entre eux d'un côté à l'autre, le boulanger faire cuire son pain pendant qu'il réponds au boucher qui fait rôtir son poulet... Le monde est concurrent, ma femme arrive à tenir deux conversations etc.)
Les processus discutent en échangeant des messages de manière asynchrones.
Je lisais encore tout à l'heure pourquoi le projet MERB http://www.railspikes.com/2007/4/1/merb est né, à savoir, avec Mongrel il était visiblement difficile de faire de l'upload de fichier...
Ruby semblait bloquer, or ce n'est pas exactement ce qui se passait et c'est pourquoi MERB est né.
Ce que mets en évidence MERB c'est tout simplement que la concurrence n'était pas gérer du tout dans Ruby (j'exagère à peine).
Et la véritable raison à cela est tout simplement que les programmeurs actuels ne sont pas du tout capables de penser concurrence. La formation n'existe quasiment pas et la culture n'aide pas les éventuels aventuriers du domaine.
Il fait se rendre à l'évidence le modèle concurrent bien plus 'naturel' n'est pas encore à la portée de tous.
Cependant la concurrence nous allons tous devoir nous y mettre, il est tout simplement impensable à l'heure actuelle d'ignorer l'arrivée de processeurs à plusieur coeurs.
Tant que la programmation par sémaphore et par "shared memory" sera utilisée les programmes ne seront pas capables de bénéficier de toute la puissance des nouveaux processeurs.
Penser un programme de manière concurrente cela veut dire qu'on est capable de le faire fonctionner (sans réécrire quoi que ce soit) sur un processeur multicoeur mais aussi sur une grape de serveur... (erlang rends le réseau transparent, les processus ne sont pas que locaux)
Afin de peut être vous familiariser avec ces notions je vous invite à regarder la http://qcon.infoq.com/sanfrancisco/file?path=/QConSF2007/sli(...) présentation de Randy Shoup (eBay) et plus particulièrement la page 4 décrivant les stratégies adoptées par eBay:
Strategy 1: Partition Everything
– "How do you eat an elephant? ... One bite at a time"
Strategy 2: Async Everywhere
– "Good things come to those who wait"
Strategy 3: Automate Everything
– "Give a man a fish and he eats for a day ... Teach a man to fish and he eats for alifetime"
Strategy 4: Remember Everything Fails
– "Be Prepared"
Pour les plus curieux je tiens un blog sur erlang: http://easyerl.blogspot.com/
le propos est de montrer qu'erlang est adapté à beaucoup plus de tâches qu'on ne pense, et a fortiori au développement web...
[^] # Re: erlang ?
Posté par forc3 . En réponse au journal Ror ne se porte plus très bien ? Quid des autres ?. Évalué à 2.
Erlang est un peu différent, erlang est né d'un besoin venant de l'industrie.
Ce langage a été créé pour pour répondre à des problématique bien précises.
Les plus notables sont:
- La tolérance au panne,
- La rapidité de maquettage,
- La haute disponibilité.
Les livres et documentation officielle traitant du sujet en parleront mieux que moi:
http://erlang.org/doc/getting_started/part_frame.html
Le langage est fonctionnel ce qui signifie pour nous programmeurs (en simplifié :) que les closures et la récurrence sont omniprésents. Que les travaux sur les listes ou les arbres sont courants.
Malheureusement pour parler de erlyweb je dirais que ce projet tente de recopier RoR, alors que RoR est bati sur un langage complètement différent.
Erlang c'est de la programmation concurrente, et c'est bien là toute la différence avec les autres langage objets (Python, Ruby, Php) ou pas (Php) disponibles... Erlang rejette la notion d'objet, il mets en avant la notion de clients serveurs.
De son point de vue, un objet et un serveur et ses méthodes sont simplement des requètes faites à ce serveur.
L'énorme avantage d'Erlang est aussi sa plus grande difficulté d'accès est le 'share anything paradigm'.
Aucune donnée n'est partagée, tout se fait à travers des messages.
(imaginer une rue commercante où tout les marchants crieraient pour discuter entre eux d'un côté à l'autre, le boulanger faire cuire son pain pendant qu'il réponds au boucher qui fait rôtir son poulet... Le monde est concurrent, ma femme arrive à tenir deux conversations etc.)
Les processus discutent en échangeant des messages de manière asynchrones.
Je lisais encore tout à l'heure pourquoi le projet MERB http://www.railspikes.com/2007/4/1/merb est né, à savoir, avec Mongrel il était visiblement difficile de faire de l'upload de fichier...
Ruby semblait bloquer, or ce n'est pas exactement ce qui se passait et c'est pourquoi MERB est né.
Ce que mets en évidence MERB c'est tout simplement que la concurrence n'était pas gérer du tout dans Ruby (j'exagère à peine).
Et la véritable raison à cela est tout simplement que les programmeurs actuels ne sont pas du tout capables de penser concurrence. La formation n'existe quasiment pas et la culture n'aide pas les éventuels aventuriers du domaine.
Il fait se rendre à l'évidence le modèle concurrent bien plus 'naturel' n'est pas encore à la portée de tous.
Cependant la concurrence nous allons tous devoir nous y mettre, il est tout simplement impensable à l'heure actuelle d'ignorer l'arrivée de processeurs à plusieur coeurs.
Tant que la programmation par sémaphore et par "shared memory" sera utilisée les programmes ne seront pas capables de bénéficier de toute la puissance des nouveaux processeurs.
Penser un programme de manière concurrente cela veut dire qu'on est capable de le faire fonctionner (sans réécrire quoi que ce soit) sur un processeur multicoeur mais aussi sur une grape de serveur... (erlang rends le réseau transparent, les processus ne sont pas que locaux)
Afin de peut être vous familiariser avec ces notions je vous invite à regarder la http://qcon.infoq.com/sanfrancisco/file?path=/QConSF2007/sli(...) présentation de Randy Shoup (eBay) et plus particulièrement la page 4 décrivant les stratégies adoptées par eBay:
Strategy 1: Partition Everything
– "How do you eat an elephant? ... One bite at a time"
Strategy 2: Async Everywhere
– "Good things come to those who wait"
Strategy 3: Automate Everything
– "Give a man a fish and he eats for a day ... Teach a man to fish and he eats for alifetime"
Strategy 4: Remember Everything Fails
– "Be Prepared"
Une autre excellente introduction au monde concurrent est visionnable dans une conférence http://www.google.fr/url?sa=t&ct=res&cd=1&url=ht(...) mémorable de http://fr.wikipedia.org/wiki/Alan_Kay ... (apprécier le parallèle avec le corps humain et les cellules...)
Pour les plus curieux je tiens un blog sur erlang: http://easyerl.blogspot.com/
le propos est de montrer qu'erlang est adapté à beaucoup plus de tâches qu'on ne pense, et a fortiori au développement web...