Ah, bien comme commentaire, j'aurais aimer que tu argumentes un peu ...
En revanche j'admets tout à fait que pour la gestion des caractères sous forme de liste peut sembler être lourd, c'est le cas, mais c'est également pour cette raison que le type binary est utilisé (notation en << >>).
Maintenant il est toujours (et peut importe le language) de générer un automate pour parser un fichier XML que d'utiliser DOM, XPATH et tout ce que tu veux.
Je défis quiconque de réaliser un parser avec libxml2 pour ne citer que le meilleur, qui irait plus vite qu'un code générer à partir de flex (même pas besoin de bison/yacc) pour parser exactement les même tags...
Et oh grand bonheur, dans le code source de erlang tu peux trouver l'application megaco qui utilise justement un parseur générer à l'aide de flex, tout simplement pour des soucis de performances (et certainement de rapidité de développement pour le ou les auteurs).
ejabberd utilise libexpat pour parser son XML.
Dernier point, même si me prouve qu'à traitement équivalent erlang est plus lent, lorsque tu veux augmenter ta puissance de calcul en ajoutant des noeuds à ton réseau je peux te garantir qu'erlang au final l'emportera.
Regarde du côté du MapReduce ( de google ) et essai peut être de comprendre que la vitesse n'ai absolument pas le but ultime, le but ultime c'est d'avoir une plateforme
dans laquelle tu peux
ajouter 1 noeud, retirer 1 noeud quand tu veux et sans perturber le service,
une plateforme qui peut grossir horizontalement.
Un noeud (une machine on va dire) utilisé à 100% de sa puissance à 100% du temps est une énorme erreur.
Ce noeud ne pourra pas encaisser une charge soudaine, devient difficile à administrer (pense à toute les sondes de surveillance système et métiers) et est primordiale à la plateforme, c'est à dire que si elle tombe les autres machines de la plateforme ne pourront tenir la charge globale...
Erlang c'est pour bâtir des architectures solides dans un monde où 100% du temps seul 90% (on va dire) du matériel fonctionne...
Cadeau bonus:
études de cas
Ce lien ne parle pas d'erlang en particulier mais d'architecture, et la conclusion est que le brique qui ont été nécessaires existent ou sont triviales à implémenter en erlang...
[^] # Re: Erlang ?
Posté par forc3 . En réponse au journal L'expressivité des langages. Évalué à 3.
En revanche j'admets tout à fait que pour la gestion des caractères sous forme de liste peut sembler être lourd, c'est le cas, mais c'est également pour cette raison que le type binary est utilisé (notation en << >>).
Maintenant il est toujours (et peut importe le language) de générer un automate pour parser un fichier XML que d'utiliser DOM, XPATH et tout ce que tu veux.
Je défis quiconque de réaliser un parser avec libxml2 pour ne citer que le meilleur, qui irait plus vite qu'un code générer à partir de flex (même pas besoin de bison/yacc) pour parser exactement les même tags...
Et oh grand bonheur, dans le code source de erlang tu peux trouver l'application megaco qui utilise justement un parseur générer à l'aide de flex, tout simplement pour des soucis de performances (et certainement de rapidité de développement pour le ou les auteurs).
ejabberd utilise libexpat pour parser son XML.
Dernier point, même si me prouve qu'à traitement équivalent erlang est plus lent, lorsque tu veux augmenter ta puissance de calcul en ajoutant des noeuds à ton réseau je peux te garantir qu'erlang au final l'emportera.
Regarde du côté du MapReduce ( de google ) et essai peut être de comprendre que la vitesse n'ai absolument pas le but ultime, le but ultime c'est d'avoir une plateforme
dans laquelle tu peux
ajouter 1 noeud, retirer 1 noeud quand tu veux et sans perturber le service,
une plateforme qui peut grossir horizontalement.
Un noeud (une machine on va dire) utilisé à 100% de sa puissance à 100% du temps est une énorme erreur.
Ce noeud ne pourra pas encaisser une charge soudaine, devient difficile à administrer (pense à toute les sondes de surveillance système et métiers) et est primordiale à la plateforme, c'est à dire que si elle tombe les autres machines de la plateforme ne pourront tenir la charge globale...
Erlang c'est pour bâtir des architectures solides dans un monde où 100% du temps seul 90% (on va dire) du matériel fonctionne...
Cadeau bonus:
études de cas
Ce lien ne parle pas d'erlang en particulier mais d'architecture, et la conclusion est que le brique qui ont été nécessaires existent ou sont triviales à implémenter en erlang...