Ca dépend ? Qui veux-t-on comme gagnant ? Si on veut juste se rassurer sur l'inutilité à apprendre un autre langage que le C je suggère le calcul de décimales de Pi ou des suites de Fibonacci en mono processus - mono utilisateur. Le C devrait plier à peu près tout ce qui passe. Erlang va apparaitre comme lent et gourmand en mémoire.
Par contre si on s'amuse à faire un bête programe qui créé 200 serveurs intersynchronisés (comme par exemple pour un MMORPG) et que l'on connecte dessus quelques dizaines de milliers de clients on risque d'avoir 99% des programmeurs C qui vont avoir vraiment du mal. Alors que les programmeurs Erlang ayant un peu d'expérience devraient s'en sortir tous a peu près convenablement. Alors après reste la question de savoir qui entre le meilleur programmeur C et le meilleur programmeur Erlang du monde remporterait la palme. En toute honnêteté ce serait probablement le meilleur programmeur C du monde, mais le meilleur programmeur Erlang du monde aurait à coup sur un code maintenable par d'autres que le meilleur programmeur Erlang du monde.
Erlang à un très fort overhead (charge initiale), donc lui faire éxecuter des petits programmes en boucle le met forcément en position de faiblesse. Ceci dit il scale (monte en charge) très bien (très très même).
De toutes les façons, le langage Erlang est certes turing complet, mais il est destiné très prioritairement aux applications communicantes (archi point à point, client/serveur, n tiers etc.) de fait le comparer avec un langage aussi généraliste que le C n'a pas grand intéret. On pourrait éventuellement imaginer un bench d'une bibliothèque réseau ou IPC face à Erlang, mais comparer brut de décoffrage C et Erlang revent à la bonne vieille comparaison entre le couteau et la fourchette.
[^] # Re: ...
Posté par Jerome Herman . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 10.
Ca dépend ? Qui veux-t-on comme gagnant ? Si on veut juste se rassurer sur l'inutilité à apprendre un autre langage que le C je suggère le calcul de décimales de Pi ou des suites de Fibonacci en mono processus - mono utilisateur. Le C devrait plier à peu près tout ce qui passe. Erlang va apparaitre comme lent et gourmand en mémoire.
Par contre si on s'amuse à faire un bête programe qui créé 200 serveurs intersynchronisés (comme par exemple pour un MMORPG) et que l'on connecte dessus quelques dizaines de milliers de clients on risque d'avoir 99% des programmeurs C qui vont avoir vraiment du mal. Alors que les programmeurs Erlang ayant un peu d'expérience devraient s'en sortir tous a peu près convenablement. Alors après reste la question de savoir qui entre le meilleur programmeur C et le meilleur programmeur Erlang du monde remporterait la palme. En toute honnêteté ce serait probablement le meilleur programmeur C du monde, mais le meilleur programmeur Erlang du monde aurait à coup sur un code maintenable par d'autres que le meilleur programmeur Erlang du monde.
Erlang à un très fort overhead (charge initiale), donc lui faire éxecuter des petits programmes en boucle le met forcément en position de faiblesse. Ceci dit il scale (monte en charge) très bien (très très même).
De toutes les façons, le langage Erlang est certes turing complet, mais il est destiné très prioritairement aux applications communicantes (archi point à point, client/serveur, n tiers etc.) de fait le comparer avec un langage aussi généraliste que le C n'a pas grand intéret. On pourrait éventuellement imaginer un bench d'une bibliothèque réseau ou IPC face à Erlang, mais comparer brut de décoffrage C et Erlang revent à la bonne vieille comparaison entre le couteau et la fourchette.