Readit News logoReadit News
tatterdemalion commented on Announcing Rust 1.26.2   blog.rust-lang.org/2018/0... · Posted by u/philonoist
zxcvhjkl · 7 years ago
Look at the tokio chat example: https://github.com/tokio-rs/tokio-core/blob/master/examples/...

  let line = io::read_until(reader, b'\n', Vec::new());
  let line = line.and_then(|(reader, vec)| {
     if vec.len() == 0 {
       Err(Error::new(ErrorKind::BrokenPipe, "broken pipe"))
     } else {
       Ok((reader, vec))
     }
  });

  // Convert the bytes we read into a string, and then send   that
  // string to all other connected clients.
  let line = line.map(|(reader, vec)| {
    (reader, String::from_utf8(vec))
  });
  ...
With monads we end up with much boilerplate that has nothing to do with the actual "business" logic.

Maybe you prefer that, but I prefer the code to describe just the business logic.

tatterdemalion · 7 years ago
The same code with `await` :)

    let (reader, vec) = await { io.read_until(reader, b'\n', Vec::new() }?;
    if vec.len() == 0 {
        return Err(Error::new(ErrorKind::BrokenPipe, "broken pipe"));
    }
    let string = String::from_utf8(vec)?;

tatterdemalion commented on Announcing Rust 1.26.2   blog.rust-lang.org/2018/0... · Posted by u/philonoist
steveklabnik · 7 years ago
I don't read your parent as saying that async/await is bad compared to futures, but that futures code right now is tough to write. This is why so many people are psyched about async/await in Rust!

One area in which async/await significantly improves over manual futures is borrows between individual futures in the chain. In languages with a GC, this isn't an issue, but it comes up in Rust a bunch.

See this for a great explanation: http://aturon.github.io/2018/04/24/async-borrowing/

tatterdemalion · 7 years ago
The user specifically asked about stackfull coroutines, which is not the direction we're going. But I think the pain point the user talked about (futures right now are difficult to deal with) will be resolved by our stackless coroutine approach, and more in line with Rust's values around "zero cost abstractions."
tatterdemalion commented on Rust's 2018 roadmap   blog.rust-lang.org/2018/0... · Posted by u/steveklabnik
Ygg2 · 7 years ago
As far I understand the RFC won't allow for `Array[Y, N]` (or `Array<T, N>` in Rust parlance) note eddyb's comment:

     Note that all of this should allow impl<T, const N: usize> Trait for [T; N] {...}, 
     but not actually passing a constant expression to a type/function, e.g. ArrayVec<T, 3>.
What I'm actually looking is `Array<Y, size_of::<T>>` for support for data structures that vary depending on size of `T`.

tatterdemalion · 7 years ago
The RFC supports it, eddyb's list of milestones in the compiler just don't get you all the way there.
tatterdemalion commented on Signal Foundation   signal.org/blog/signal-fo... · Posted by u/conroy
faitswulff · 8 years ago
This is a bit of a tangent, but I first heard of Intel SGX (Secure Guard Extensions) via Signal's blog post about secure contact sharing[0], so it's almost relevant :p From what I've read[1][2][3], Intel SGX is vulnerable to Spectre exploits. Does anyone know if this has changed Signal's approach to security at all? Granted, contact sharing was a technology preview, but I'm curious if SGX is still considered a feasible, "good enough" security measure for Signal Foundation.

[0]: https://signal.org/blog/private-contact-discovery/

[1]: https://software.intel.com/en-us/forums/intel-software-guard...

[2]: https://github.com/lsds/spectre-attack-sgx

[3]: https://security.stackexchange.com/questions/176635/how-does...

tatterdemalion · 8 years ago
Signal's use of SGX was to increase users' trust in Signal - OpenWhisperSystems couldn't log your contacts even if they wanted to. Its up to potential users to decide if they think OpenWhisperSystems will surreptitiously perform an attack on their own secure enclave to secretly log your contact information.
tatterdemalion commented on Unsafe Zig Is Safer Than Unsafe Rust   andrewkelley.me/post/unsa... · Posted by u/jfo
klodolph · 8 years ago
> then at least one of those libraries has a bug

Yes, we agree about this point. However, the process for determining if these bugs exist is not well understood. That's what I mean when I say that this is not only a pedagogical problem--even Rust experts struggle to prove that a library containing "unsafe" blocks is safe, and more research into the area is needed.

tatterdemalion · 8 years ago
My apologies if I misunderstood you - I read your comment as suggesting that safe abstractions are "leaky" and therefore create additional responsibilities for users to validate that they are using them safely when composing them together. This is not the case unless those abstractions are incorrect - which is the same situation you are with any language, just most languages those abstractions exist within the language runtime & not in libraries.
tatterdemalion commented on Unsafe Zig Is Safer Than Unsafe Rust   andrewkelley.me/post/unsa... · Posted by u/jfo
klodolph · 8 years ago
> This comment suggests you don't have much domain knowledge about how `unsafe` in Rust works, so I'm surprised you speak with such confidence.

I hate being tone police, but jeez, we're having a discussion about Rust here and talking about my personal competency is inappropriate and unwelcome.

The problem I'm talking about happens when you write libraries that contain "unsafe" blocks. You want to prove (or at least assure yourself) that no unsafe behavior is observable by clients of the library. However, the way to do this is not entirely clear, although there is research being done in this area. One known trap is that it is not sufficient to demonstrate that Rust code without "unsafe" blocks cannot observe unsafe behavior in your library.

See: https://plv.mpi-sws.org/rustbelt/popl18/paper.pdf

These concerns are not hypothetical, there have been soundness problems in the Rust standard library before and I expect it to happen again.

tatterdemalion · 8 years ago
Proving the correctness of unsafe code is totally different from what you talked about, which was composing different abstractions with unsafe internals together.

Users of safe Rust do not need to worry about whether the composition of two safe interfaces that use unsafe internally is safe unless one of those interfaces is incorrect. Your comment would suggest that users need to think about the untyped invariants of each library they use, but this is not correct, libraries are not allowed to rely on untyped invariants for the correctness of their safe APIs.

tatterdemalion commented on Unsafe Zig Is Safer Than Unsafe Rust   andrewkelley.me/post/unsa... · Posted by u/jfo
madez · 8 years ago
Think of two libraries that use unsafe Rust and interact with the same hardware, but work correctly when used on their own.

A program written only in pure not-unsafe Rust might use these two libraries in a way that breaks because the assertions the programmers of the libaries had, like for example having exclusive access to the hardware, are wrong now.

One could argue the pure not-unsafe Rust program is wrong, not the libraries.

I think klodolph's comment is very thoughtful and shows a good deal of experience and domain knowledge.

tatterdemalion · 8 years ago
There is a conflation happening here. What is the nature of this bug when you compose these two libraries together?

If it is a violation of Rust's safety guarantees, then at least one of those libraries has a bug, it is exposes a safe abstraction which is not actually safe. One could not argue that the safe Rust program is wrong; the library exposing an unsafe interface as safe is unarguably wrong.

If the library just behaves incorrectly in a manner disconnected from the type system because some global state was changed in a way it doesn't expect ("the hardware" in this case), then that's a normal bug & it is not connected to unsafe code at all.

tatterdemalion commented on Unsafe Zig Is Safer Than Unsafe Rust   andrewkelley.me/post/unsa... · Posted by u/jfo
wickawic · 8 years ago
Correct me if I’m wrong but I thing GP was stating that composing two “unsafe” blocks together (both of which are manually verified to work well) might interfere with each other when run simultaneously.
tatterdemalion · 8 years ago
Its possible that I misread the comment; it seemed to state that this problem extended into safe Rust, which it definitely does not.
tatterdemalion commented on Unsafe Zig Is Safer Than Unsafe Rust   andrewkelley.me/post/unsa... · Posted by u/jfo
klodolph · 8 years ago
There's not only a pedagogical task here, but the Rust community must learn how to write code safely. The major difficulty here is that in general, unsafe pieces of code cannot be safely composed, even if the unsafe pieces of code are individually safe. This allows you to bypass runtime safety checks without unsafe code just by composing "safe" modules that internally use unsafe code in their implementation.

This kind of problem comes up a lot. Composed atomic operations are not atomic. Composed correct threaded code is not always correct. Mixing Scheme control structures made with call/cc don't work as desired. Enabling different Haskell language extensions gets you off the deep end quickly, and some unsafe combinations are surprising (see GeneralizedNewtypeDeriving, which is considered unsafe even though it used to be safe).

tatterdemalion · 8 years ago
> The major difficulty here is that in general, unsafe pieces of code cannot be safely composed, even if the unsafe pieces of code are individually safe. This allows you to bypass runtime safety checks without unsafe code just by composing "safe" modules that internally use unsafe code in their implementation.

This comment suggests you don't have much domain knowledge about how `unsafe` in Rust works, so I'm surprised you speak with such confidence. Your comment is flatly wrong: users using only safe code are not responsibility for guaranteeing the composed safety of the components they use (whether or not they are implemented with unsafe code).

Interfaces marked safe must uphold Rust's safety guarantees, or they are incorrect. They are just wrong if they have additional untyped invariants that need to be maintained to guarantee their safety; interfaces like this must be marked `unsafe`.

Because they cannot depend on untyped invariants, any correct implementation with a safe interface can be composed with any other. This ability to create safe abstractions over unsafe code which extend the reasoning ability of the type system is a fundamental value proposition of Rust.

tatterdemalion commented on Why is Rust difficult?   vorner.github.io/difficul... · Posted by u/chewbacha
sillysaurus3 · 8 years ago
(ง'̀-'́)ง

Static typing is useful in large codebases at big companies because it forces you to communicate your intentions clearly. It's also useful in large OSS projects because it allows your IDE to auto generate tooling and documentation. If someone is using TypeScript, it's far more likely the codebase will have clear, documented interfaces.

But TypeScript is optional. It doesn't hold you down and yell at you until you obey it. Even when you're using it, you can simply ignore the warnings/errors if you want to be naughty, and TypeScript will simply shrug and say "if you insist. You'll realize later I was right." But in the meantime your code actually runs.

In Rust, it's the opposite. You have to think about every single aspect of what you're doing. Making a cathedral out of toothpicks would also force you to plan your actions very carefully, but you wouldn't really say it's a feature per se. More like the tradeoffs of the medium.

tatterdemalion · 8 years ago
Rust is consciously designed for large code bases. shrug

u/tatterdemalion

KarmaCake day2029July 31, 2014
About
https://github.com/withoutboats
View Original