Bah non justement, en Rust les concepts ne sont pas masqués :
allocation dynamique sur la heap ? Box<T>
allocation dynamique avec refcounting pour pouvoir partager une même ressource ? Rc<T>
je veux partager la même data en lecture mais pas en écriture (copy on write) ? Cow<T>
je veux protéger l'accès concurrentiel à une donnée ? Mutex<T> souvent avec Arc<Mutex<T>>
je veux créer une structure qui est thread-safe ? Implémentation de Send et/ou Sync
...
Il n'y a rien de plus explicite, ces informations apparaissent dans le système de type qui va permettre au compilateur de s'assurer que les règles qui gouvernent ces concepts sont bien respectées.
la syntaxe est moche
C'est subjectif. Je trouve aussi que la syntaxe est lourde, mais c'est pas plus moche que des templates C++ qu'on observe en masse dans les librairies "header only" (beurk).
les temps de compilation tendent vers l'infini ;
Exagération obsolète.
Ca compile plus vite que du C++ (de mon expérience personnelle et anecdotique)
sous prétexte d'être plus "safe", on doit se prendre la tête avec 42 concepts qui polluent le code ;
C'est pas sous prétexte d'être plus safe. C'est sous prétexte de prendre aucune décision pour le développeur. On le laisse gérer lui même pour qu'il puisse faire des applications performantes, on le laisse choisir lui même les trade-offs.
Le Go est un langage safe aussi, mais les trade-offs ont été choisi par les développeurs du langage/compilateur. Et toi, pauvre petit développeur, tu dois faire avec.
c'est safe, mais dès l'exemple de base de wgpu, on se retrouve avec un bloc "unsafe".
Ca j'ai mis pas mal de temps à le comprendre. Mais en gros, le choix qui a été fait par les développeurs de Rust est le suivant :
Il vaut mieux rejeter un programme valide qu'accepter un programme potentiellement invalide.
Le unsafe permet au développeur d'indiquer au compilateur que, même si le compilateur ne sait pas le déterminer, le bloc de code est safe. C'est à utiliser avec parcimonie, mais le côté "non safe" (qui est plutôt "n'a pas réussi a déterminer la safety") ne fuit pas vers le reste du programme.
De plus, le hardware sur lequel tourne le code Rust (ton PC) est par nature "unsafe". Il y a donc naturellement des choses que l'on ne peut pas déterminer à l'avance comme étant "safe".
Au final, utiliser "unsafe" c'est déléguer à l'OS la garantie que l'opération est safe. Tout comme en Haskell on délèguerait la gestion d'une IO (impure) au runtime.
Plus j'en apprends sur ce langage, moins j'ai envie d'en faire
Et c'est dommage. Ce langage n'est pas parfait, loin de là. Beaucoup de fonctionnalités ne sont pas encore stabilisées (hello générateurs/code asynchrone/...). La syntaxe est dure à comprendre.
Mais plus j'apprend ce langage, plus mes hypothèses et opinions se cassent la figure, pour laisser place à la réalité.
Grâce à Rust, je me pose des questions sur mon code, mes données, que je ne me posais pas avant, et ce même dans d'autres langages.
Si j'ose dire, apprendre le Rust fait de moi un meilleur développeur C / C++.
[^] # Re: libretro core?
Posté par David Delassus (site web personnel) . En réponse au journal Écrire un jeu en Rust presque de zéro. Évalué à 7.
Bah non justement, en Rust les concepts ne sont pas masqués :
Box<T>Rc<T>Cow<T>Mutex<T>souvent avecArc<Mutex<T>>Sendet/ouSyncIl n'y a rien de plus explicite, ces informations apparaissent dans le système de type qui va permettre au compilateur de s'assurer que les règles qui gouvernent ces concepts sont bien respectées.
C'est subjectif. Je trouve aussi que la syntaxe est lourde, mais c'est pas plus moche que des templates C++ qu'on observe en masse dans les librairies "header only" (beurk).
Exagération obsolète.
C'est pas sous prétexte d'être plus safe. C'est sous prétexte de prendre aucune décision pour le développeur. On le laisse gérer lui même pour qu'il puisse faire des applications performantes, on le laisse choisir lui même les trade-offs.
Le Go est un langage safe aussi, mais les trade-offs ont été choisi par les développeurs du langage/compilateur. Et toi, pauvre petit développeur, tu dois faire avec.
Ca j'ai mis pas mal de temps à le comprendre. Mais en gros, le choix qui a été fait par les développeurs de Rust est le suivant :
Il vaut mieux rejeter un programme valide qu'accepter un programme potentiellement invalide.
Le
unsafepermet au développeur d'indiquer au compilateur que, même si le compilateur ne sait pas le déterminer, le bloc de code est safe. C'est à utiliser avec parcimonie, mais le côté "non safe" (qui est plutôt "n'a pas réussi a déterminer la safety") ne fuit pas vers le reste du programme.De plus, le hardware sur lequel tourne le code Rust (ton PC) est par nature "unsafe". Il y a donc naturellement des choses que l'on ne peut pas déterminer à l'avance comme étant "safe".
Au final, utiliser "unsafe" c'est déléguer à l'OS la garantie que l'opération est safe. Tout comme en Haskell on délèguerait la gestion d'une IO (impure) au runtime.
Et c'est dommage. Ce langage n'est pas parfait, loin de là. Beaucoup de fonctionnalités ne sont pas encore stabilisées (hello générateurs/code asynchrone/...). La syntaxe est dure à comprendre.
Mais plus j'apprend ce langage, plus mes hypothèses et opinions se cassent la figure, pour laisser place à la réalité.
Grâce à Rust, je me pose des questions sur mon code, mes données, que je ne me posais pas avant, et ce même dans d'autres langages.
Si j'ose dire, apprendre le Rust fait de moi un meilleur développeur C / C++.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg