I think the issue with that would be increasingly working catch-up on newer developments of replaced functionalities.
If your end-goal is integration then it's better to integrate early rather than late.
Developing and maintaining an interface and abstraction and having to keep that up to date is one thing. But after replacing some modules and components, any developments on their originals raises the question of how does that apply to our Rust module? If it already were in the Kernel and had replaced that module or component, that effort would not arise.
You say it's "needless" complexity. But that's what's up for debate, and most people, including Linus seem to disagree with you.
It's not a matter of whether Rust is demonstrably superior and more secure, that it is seems to be the common understanding and agreement.
A new project matching reasonable Kernel feature-parity would be too much effort. It's unrealistic.
The value is in moving the Kernel itself into a safer space and tool-space.
The idea that a technically superior solution would naturally supplant an earlier one with a huge market penetration and stability is wishful thinking. We see it in many areas. Without significant issues people at large will stay with what they know and what is popular.
I mainly work with C#, where I use Visual Studio. I think I mainly changed bindings for expand selection, and go to definition, declaration, implementation (ALT+A/+S/+D). All other bindings work out for me.
Cursor and selection "jumping" with CTRL and SHIFT, and using multiple cursors is a regular occurrence for me. I largely keep using keyboard, but for navigating I do often switch to or combine it with mouse.
When it's not C#, it's often VS Code, or otherwise Notepad++ for non-IDE simple editing. For even simpler quick edits I also use Double Commanders integrated text editor.
I use TortoiseGit, and its diff editor. I sometimes make changes there too. I also occasionally use KDiff or Winmerge.
I think whether it's worth to learn a new one should be determined by 1. what are your pain points/shortcomings, 2. what are the promises or your hopes, and 3. testing it out.
If you explore a promise and quickly find it not useful to you, it may be easy and simple to dismiss a switch without investing more.
The bigger and more complex the project, the more important a mentor to onboard, collaborate, and gain experience.
The better the mentor, the more you can gain in terms of specific and broad knowledge, not only about the things at hand, but understanding of alternatives and concepts.
If I change a string to a raw string or an interpolated string, it is a semantic change on the entire string, even if it leads to consequential changes only on subsections of it. The next time or additional changes I make must take different semantics into account.
If the formatting configuration forces one specific style then that is the deliberate choice; to have that one.
If there is no uniform single string quoting it is useful to differentiate between them; for example if for normal strings ' is preferred while for specific cases where escaping characters like \n is required, " must be used.
"" to '' … There is nothing to highlight for SemanticDiff.
Really? I definitely want to see that. I want to be deliberate about my code. I am not only targeting compiled code. I am also targeting developers through maintainable code.
I'm surprised they did not list an alternative that would be my preference: Highlight the entire string. The f prefix changes the entire text value type. I would like the `f´ to be highlighted strongly, and string it changes the interpretation of weakly, and the placeholder variable more strongly again.
I think and assume they use enforced guidelines, custom types and tooling to make it workable. By that point C is no longer simple. You extended the language to make it safe, and ended up with the same complexity.
I'm very skeptical of sticking to "old and tested" without reasoning.
If you're talking about the implementation, if they're making changes it's no longer "well tested". If it's undocumented, it's not approachable. If you're talking about toolchain, if the old is unapproachable because of inherent toolchain barriers, and custom toolchain dialects, I think it's good to question.
There may also be something to say about them struggling to get new contributors and maintainers (from what I heard/read).
Swift Build is a high-level build system based on llbuild with great support for building Swift.
Sounds like this won't help C++ projects?
The requirements of sold developer license, physical mac hardware, and XCode make it hard to be interested or even feel it worthwhile unless you're already a mac user.
I think the issue with that would be increasingly working catch-up on newer developments of replaced functionalities.
If your end-goal is integration then it's better to integrate early rather than late.
Developing and maintaining an interface and abstraction and having to keep that up to date is one thing. But after replacing some modules and components, any developments on their originals raises the question of how does that apply to our Rust module? If it already were in the Kernel and had replaced that module or component, that effort would not arise.