C'est intéressant: c'est un langage qui s'intéresse à la sureté mémoire spatiale, là où le borrow-checker s'intéresse à la sureté mémoire temporelle. (voir cet article sur les différences entre les deux)

C'est intéressant, parce que la sureté mémoire spatiale a longtemps été considéré comme un problème moins gênant que la sureté temporelle, parce qu'on pouvait faire des vérifications à l'exécution pour pas cher, là où pour l'aspect temporel le coût en performance (garbage collector) était prohibitif pour plein d'applications.

Mais quand le “borrow-checker” de Rust est arrivé, on s'est rendu compte qu'on pouvait avoir la sureté temporelle sans impact sur les perfs, alors que la sureté spatiale impliquait un (léger mais substantiel) coût à l'exécution.

Content de voir qu'il existe une lib pour faire ça !

I have no idea what the complexities and caveates of doing this would be, but it could also be interesting to have the crate publishing step do aggressive borrow checking logic for every supported platform but then disable the borrow checker on crates downloaded from crates.io. The borrow checker contributes a lot of time to the compilation process, and if you gate acceptance to crates.io on the borrow checker passing then you can get away without needing to run the extra borrow checker logic when compiling dependencies.

Ça c'est vraiment pas très malin, pour plein de raison: déjà parce que le borrow-checker ne prend pas tant de temps que ça, ensuite parce qu'il arrive après les phases cfg resolution (quelque soit son nom réel) de “macro expansion”, donc ce n'est pas vraiment possible en pratique, ou plutot ça revient au même que de stocker des versions pré-compilées des dépendances sur crates.io.

Ce qui devait arriver arriva. J'aimerai beaucoup que cargo soit sandboxé par défaut …

Le plus triste dans cette histoire c'est que des gens vont se mettre à verrouiller leur dépendance à serde sur une version en particulier, ce qui va conduire à une montagne de problème (bien plus grands que le problème initial, qu'il s'agisse du temps de compilation ou du fait d'avoir une dépendance sous forme de binaire).

La vraie solution serait d'avoir cargo qui supporte nativement ce genre de chose (idéalement via webassembly comme dtolnay l'avait proposé il y a plusieurs années)