Re: Petite question à ceux qui "baignent" encore dans le C

Il y a quand même un petit avantage a avoir une lib qui fait beaucoup plutot que plusieurs petites libs qui font des petites choses : la confiance. Il est plus facile de faire confiance à une lib qui est maintenu par une équipe identifiée, même si cette lib fait plein de choses, que de faire confiance à un tas de petites libs éparpillées non ?

Entièrement d'accord avec ça.
Ce que je voulais dire, c'est que les avantages des petites libs, n'ont pas d'avantages pour se défendre des supply chain attaques. (en tout cas dans leur état actuel sur cargo)

C'est là ou moi (et d'autres) ne sommes pas d'accord. Dans l'absolu Rust n'est pas plus vulnérables au supply chain attack que n'importe quelle autre langage. LA différence avec C c'est que Rust est plus ancien, et qu'on a pas encore un ecosysteme de libs matures permettant de faire aussi bien que C en terme d'attaque par supply chain. C'est de mon point de vue la seule différence aujourd'hui (mais je peux me tromper).

Je suis d'accord, je parle de l'écosystème actuel de Rust, en soie le langage, n'est pas vraiment coupable, cargo peu être plus.

Cargo ne pousse absolument pas à se défendre contre les supply chaines attaques, rajouter des dépendances sur cargo, c'est magique, et c'est tellement magique, que si l'on rajoute une dépendance, qui a en dépendances une lib que l'on a déjà, mais a une version différente, tout va marcher, sans rien dire, on aura la lib présente deux fois.

suro-rs c'était poser la question du nombre de dépendances et ont essayé de réduire ce qui n'était pas nécessaire, par contre, ça a été un gros travaille de leur côté et Cargo ne pousse pas à le faire par défaut.

Ce défaut est particulièrement questionnable, car même si ce n'est pas fait volontairement, make C pousse à être conservateur sur ces dépendances, il le fait du fait que make est un outil pourrit pour les gérer.

Une manière de voir Rust, et son système de borrow, pourraient être de voir Rust comme un outil pourrit pour manipuler ces pointers, qui met des bâtons dans les roues des Dev quand ils veulent faire de la manipulation de pointeur.

Toute l'idée de Rust est d'avoir un comportement par défaut qui pousse le dev à se questionner sur ce qu'il fait de sa mémoire, et ne pas chercher à toujours dire "ok ça va marcher".
Pour cargo, c'est l'exact opposé, on cherche à avoir un outil qui dit juste "oui" au dev.
Make bizarrement lui quand tu rajoutes une dépendance, tu forces à te poser la question du besoin de cette dépendance. Même si contrairement à Rust, c'est un effet de bord de son manque de fonctionnalités.