In order not to pollute the technical conversation going on around Rust in the Case for Rust in Base thread, I'm starting this thread for broader, ignoramus discussion.
A few days ago the famous annual Linus Torvalds interview was released, and he said two things in seperate contexts but which, considered together, are quite interesting. I don't think it's some crypto-message, I just think it's two things that he probably doesn't consciously realize are related.
The first thing is that he is worried about what I may call "developer deflation," a general over all decrease in amount of trained programmers working professionally, and a specific decrease in those that do exist who have active interest in developing Linux. In this context, he mentioned that, being realistic, Linux will have to depend more and more on autogenerated code for long term maintenance and development.
The second thing he said was also in the context of "specific Linux developer deflation." It is that, even though Rust in the Linux kernel hasn't caught on like he had hoped, he still thinks it is important, for the simple reason that it may combat the deflation.
What I don't think he quite goes on to connect is that Rust will probably help solve long-term maintenance problems with Linux, not because Rust has somehow caught like wildfire among programmers, but because Rust is probably a far more autogenerated code-friendly language than C. Not only in real terms, but most likely in perceived terms of autogenerated software companies.
Of course, the whole idea of autogenerated software is that a coding language is not needed, binaries can be directly produced. But if the goal is to transition maintenance and development of software that is very large, complex and sprawling, and already has a codebase, and cannot be et wrested entirely from traditional human-to-code maintenance, then a stopgap at least is needed. How does a program reason about a kernel? How do you measure outcomes such that you can adjust the originating binary on the basis of it? Computer code at least presents an atomizable outcome that computers can measure.
The underlying thesis here is that the main selling point of Rust, memory management with low-level performance, is of debatable transcendence for human coders, but is game changing for an autogenerated program that will have a much easier time with specific limits than with indeterminate loose ends.
A few days ago the famous annual Linus Torvalds interview was released, and he said two things in seperate contexts but which, considered together, are quite interesting. I don't think it's some crypto-message, I just think it's two things that he probably doesn't consciously realize are related.
The first thing is that he is worried about what I may call "developer deflation," a general over all decrease in amount of trained programmers working professionally, and a specific decrease in those that do exist who have active interest in developing Linux. In this context, he mentioned that, being realistic, Linux will have to depend more and more on autogenerated code for long term maintenance and development.
The second thing he said was also in the context of "specific Linux developer deflation." It is that, even though Rust in the Linux kernel hasn't caught on like he had hoped, he still thinks it is important, for the simple reason that it may combat the deflation.
What I don't think he quite goes on to connect is that Rust will probably help solve long-term maintenance problems with Linux, not because Rust has somehow caught like wildfire among programmers, but because Rust is probably a far more autogenerated code-friendly language than C. Not only in real terms, but most likely in perceived terms of autogenerated software companies.
Of course, the whole idea of autogenerated software is that a coding language is not needed, binaries can be directly produced. But if the goal is to transition maintenance and development of software that is very large, complex and sprawling, and already has a codebase, and cannot be et wrested entirely from traditional human-to-code maintenance, then a stopgap at least is needed. How does a program reason about a kernel? How do you measure outcomes such that you can adjust the originating binary on the basis of it? Computer code at least presents an atomizable outcome that computers can measure.
The underlying thesis here is that the main selling point of Rust, memory management with low-level performance, is of debatable transcendence for human coders, but is game changing for an autogenerated program that will have a much easier time with specific limits than with indeterminate loose ends.
)
