Erlang

La première fois que tu touches à Erlang, tu te dis :
“OK, c’est moche, bizarre, et y’a pas de boucles. Je fais quoi avec ça ?”

Et puis tu creuses.
Et là tu captes un truc : ce langage a été conçu pour échouer.

Pas dans le sens rater.
Dans le sens assumer que tout va péter un jour.

C’est Ericsson qui l’a créé dans les années 80.
Ils devaient gérer des millions d’appels téléphoniques, des antennes relais, des systèmes qui doivent rester allumés H24.

Et ils se sont dit : “Plutôt que d’essayer de faire du code qui ne plante jamais…
On va faire du code qui plante bien.”

C’est là que naît le “let it crash”.
Tu ne gères pas les erreurs comme dans les autres langages.
Tu laisses ton process mourir, et un autre le redémarre proprement, sans drama.

Chaque process est isolé. Pas de partage d’état.
Tu veux bosser en parallèle ? Tu spawnes un million de petits workers, chacun dans sa bulle.
Comme des microservices avant l’heure.

Résultat : t’as un système résilient.
Tu peux tout crasher sauf le superviseur, et ton appli continue de tourner.

C’est pour ça que WhatsApp l’a utilisé.
Des millions de users, sur une équipe dev minuscule.
Pas de scaling horizontal compliqué, pas de kafka, pas de microservices dans tous les sens. Juste du Erlang bien pensé, et ça tient.

Mais voilà.
C’est pas sexy.
La syntaxe pique les yeux.
Et quand t’en parles en soirée dev, tu passes pour un moine Shaolin chelou qui médite sur la tolérance aux pannes.

Et pourtant, ce langage t’apprend un truc essentiel :
Accepte que tout va planter un jour. Prévois-le. Rends ça propre.

👉 Tu l’as déjà croisé Erlang ? Ou t’as juste vu passer Elixir sans comprendre d’où ça venait ?