Pareil avec un GC : si tu gardes une référence vers un objet inutilement, ni Rust, ni Go, ni aucun langage ne va t'aider.
La gestion de l'ownership réduit pas mal le risque, mais tu as toujours la possibilité d'écrire des algos monstrueux d'un point de vue mémoire.
Je suis tombé il y a quelques semaines sur un exercice de simplification sur twitter où pour passer d'un algo en O(n4) à O(n2) pas mal de participants alloués une map de n2 éléments.
Même s'il n'a pas de garantie contre ça le borrow checker va limiter les risques de bugs quand tu voudra corriger.
La JVM et son outillage sont aussi de grandes aides pour détecter et corriger des problèmes mémoire. Je ne connais pas d'équivalent à Memory Analyser ailleurs par exemple.
[^] # Re: Ne pas craindre la Faucheuse
Posté par barmic 🦦 . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été. Évalué à 1.
La gestion de l'ownership réduit pas mal le risque, mais tu as toujours la possibilité d'écrire des algos monstrueux d'un point de vue mémoire.
Je suis tombé il y a quelques semaines sur un exercice de simplification sur twitter où pour passer d'un algo en O(n4) à O(n2) pas mal de participants alloués une map de n2 éléments.
Même s'il n'a pas de garantie contre ça le borrow checker va limiter les risques de bugs quand tu voudra corriger.
La JVM et son outillage sont aussi de grandes aides pour détecter et corriger des problèmes mémoire. Je ne connais pas d'équivalent à Memory Analyser ailleurs par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll