4 ms·

Walter's point is by even C's own standards, the behavior of automatically having an array be treated as a pointer when it is passed to a function is unexpected

Walter's point is by even C's own standards, the behavior of automatically having an array be treated as a pointer when it is passed to a function is unexpected and a mistake. Given he authored the D programming language, he is absolutely aware of the benefits of managing memory allocation, runtime checks for boundary overruns, etc etc... It turns out when developing a kernel extremely fine, granular control, over memory is very important. And there are a lot of complexities that fall between the cracks of various architectures where a compiler and language having an extremely long track-record of behavior is helpful. The Linux Kernel folks have even gone as far as restricting the use of VLAs that were introduced in C99 due to unexpected side-effects and complexities that came from it: https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kills-The-VLA https://www.phoronix.com/scan.php?page=news_item&px=Linux-Ki... I'm definitely interested in RUST, but it seems like everything is viewed through a RUST looking glass these days, and all answers and roads lead to RUST.

avianes 5y ago
> Given he authored the D programming language, he is absolutely aware of the benefits of managing memory allocation, runtime checks for boundary overruns, etc etc... No doubt about that, but the proposal still does not address these issues while claiming it's an easy fix. > It turns out when developing a kernel extremely fine, granular control, over memory is very important. And there are a lot of complexities that fall between the cracks of various architectures where a compiler and language having an extremely long track-record of behavior is helpful I do not mean that the fine-grained control over memory is useless for developing a entire kernel, I mean that a large part of a kernel is made of logic that does not need this fine-grained control. My point is that using unsafe fine-grained control over memory everywhere is risky, while we could keep fine-grained control over memory languages only where it's required. > but it seems like everything is viewed through a RUST looking glass these days, and all answers and roads lead to RUST. True, it's worth noting that Rust is not mature yet and is not easy to use
- thedracle 5y ago
  I'm excited by the Kernel maintainer's openness to include Rust, especially for driver work. But I think it's a long-road ahead until it is generally adopted. My team in the past (which developed security device drivers), ended up splitting a lot of our observability logic into EBPF, which is basically using a verifiable memory-safe subset of C, which was pretty incredible.

avianes 5y ago

> Given he authored the D programming language, he is absolutely aware of the benefits of managing memory allocation, runtime checks for boundary overruns, etc etc... No doubt about that, but the proposal still does not address these issues while claiming it's an easy fix. > It turns out when developing a kernel extremely fine, granular control, over memory is very important. And there are a lot of complexities that fall between the cracks of various architectures where a compiler and language having an extremely long track-record of behavior is helpful I do not mean that the fine-grained control over memory is useless for developing a entire kernel, I mean that a large part of a kernel is made of logic that does not need this fine-grained control. My point is that using unsafe fine-grained control over memory everywhere is risky, while we could keep fine-grained control over memory languages only where it's required. > but it seems like everything is viewed through a RUST looking glass these days, and all answers and roads lead to RUST. True, it's worth noting that Rust is not mature yet and is not easy to use

thedracle 5y ago
I'm excited by the Kernel maintainer's openness to include Rust, especially for driver work. But I think it's a long-road ahead until it is generally adopted. My team in the past (which developed security device drivers), ended up splitting a lot of our observability logic into EBPF, which is basically using a verifiable memory-safe subset of C, which was pretty incredible.