La différence est entre "on peut avoir des interfaces bien définies" dans un autre langage et Rust oblige à avoir des interfaces bien définies (par exemple pour indiquer qui est propriétaire de la mémoire et responsable de la libération, ou assurer la synchronisation entre threads). Oui bien sûr c'est contraignant et parfois ça empêche de faire des choses qui pourraient très bien |onctionner par ailleurs. De la même façon que le C n'a pas de coroutines (alors que c'est facile en assembleur) ou que le C++ ne permet pas de modifier la vtable d'un objet à la volée pendant l'exécution (alors que c'est tout à fait possible en smalltalk, ou si on implémente des vtables en C à la main). Ce sont bien évidement des choix pour contraindre les choses à fonctionner d'une certaine façon: une exécutioneavec une pile d'appel unique par thread, des possibilités d'optimisation des appels de méthodes, par exemple.
La qaestion oevient donc: en pratique, quelles sont les fonctions du noyau Linux qui ont une interface bien définie (en terme de gestion de la mémoire et des threads), mais une approche "inhabituelle" qui fait que ça ne peut pas s'interfacer avec du Rust?
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 6.
La différence est entre "on peut avoir des interfaces bien définies" dans un autre langage et Rust oblige à avoir des interfaces bien définies (par exemple pour indiquer qui est propriétaire de la mémoire et responsable de la libération, ou assurer la synchronisation entre threads). Oui bien sûr c'est contraignant et parfois ça empêche de faire des choses qui pourraient très bien |onctionner par ailleurs. De la même façon que le C n'a pas de coroutines (alors que c'est facile en assembleur) ou que le C++ ne permet pas de modifier la vtable d'un objet à la volée pendant l'exécution (alors que c'est tout à fait possible en smalltalk, ou si on implémente des vtables en C à la main). Ce sont bien évidement des choix pour contraindre les choses à fonctionner d'une certaine façon: une exécutioneavec une pile d'appel unique par thread, des possibilités d'optimisation des appels de méthodes, par exemple.
La qaestion oevient donc: en pratique, quelles sont les fonctions du noyau Linux qui ont une interface bien définie (en terme de gestion de la mémoire et des threads), mais une approche "inhabituelle" qui fait que ça ne peut pas s'interfacer avec du Rust?