5 ms·

> In rust there are two types of code. 'safe' and 'unsafe'. The above is only true if your entire code path contains only safe code. I think this is actually a

by wycats 12y ago

> In rust there are two types of code. 'safe' and 'unsafe'. The above is only true if your entire code path contains only safe code. I think this is actually a misconception. In every high-level language (Ruby, Python, etc.) there are APIs for interacting with low-level code. These APIs (C bindings and FFI) are unsafe, and are in the path of virtually all high-level code. It is the responsibility of somebody implementing a C binding for Ruby to ensure that the publicly exposed API is safe. If you use `nokogiri` in Ruby and get a segfault, that is a bug in nokogiri. It is not an indication that Ruby is unsafe. Similarly, the "safe" dialect of Rust is Rust. Rust provides a low-level binding to unsafe code via the unsafe dialect that is philosophically equivalent to the FFI API or C bindings in Ruby. If somebody uses the low-level binding and exposes a Rust library that segfaults, there is a bug in that binding, full stop. I think this is very important. If you use regular Rust code with the expectation that "anyone in your path may cause you to segfault", something has gone very, very awry in the ecosystem. This is not an expectation in other high-level languages when people write low-level libraries with unsafe code in them, and it should not be an expectation in Rust. > Rust uses 'drop flags', which are extra bytes at the end of struct instances in memroy, to track objects and keep meta information about them to determine if they should be dropped This is in the process of being eliminated (see https://github.com/rust-lang/rfcs/pull/320 https://github.com/rust-lang/rfcs/pull/320). I didn't mention it because it's runtime overhead that will not be present shortly, and certainly by the time 1.0 is reached later this year.

shadowmint 12y ago
> If you use `nokogiri` in Ruby and get a segfault, that is a bug in nokogiri. It is not an indication that Ruby is unsafe. Rust has a strict definition of safety; not all rust code for fills that guarantee. We're not talking fast and loose here. These are absolute definitions. You can write safe code that crashes in rust. That absolutely violates the safety guarantee whatever the reason for it. > This is in the process of being eliminated No it's not. Keep dynamic drop semantics, by having each function maintain a (potentially empty) set of auto-injected boolean flags for the drop obligations for the function that need to be tracked dynamically (which we will call "dynamic drop obligations"). What's happening is some of the run time overhead is being reduced.
- wycats 12y ago
  > You can write safe code that crashes in rust. That absolutely violates the safety guarantee whatever the reason for it. You can write Ruby code that calls into unsafe C code and SEGVs. This is a bug in the C code you called. It should have exposed a safe interface. You can write Rust code that calls into clearly delineated unsafe code and SEGVs. This is a bug in the unsafe code you called. It should have exposed a safe interface. Anything to the contrary is a misunderstanding of the purpose and role of unsafe code in Rust, and endangers the entire ecosystem, just as it would endanger the Ruby ecosystem if it were seen as normal for C extensions to SEGV the safe Ruby process.
  - nwmcsween 12y ago
    'Unsafe' is a bad term, effect is much better and it is most definitely a rust issue. If the language doesn't have a way of dealing with effects it won't be able to handle them. Rust is honestly a more safe c++ and in my opinion not an alternative for c.
    - wycats 12y ago
      I don't know what this means. I stand by my upstream comment.
      - TheHydroImpulse 12y ago
        Algebraic effects system.
  - shadowmint 12y ago
    I'm not arguing any of these points. I'm just saying there are these two misconceptions: - if you write safe rust code, your code can't segfault This isn't true if your code path contains any unsafe code. - Rust code can't segfault This isn't true at all. Sure, if it does segfault its a bug in the c code / unsafe code. You're absolutely correct. ...but bugs aren't deliberate. Obviously no one is going to deliberately expose a c api that has segfaults in it. The misconception is that if you're using rust you're safe from the bugs that other programmers may have made... which is not true. There's a trust chain involved; if you depend on a library you trust it's bug free and won't delete your harddisk and crash your program, but there's a difference between trusting a library is not malicious, and trusting a library is bug free. If you have to trust the library is bug free, you're really no better off than using C++ are you? ...but people keep saying that if you use rust then there are certain types of safety that are guaranteed by the language: http://doc.rust-lang.org/reference.html#behavior-considered-unsafe http://doc.rust-lang.org/reference.html#behavior-considered-..., regardless of programmer bugs. It's just not true. Once again, I'm not arguing that safety is good or bad or whatever. My assertion is very very specific: Rust code written 100% safely can crash if it has a dependency that uses unsafe code. The assertion that 100% safely written rust code with arbitrary dependencies can't crash is false.

by wycats 12y ago

shadowmint 12y ago

> If you use `nokogiri` in Ruby and get a segfault, that is a bug in nokogiri. It is not an indication that Ruby is unsafe. Rust has a strict definition of safety; not all rust code for fills that guarantee. We're not talking fast and loose here. These are absolute definitions. You can write safe code that crashes in rust. That absolutely violates the safety guarantee whatever the reason for it. > This is in the process of being eliminated No it's not. Keep dynamic drop semantics, by having each function maintain a (potentially empty) set of auto-injected boolean flags for the drop obligations for the function that need to be tracked dynamically (which we will call "dynamic drop obligations"). What's happening is some of the run time overhead is being reduced.

wycats 12y ago
> You can write safe code that crashes in rust. That absolutely violates the safety guarantee whatever the reason for it. You can write Ruby code that calls into unsafe C code and SEGVs. This is a bug in the C code you called. It should have exposed a safe interface. You can write Rust code that calls into clearly delineated unsafe code and SEGVs. This is a bug in the unsafe code you called. It should have exposed a safe interface. Anything to the contrary is a misunderstanding of the purpose and role of unsafe code in Rust, and endangers the entire ecosystem, just as it would endanger the Ruby ecosystem if it were seen as normal for C extensions to SEGV the safe Ruby process.
- nwmcsween 12y ago
  'Unsafe' is a bad term, effect is much better and it is most definitely a rust issue. If the language doesn't have a way of dealing with effects it won't be able to handle them. Rust is honestly a more safe c++ and in my opinion not an alternative for c.
  - wycats 12y ago
    I don't know what this means. I stand by my upstream comment.
    - TheHydroImpulse 12y ago
      Algebraic effects system.
- shadowmint 12y ago
  I'm not arguing any of these points. I'm just saying there are these two misconceptions: - if you write safe rust code, your code can't segfault This isn't true if your code path contains any unsafe code. - Rust code can't segfault This isn't true at all. Sure, if it does segfault its a bug in the c code / unsafe code. You're absolutely correct. ...but bugs aren't deliberate. Obviously no one is going to deliberately expose a c api that has segfaults in it. The misconception is that if you're using rust you're safe from the bugs that other programmers may have made... which is not true. There's a trust chain involved; if you depend on a library you trust it's bug free and won't delete your harddisk and crash your program, but there's a difference between trusting a library is not malicious, and trusting a library is bug free. If you have to trust the library is bug free, you're really no better off than using C++ are you? ...but people keep saying that if you use rust then there are certain types of safety that are guaranteed by the language: http://doc.rust-lang.org/reference.html#behavior-considered-unsafe http://doc.rust-lang.org/reference.html#behavior-considered-..., regardless of programmer bugs. It's just not true. Once again, I'm not arguing that safety is good or bad or whatever. My assertion is very very specific: Rust code written 100% safely can crash if it has a dependency that uses unsafe code. The assertion that 100% safely written rust code with arbitrary dependencies can't crash is false.