5 ms·

Cool project! But there's an attitude attached which amuses me: > Toshi will always target stable Rust and will try our best to never make any use of unsafe R

• troutwine 8y ago
  There's an inside baseball discussion happening here with the larger Rust community that I think, maybe, you're missing. You are absolutely correct in saying that Go, Python et al offer memory safety in a way that low-level languages do not. These languages use techniques that incure some kind of runtime penalty. Erlang, for instance, copies memory like it's going out of style. Now, with Rust you get a similar kind of memory safety but, somewhat uniquely, without the same category of runtime penalty. There's still some, sometimes, and that's where the community discussion around 'unsafe' happens in Rust. So, you're writing in Rust and you'd like to write code which has the absolute most aggressive performance possible. In Rust parlance this _maybe_ means you need to do unsafe things: turn off bounds checks, fiddle with the raw memory of a structure, allow multiple threads to access the same memory without synchronization, interact with mutable globals and so on. That's great, but, you've potentially opened up your program to crashes or security issues. If you're a solo author that's a trade-off you can make based on your needs. Here's the rub: if you use similar techniques in a crate -- a shared library for all to use -- then you've opted everyone using your crate into the same trade-off, one which they might not have otherwise chosen for themselves. What the Toshi project is saying here is that it's design preference is to avoid opting into this trade-off, preserving all the guarantees that Rust can provide at _possibly_ the expense of absolute performance. There's a safety-focused subset of the Rust community that takes the presence of an 'unsafe' in a body of Rust code very seriously and this project is participating in that conversation.
  • bluejekyll 8y ago
    This is very well stated. I would clarify one thing in particular. I think, hard to speak for everyone, most people have settled on the idea that high-level libraries should avoid unsafe (like this one) and rely on libraries that need to work around safety restrictions. This allows the “unsafe” libraries to have fewer lines of code and more isolated testing, with greater coverage.
    • nickpsecurity 8y ago
      You can also, if they're written in C, verify the absence of everything you'd worry about using the automated and lightweight tooling available for C. Then, fuzz it to be sure. Then, port it back to equivalent rust maybe with C2Rust. Then, equivalence testing to make sure the two have same output. That's my current recommendation for medium-assurance apps in Rust that have to use unsafe code. Oh yeah, gotta turn overflow checks on in the safe Rust for best effect but might have performance hit. I'm still thinking about the rest of concurrency problems and side channels that Rust's type system doesn't cover. Trying to find out what's as easy as above. For concurrency, I'm eyeballing Eiffel's SCOOP, DTHREADS, and eventually will study whatever Pony is doing.
      • bluejekyll 8y ago
        > You can also, if they're written in C, verify the absence of everything you'd worry about using the automated and lightweight tooling available for C. Then, fuzz it to be sure. Then, port it back to equivalent rust maybe with C2Rust. Not sure I totally understand (or if I do, totally agree). For all FFI in Rust, we have to drop down to unsafe interfaces. I like the model that's generally happening in this area where there is an auto-generated sys crate (with bindgen), then an FFI crate that does all the Rust <-> C interop. This tends to work pretty well. A lot of C/C++ (native library) validation tools just work with Rust artifacts, so I don't personally see a lot of value for writing in C as well as Rust, unless we're talking about a rewrite from C to Rust. > still thinking about the rest of concurrency problems and side channels that Rust's type system doesn't cover. What things are you thinking about beyond the Send/Sync traits? I've found those to be very expressive, and appropriately restrictive.
• viraptor 8y ago
  > Go, Python, Java, C#, Erlang, JS, and a myriad of others But few of them has as strong guarantees about your safety as rust. Python, Erlang, JS will not enforce anything and raise recoverable errors on mismatch. Java and C# will enforce a bit of correctness and raise recoverable errors. Go is the most strict, but happy to panic at runtime if you cast to the wrong interface. And that's before we talk about things like defined integer overflow behaviour, safety without concurrent execution, etc. Those languages do protect from accidental memory overflows, but rust offers a lot more in safe code.
  • bluejekyll 8y ago
    Let’s not go too far, Rust has plenty of panics at runtime.
    • viraptor 8y ago
      Do you mean something that's not validated by the compiler, or explicit unwrap/panic calls?
      • bluejekyll 8y ago
        Explicit unwrap/panic calls, as well as some numerical operations (in debug mode) that will panic on overflow. Indexing into arrays/slices outside bounds will also panic. This was in response to the point that Go panics, and I didn't think it was perfectly fair to use that as an example (I have others that I would use) since Rust also panics in similar situations.
        • viraptor 8y ago
          Go does panic on a wrong interface cast, which doesn't have an equivalent in outside unsafe mode in rust, so I think it's a valid comparison. > as well as some numerical operations (in debug mode) that will panic on overflow That's a good thing. You normally want to find them in debug mode. > Indexing into arrays/slices outside bounds will also panic. Kind of. There's .get which returns an Option to do it safely, but you're right that basic indexing can fail.