Sans détails plus que ça c'est difficile d'évaluer l'ampleur de ce drâme !
On va laisser les gens travailler, déterminer les bouts de code essentiels, voir si c'est une si grosse partie de code que ça. Linux à sa propre lib de base, j'imagine qu'il la font évoluer aussi parfois tout le monde s'en fout.
Les communautés Rust et Linux vont aussi probablement être à l'écoute l'une de l'autre, on verra comment ils gèrent ce genre de contraintes, version ement, norme ...
Comme le reste : le jeu en vaut-il la chandelle ? Quels sont les bénéfices, les problèmes (avérés) qui sont vraiment durs à résoudre en pratique, est-ce un vrai fardeau ou alors bof la vie normale de l'évolution d'un code de cette ampleur et pas tellement plus, les solutions trouvées ...
On peut causer dans le vague et un certain purisme de propriétés attribuées au C longtemps, il a toujours sa sémantique qui permet de faire relativement n'importe quoi facilement sans contrôle ni garantie dans la balance. Il y a probablement un prix à payer pour mettre ce genre de garanties dans Linux. Mais vu que les devs qu'on ne peut pas soupçonner d'incompetences reconnaissent que ça cause des bugs qui sont un fardeau à traiter, un peu tout le temps, la question n'est pas vraiment de savoir si le C a une API qui a t'elle propriété ...
C'est si le cout d'avoir ces garanties est si important que ça contrebalance les bénéfices, et si l'intégration est si compliquée que ça et si pénible à maintenir.
Oui il y aura des problèmes d'intégration logicielle, et des problèmes humains, surtout au début. Mais en vitesse de croisières, concrètement... Tu trouves du temps de debuggage contre quelques bonnes pratiques d'intégration et du versionnement des compilos Rust et un peu de dialogue entre les projets ? Linux n'est pas un programme si insignifiant que sa voie ne pèse pas dans la balance et que Rust leur dise "merde".
[^] # Re: .
Posté par thoasm . En réponse au journal Linus répond à la controverse sur R4L (Rust pour Linux). Évalué à 6.
Sans détails plus que ça c'est difficile d'évaluer l'ampleur de ce drâme !
On va laisser les gens travailler, déterminer les bouts de code essentiels, voir si c'est une si grosse partie de code que ça. Linux à sa propre lib de base, j'imagine qu'il la font évoluer aussi parfois tout le monde s'en fout.
Les communautés Rust et Linux vont aussi probablement être à l'écoute l'une de l'autre, on verra comment ils gèrent ce genre de contraintes, version ement, norme ...
Comme le reste : le jeu en vaut-il la chandelle ? Quels sont les bénéfices, les problèmes (avérés) qui sont vraiment durs à résoudre en pratique, est-ce un vrai fardeau ou alors bof la vie normale de l'évolution d'un code de cette ampleur et pas tellement plus, les solutions trouvées ...
On peut causer dans le vague et un certain purisme de propriétés attribuées au C longtemps, il a toujours sa sémantique qui permet de faire relativement n'importe quoi facilement sans contrôle ni garantie dans la balance. Il y a probablement un prix à payer pour mettre ce genre de garanties dans Linux. Mais vu que les devs qu'on ne peut pas soupçonner d'incompetences reconnaissent que ça cause des bugs qui sont un fardeau à traiter, un peu tout le temps, la question n'est pas vraiment de savoir si le C a une API qui a t'elle propriété ...
C'est si le cout d'avoir ces garanties est si important que ça contrebalance les bénéfices, et si l'intégration est si compliquée que ça et si pénible à maintenir.
Oui il y aura des problèmes d'intégration logicielle, et des problèmes humains, surtout au début. Mais en vitesse de croisières, concrètement... Tu trouves du temps de debuggage contre quelques bonnes pratiques d'intégration et du versionnement des compilos Rust et un peu de dialogue entre les projets ? Linux n'est pas un programme si insignifiant que sa voie ne pèse pas dans la balance et que Rust leur dise "merde".