De PHP à Go : ce qui m'a pris le plus de temps à réapprendre
J'ai écrit du PHP pendant sept ans. J'ai utilisé Laravel pendant cinq d'entre eux. Lorsque je suis passé à Go pour diriger une migration d'un monolithe Laravel vers des microservices, je n'étais pas arrivé avec un tutoriel. J'étais arrivé avec une décennie d'habitudes PHP.
Apprendre la syntaxe a été facile. On peut lire du Go en un après-midi. Le plus difficile a été de désapprendre ma façon de concevoir le code.
Voici les changements de mentalité qui m'ont pris des mois à maîtriser :
Gestion des erreurs En PHP, j'utilisais try/catch. Les erreurs voyageaient souvent de manière invisible vers un gestionnaire global. En Go, les erreurs sont des valeurs. Une fonction retourne une erreur comme dernière valeur. Vous devez la gérer sur-le-champ. Au début, cela me semblait être un travail supplémentaire. Plus tard, j'ai réalisé que cela rend l'échec visible. Lorsqu'un service échoue, le message d'erreur agit comme un fil d'Ariane. Il vous indique exactement où l'échec s'est produit sans nécessiter une énorme stack trace.
Mémoire et état PHP utilise un modèle "shared-nothing". Chaque requête repart de zéro. Les fuites de mémoire importent moins car le processus meurt après la requête. Go est différent. Le processus reste en vie pour des milliers de requêtes. Cela signifie qu'une variable au niveau du package est partagée entre chaque requête. Si deux requêtes tentent d'écrire dans une map en même temps, tout le programme plante. En Go, vous gérez la concurrence. Vous devez utiliser des outils comme le race detector pour garantir la sécurité.
Le rôle du contexte En PHP, la requête est la limite. Quand la requête se termine, tout s'arrête. En Go, rien ne s'arrête automatiquement. Si un client se déconnecte, vos goroutines peuvent continuer à s'exécuter et à gaspiller des ressources. Vous devez utiliser context.Context pour transmettre des signaux d'annulation à travers votre code. C'est la colonne vertébrale qui maintient la santé de votre service sous une charge importante.
La composition plutôt que l'héritage Laravel repose largement sur l'extension de classes de base. Vous ajoutez des fonctionnalités en héritant de comportements. Go n'a pas d'héritage de classe. Il utilise des interfaces qui sont satisfaites implicitement. Vous définissez ce dont vous avez besoin là où vous l'utilisez. Cela rend le code plus facile à tester et à remplacer. J'ai dû tuer mon instinct d'étendre tout pour écrire du bon Go.
La clarté plutôt que l'astuce PHP permet les méthodes magiques et le typage dynamique. On peut écrire du code astucieux et expressif. Go est délibérément ennuyeux. Le compilateur vous oblige à utiliser un formatage standard et empêche l'utilisation de variables inutilisées. Au début, cela semblait restrictif. Maintenant, j'apprécie cela. Go est optimisé pour la personne qui lit le code, pas pour celle qui l'écrit. Un code ennuyeux est facile à corriger à 2 heures du matin lors d'un incident.
Le plus difficile dans l'apprentissage d'un nouveau langage n'est pas la nouvelle syntaxe. Ce sont les anciennes certitudes que vous transportez avec vous.
Source: https://dev.to/econ__11/from-php-to-go-what-took-me-longest-to-rewire-2nfn
