Am I misunderstanding? I thought there were existing bugs caused by unclear lifetimes, and adding a simple C wrapper would prevent those, and make Rust Interop easier at the same time? Which they eventually did, but it took one year?
Why does fixing bugs and making the API more solid = “refactor in more bugs”?
We have one side’s unilateral description of how they perceive the existing state of things and their changes. Folks are very likely to poorly characterize things in a way that would sound crazy to disagree. However the truth is usually somewhere in between.
I have had very very vocal user that decry very deliberate design that the wider user base wanted as a “bug”. If someone read their rant without the wider context one would think my team was unreasonable and producing bad software. Even after fellow users took time to explain why they wanted his request rejected, he was quite adamant that everyone else was wrong.
UB is only one class of error you can get in a big, complex program. Re-writing functionality opens the door to every other potential class of error too.
I liked the approach the kernel devs were taking where rust modules were being integrated without the ‘core’ code being touched. I think people who want a complete re-write of everything (if they exist outside of my convenient straw man) are probably better off starting a fresh kernel project.
Yes, you’re right, from my understanding nothing is in the kernel. Was more referring to the “re-write in rust!!” meme but admittedly that’s a strawman.
What time would SpaceNoodle allow? You’re in a thread about Kernel devs talking about contributing new code and why some new code is permissible, but other code, including C code, with fixes for C, are arbitrarily not allowed because it’s coming from a Rust dev.
With the “refactoring replaces old, working bugs, with new, untested bugs” mindset, you might as well stick with the good stuff from 50 years ago. Those bugs are very well-known.
The Linux kernel folks say that the rust folks missed the deadline for major code changes and the project is currently in minor bug fix mode prior to release. They weren’t prepared to accept thousands of lines of changes at this point on the grounds that introducing new regressions without time to fix them is a real risk. So timing is claimed to be an issue.
That’s an interesting perspective you got there. I hope you adopt the “ideological” mindset that adding fixes and memory safety is generally something you’d want, regardless of the language.
It says “When I tried to upstream minor fixes to the C code to make the behaviour more robust”. That doesn’t sound like a major changes to me and related to some bugs 🤷♂️
Am I misunderstanding? I thought there were existing bugs caused by unclear lifetimes, and adding a simple C wrapper would prevent those, and make Rust Interop easier at the same time? Which they eventually did, but it took one year?
Why does fixing bugs and making the API more solid = “refactor in more bugs”?
We have one side’s unilateral description of how they perceive the existing state of things and their changes. Folks are very likely to poorly characterize things in a way that would sound crazy to disagree. However the truth is usually somewhere in between.
I have had very very vocal user that decry very deliberate design that the wider user base wanted as a “bug”. If someone read their rant without the wider context one would think my team was unreasonable and producing bad software. Even after fellow users took time to explain why they wanted his request rejected, he was quite adamant that everyone else was wrong.
UB is only one class of error you can get in a big, complex program. Re-writing functionality opens the door to every other potential class of error too.
I liked the approach the kernel devs were taking where rust modules were being integrated without the ‘core’ code being touched. I think people who want a complete re-write of everything (if they exist outside of my convenient straw man) are probably better off starting a fresh kernel project.
Nothing is being rewritten in Rust.
Yes, you’re right, from my understanding nothing is in the kernel. Was more referring to the “re-write in rust!!” meme but admittedly that’s a strawman.
Because that’s the inevitability when major changes are introduced, especially when solely for purposes not directly related to bugfixes.
refactoring does fix bugs
Refactoring replaces old, working bugs with new, untested bugs.
Might as well never write new code then 🤷
Maybe pick a proper time and place, yeah?
What time would SpaceNoodle allow? You’re in a thread about Kernel devs talking about contributing new code and why some new code is permissible, but other code, including C code, with fixes for C, are arbitrarily not allowed because it’s coming from a Rust dev.
With the “refactoring replaces old, working bugs, with new, untested bugs” mindset, you might as well stick with the good stuff from 50 years ago. Those bugs are very well-known.
The Linux kernel folks say that the rust folks missed the deadline for major code changes and the project is currently in minor bug fix mode prior to release. They weren’t prepared to accept thousands of lines of changes at this point on the grounds that introducing new regressions without time to fix them is a real risk. So timing is claimed to be an issue.
Who said this, and where? Are you sure you’re not throwing together the bcachefs stuff with this Rust topic?
Interesting that you ignore how they were just going to change things for ideological purposes, which was my entire point.
That’s an interesting perspective you got there. I hope you adopt the “ideological” mindset that adding fixes and memory safety is generally something you’d want, regardless of the language.
It says “When I tried to upstream minor fixes to the C code to make the behaviour more robust”. That doesn’t sound like a major changes to me and related to some bugs 🤷♂️