J'observe la visibilité croissante des langages de programmation fonctionnels et des fonctionnalités depuis un certain temps. Je les ai examinés et je n'ai pas vu la raison de l'appel.
Puis, récemment, j'ai assisté à la présentation "Basics of Erlang" de Kevin Smith à Codemash .
J'ai apprécié la présentation et j'ai appris que de nombreux attributs de la programmation fonctionnelle permettent d'éviter les problèmes de thread / concurrence. Je comprends que le manque d'état et la mutabilité empêchent plusieurs threads de modifier les mêmes données, mais Kevin a déclaré (si j'ai bien compris) que toutes les communications se font par le biais de messages et que les messages sont traités de manière synchrone (évitant encore une fois les problèmes de concurrence).
Mais j'ai lu qu'Erlang est utilisé dans des applications hautement évolutives (la raison pour laquelle Ericsson l'a créé en premier lieu). Comment gérer efficacement des milliers de requêtes par seconde si tout est traité comme un message traité de manière synchrone? N'est-ce pas la raison pour laquelle nous avons commencé à évoluer vers le traitement asynchrone - afin que nous puissions profiter de l'exécution de plusieurs threads d'opération en même temps et atteindre l'évolutivité? Il semble que cette architecture, bien que plus sûre, soit un pas en arrière en termes d'évolutivité. Qu'est-ce que je rate?
Je comprends que les créateurs d'Erlang ont délibérément évité de prendre en charge le threading pour éviter les problèmes de concurrence, mais je pensais que le multi-threading était nécessaire pour atteindre l'évolutivité.
Comment les langages de programmation fonctionnels peuvent-ils être intrinsèquement thread-safe, tout en restant évolutifs?