3 ms·

I did not "ding" it, but asked for an honest, transparent response if available. It can only help the Rust community by making such things clear. I focused on i

I did not "ding" it, but asked for an honest, transparent response if available. It can only help the Rust community by making such things clear. I focused on it as it is what I got probing Rust since after all there can be "no free lunch". The compiler backend may be viewed as a smaller component that needs to be trusted. General code lies on top of it, and there is a big difference due to code volume.

pcwalton 11y ago
I don't understand what "there is a big difference due to code volume" means.
- gajjanag 11y ago
  I was referring to all usage of Rust by clients across the world versus a single compiler and reference standard library. Many of these clients will need "unsafe" blocks, and the combined length of these "unsafe" blocks will exceed that of the standard library and compiler assuming Rust adoption is high. This is what concerns me: I wished Rust's "unsafe" blocks could have been exclusively confined to some things in the reference language compiler and standard library. Unfortunately, it seems like many reasonable systems applications still need access to unsafe blocks for reasons of performance, low level access, etc and such needs are not uncommon given the target systems audience.
  - kibwen 11y ago
    > I wished Rust's "unsafe" blocks could have been > exclusively confined to some things in the reference > language compiler and standard library. This sadly isn't possible in a language at the systems level. If you don't provide an escape hatch then users will just use the C FFI as an escape hatch, which results in far more potential unsafety than Rust's `unsafe` blocks.
kibwen 11y ago
The quantity of unsafe code in the standard library represents far, far less code than that of the compiler. Furthermore, unsafe blocks don't turn off the type system or anything, they only let you do four extra specific actions (possibly only 3 someday). The correctness of the compiler can be leveraged to assist in determining the correctness of the standard library, and living in a typical library structure makes the code easier to understand and audit than if it were entangled up with compiler logic.

pcwalton 11y ago

I don't understand what "there is a big difference due to code volume" means.

gajjanag 11y ago
I was referring to all usage of Rust by clients across the world versus a single compiler and reference standard library. Many of these clients will need "unsafe" blocks, and the combined length of these "unsafe" blocks will exceed that of the standard library and compiler assuming Rust adoption is high. This is what concerns me: I wished Rust's "unsafe" blocks could have been exclusively confined to some things in the reference language compiler and standard library. Unfortunately, it seems like many reasonable systems applications still need access to unsafe blocks for reasons of performance, low level access, etc and such needs are not uncommon given the target systems audience.
- kibwen 11y ago
  > I wished Rust's "unsafe" blocks could have been > exclusively confined to some things in the reference > language compiler and standard library. This sadly isn't possible in a language at the systems level. If you don't provide an escape hatch then users will just use the C FFI as an escape hatch, which results in far more potential unsafety than Rust's `unsafe` blocks.

kibwen 11y ago

The quantity of unsafe code in the standard library represents far, far less code than that of the compiler. Furthermore, unsafe blocks don't turn off the type system or anything, they only let you do four extra specific actions (possibly only 3 someday). The correctness of the compiler can be leveraged to assist in determining the correctness of the standard library, and living in a typical library structure makes the code easier to understand and audit than if it were entangled up with compiler logic.