At this time, it is a very limited, single-source language, while Linux runs on tons of hardware. Hence at this time, no chance for anything but a meaningless stunt. Rust is, at best, a nice tech-demo at the moment with a bunch of very vocal blinded cult-like followers that probably believe (mistakenly) that they will finally be able to write good code using it. The actual reality is that the language matters very little for that.
At this time, it is a very limited, single-source language, while Linux runs on tons of hardware.
Linux runs on many obscure platforms, but the vast majority of Linux devices run on only a few platforms. If Rust proves to work well in practice for kernel code, it will become the responsibility of the people who care about the obscure platforms to ensure that LLVM supports them or they'll be left behind. I'm not saying this is what will happen, but if Rust proves to be as effective as it has the potential to be, the kernel will undoubtedly choose to move forward at the expense of obscure platforms.
Hence at this time, no chance for anything but a meaningless stunt. Rust is, at best, a nice tech-demo at the moment with a bunch of very vocal blinded cult-like followers that probably believe (mistakenly) that they will finally be able to write good code using it. The actual reality is that the language matters very little for that.
The difference between you and me maybe that I have seen countless hypes of the type "Tool/language/approach XYZ will finally fix software errors!". None of them ever has panned out. Assembler code was not more error prone than C and C is not more error prone then Rust. The reason to use C and not assembler is portability and higher productivity. But in a kernel-setting, things end there. The amount of control C gives is _needed_.
Assembler code was not more error prone than C and C is not more error prone then Rust.
Do you have som proof for this? Because otherwise it sounds like nonsense. There is a class of wrong programs which are possible in assembler and are not possible in C (e.g. programs having all the type mishmash errors C compilers catches). That means a programmer can make more errors in assembler than in C. That almost definitely means there more errors in assembler than in C provided that the scope of implemented functionality is the same.
Relationship between Rust and C is analogous to the one between C a
Why do you assume more ways errors can be made results in more errors? There is no sane reason for that assumption. Coding is not a randomized process.
Rust would have to run anywhere Linux runs... (Score:3, Insightful)
At this time, it is a very limited, single-source language, while Linux runs on tons of hardware. Hence at this time, no chance for anything but a meaningless stunt. Rust is, at best, a nice tech-demo at the moment with a bunch of very vocal blinded cult-like followers that probably believe (mistakenly) that they will finally be able to write good code using it. The actual reality is that the language matters very little for that.
Re: (Score:3)
At this time, it is a very limited, single-source language, while Linux runs on tons of hardware.
Linux runs on many obscure platforms, but the vast majority of Linux devices run on only a few platforms. If Rust proves to work well in practice for kernel code, it will become the responsibility of the people who care about the obscure platforms to ensure that LLVM supports them or they'll be left behind. I'm not saying this is what will happen, but if Rust proves to be as effective as it has the potential to be, the kernel will undoubtedly choose to move forward at the expense of obscure platforms.
Hence at this time, no chance for anything but a meaningless stunt. Rust is, at best, a nice tech-demo at the moment with a bunch of very vocal blinded cult-like followers that probably believe (mistakenly) that they will finally be able to write good code using it. The actual reality is that the language matters very little for that.
You're
Re: (Score:2)
The difference between you and me maybe that I have seen countless hypes of the type "Tool/language/approach XYZ will finally fix software errors!". None of them ever has panned out. Assembler code was not more error prone than C and C is not more error prone then Rust. The reason to use C and not assembler is portability and higher productivity. But in a kernel-setting, things end there. The amount of control C gives is _needed_.
Re: (Score:2)
Assembler code was not more error prone than C and C is not more error prone then Rust.
Do you have som proof for this? Because otherwise it sounds like nonsense. There is a class of wrong programs which are possible in assembler and are not possible in C (e.g. programs having all the type mishmash errors C compilers catches). That means a programmer can make more errors in assembler than in C. That almost definitely means there more errors in assembler than in C provided that the scope of implemented functionality is the same.
Relationship between Rust and C is analogous to the one between C a
Re:Rust would have to run anywhere Linux runs... (Score:2)
Why do you assume more ways errors can be made results in more errors? There is no sane reason for that assumption. Coding is not a randomized process.