Dans 99% des cas tu m'as pas besoin d'unsafe. Et quand on l'utilise, on s'arrange pour avoir un bloc le plus petit possible, comme ça on ne fait que de la merde dans la fonction actuelle et la zone non-sûre à vérifier est beaucoup plus réduite en cas de bug inhabituel.
C'est un peu comme du Python ou du Java avec un bout de C pour les trucs nécessitant de la vitesse. En cas de segfault, il n'y a que le petit bout de C à vérifier. Sauf que Rust est plus sûr que Python ou Java et surtout suffisant rapide pour n'avoir que très rarement besoin de pointeurs nus.
Rust sera (attendons quand même la 1.0 tout de même!) un langage très intéressant pour remplacer le C++: au lieu de devoir être un super-développeur et de devoir utiliser des outils externes pour trouver les bugs, passer sa vie sur StackOverflow à cause de deux parenthèses en trop (histoire vraie., il suffit de comprendre le système de durée de vie et de corriger les erreurs indiquées par le compilateur. Il permet également de corriger des erreurs plus subtiles, puisqu'il y a zéro conversion de type implicite (même de int à double).
Enfin, c'est plus agréable pour plein de trucs (pas exempleuint au lieu de unsigned int, le filtrage par motif c'est la vie, possible de faire la déclaration d'une fonction en haut du fichier et la définir après mais pas obligatoire et surtout pas besoin de fichiers d'en-têtes (le truc que je trouve le plus chiant avec C++ quand tu débutes un projet), etc), c'est plus facile à parser/grepperfonction (let, variable: let — en C/C++ les deux déclarations commencent par le type ou const, des fois le «type» est deux parties — unsigned int, etc).
Le C++14 c'est cool, mais ça fait longtemps que j'attends le système de module pour me passer des fichiers d'en-têtes et ça n'arrive pas. Et les mots d'erreurs sont trop souvent imbitables, même si ça c'est clairement amélioré. La dette technique du C++ fait que certains défauts resteront à tout jamais, et que les améliorationt arrivent lentement, au prix d'une complexité qui décourage le portable des fonctionnalités C++11 par exemple beaucoup de plateformes.
[^] # Re: Rust vs Go
Posté par ariasuni . En réponse à la dépêche Rust s’oxyde en version 0.10. Évalué à 6. Dernière modification le 12 avril 2014 à 12:05.
Dans 99% des cas tu m'as pas besoin d'
unsafe. Et quand on l'utilise, on s'arrange pour avoir un bloc le plus petit possible, comme ça on ne fait que de la merde dans la fonction actuelle et la zone non-sûre à vérifier est beaucoup plus réduite en cas de bug inhabituel.C'est un peu comme du Python ou du Java avec un bout de C pour les trucs nécessitant de la vitesse. En cas de segfault, il n'y a que le petit bout de C à vérifier. Sauf que Rust est plus sûr que Python ou Java et surtout suffisant rapide pour n'avoir que très rarement besoin de pointeurs nus.
Rust sera (attendons quand même la 1.0 tout de même!) un langage très intéressant pour remplacer le C++: au lieu de devoir être un super-développeur et de devoir utiliser des outils externes pour trouver les bugs, passer sa vie sur StackOverflow à cause de deux parenthèses en trop (histoire vraie., il suffit de comprendre le système de durée de vie et de corriger les erreurs indiquées par le compilateur. Il permet également de corriger des erreurs plus subtiles, puisqu'il y a zéro conversion de type implicite (même de
intàdouble).Enfin, c'est plus agréable pour plein de trucs (pas exemple
uintau lieu deunsigned int, le filtrage par motif c'est la vie, possible de faire la déclaration d'une fonction en haut du fichier et la définir après mais pas obligatoire et surtout pas besoin de fichiers d'en-têtes (le truc que je trouve le plus chiant avec C++ quand tu débutes un projet), etc), c'est plus facile à parser/grepperfonction (let, variable:let— en C/C++ les deux déclarations commencent par le type ouconst, des fois le «type» est deux parties — unsigned int, etc).Le C++14 c'est cool, mais ça fait longtemps que j'attends le système de module pour me passer des fichiers d'en-têtes et ça n'arrive pas. Et les mots d'erreurs sont trop souvent imbitables, même si ça c'est clairement amélioré. La dette technique du C++ fait que certains défauts resteront à tout jamais, et que les améliorationt arrivent lentement, au prix d'une complexité qui décourage le portable des fonctionnalités C++11 par exemple beaucoup de plateformes.
Écrit en Bépo selon l’orthographe de 1990