Erlang permet de gerer trés facilement la "clusterisation" de ton serveur, ce qui permet une mise à l'échelle horizontale en cas de monté de la charge ( à condition d'avoir les compétences, et que je ne raconte pas de la merde avec du jargon que je maitrise pas :) ).
Ejabberd est pas le seul gros projet en erlang, tu as aussi couchdb, un des fers de lance du mouvement nosql, et qu'on retrouve notament derriére UbuntuOne, le service proprio de Canonical. La aussi, on se retrouve avec un systéme facilement clusterisable, qui monte à l'echelle en rajoutant des serveurs, etc.
Je pense pas qu'Erlang soit un mauvais choix, et c'est pas si complexe à utiliser, j'ai vu largement pire et moins documenté ( genre le ncl : http://www.ncl.ucar.edu/, lors d'une mission dans un laboratoire à Paris ). Mais faire des opérations avancés comme traquer une fuite mémoire, c'est complexe, en erlang comme en C. Et je pense que les admins de jabber.org ont aussi commencé par se tourner vers process-one avant tout.
[^] # Re: Pourquoi cette solution?
Posté par Misc (site web personnel) . En réponse à la dépêche Jabber.org se tourne vers un serveur propriétaire. Évalué à 3.
Ejabberd est pas le seul gros projet en erlang, tu as aussi couchdb, un des fers de lance du mouvement nosql, et qu'on retrouve notament derriére UbuntuOne, le service proprio de Canonical. La aussi, on se retrouve avec un systéme facilement clusterisable, qui monte à l'echelle en rajoutant des serveurs, etc.
Je pense pas qu'Erlang soit un mauvais choix, et c'est pas si complexe à utiliser, j'ai vu largement pire et moins documenté ( genre le ncl : http://www.ncl.ucar.edu/, lors d'une mission dans un laboratoire à Paris ). Mais faire des opérations avancés comme traquer une fuite mémoire, c'est complexe, en erlang comme en C. Et je pense que les admins de jabber.org ont aussi commencé par se tourner vers process-one avant tout.