4 ms·

FWIW, I'd bet almost anything that this problem isn't solvable in any general way without linear types, at which point I bet it would be a somewhat easy modific

by saurik 6y ago

FWIW, I'd bet almost anything that this problem isn't solvable in any general way without linear types, at which point I bet it would be a somewhat easy modification to what Rust has already implemented. (Most of my development for a long time now has been in C++ using co_await with I/O completion and essentially all of the issues I run into--including the things analogous to "async Drop", which I would argue is actually the same problem as being able to drop a task itself--are solvable using linear types, and any other solutions feel like they would be one-off hacks.) Now, the problem is that the Rust people seem to be against linear types (and no one else is even considering them), so I'm pretty much resigned that I'm going to have to develop my own language at some point (and see no reason to go too deep into Rust in the mean time) :/.

SkiFire13 6y ago
I'm not familiar with linear types but as far as I can see they're pretty much the same as rust's ownership rules. Is there something I'm missing?
- littlestymaar 6y ago
  Rust implements affine types, which means every object must be used at most once. You cannot use them twice, but you can discard them and not do anything with them. Linear types means exactly once. but I don't think you can easily move from affine types to linear types in the case of Rust, see leakpocalypse[1] [1]: https://cglab.ca/~abeinges/blah/everyone-poops/#leakpocalypse https://cglab.ca/~abeinges/blah/everyone-poops/#leakpocalyps...
reasonabl_human 6y ago
I did a double take seeing your username above this comment! Thank you for your contributions to the jailbreak community, it’s what got me started down the programming / tinkering path back in middle school and has significantly shaped the opportunities I have today. Can’t believe I’m at the point where I encountered you poking around the same threads on a forum... made my day! :)
steveklabnik 6y ago
> at which point I bet it would be a somewhat easy modification to what Rust has already implemented. You'd lose that bet: https://gankra.github.io/blah/linear-rust/ https://gankra.github.io/blah/linear-rust/
- saurik 6y ago
  This is an article about why linear types are hard to implement... and it doesn't even claim they can't be done; regardless, I have argued this at you before :(. https://news.ycombinator.com/item?id=23579426 https://news.ycombinator.com/item?id=23579426 I continue to believe that the strongest point in that article is actually the third footnote, which correctly admits that this is mostly about a lack of appreciation. > The Swift devs have basically the exact same argument for move-only code, and their implicit Copy bound. Hooray! My claim here is that, given linear types, it should be trivial to use async/await style coroutines for I/O continuation. You have given no evidence against this idea.
  - steveklabnik 6y ago
    Ah! I misunderstood you, sorry. I thought you were saying that linear types would be easy to implement. I wasn't trying to say anything about the stuff you'd do with them if you had them.
ragall 6y ago
ATS has linear types.
pcwalton 6y ago
> FWIW, I'd bet almost anything that this problem isn't solvable in any general way without linear types I think this part of your comment is absolutely right and it's fatal to the argument that Rust made the wrong decision about I/O models for Rust. Maybe in the context of some other language, Rust's decision was not the best one, but not for Rust, because Rust just doesn't have linear types.

by saurik 6y ago

SkiFire13 6y ago

I'm not familiar with linear types but as far as I can see they're pretty much the same as rust's ownership rules. Is there something I'm missing?

littlestymaar 6y ago
Rust implements affine types, which means every object must be used at most once. You cannot use them twice, but you can discard them and not do anything with them. Linear types means exactly once. but I don't think you can easily move from affine types to linear types in the case of Rust, see leakpocalypse[1] [1]: https://cglab.ca/~abeinges/blah/everyone-poops/#leakpocalypse https://cglab.ca/~abeinges/blah/everyone-poops/#leakpocalyps...

reasonabl_human 6y ago

I did a double take seeing your username above this comment! Thank you for your contributions to the jailbreak community, it’s what got me started down the programming / tinkering path back in middle school and has significantly shaped the opportunities I have today. Can’t believe I’m at the point where I encountered you poking around the same threads on a forum... made my day! :)

steveklabnik 6y ago

> at which point I bet it would be a somewhat easy modification to what Rust has already implemented. You'd lose that bet: https://gankra.github.io/blah/linear-rust/ https://gankra.github.io/blah/linear-rust/

saurik 6y ago
This is an article about why linear types are hard to implement... and it doesn't even claim they can't be done; regardless, I have argued this at you before :(. https://news.ycombinator.com/item?id=23579426 https://news.ycombinator.com/item?id=23579426 I continue to believe that the strongest point in that article is actually the third footnote, which correctly admits that this is mostly about a lack of appreciation. > The Swift devs have basically the exact same argument for move-only code, and their implicit Copy bound. Hooray! My claim here is that, given linear types, it should be trivial to use async/await style coroutines for I/O continuation. You have given no evidence against this idea.
- steveklabnik 6y ago
  Ah! I misunderstood you, sorry. I thought you were saying that linear types would be easy to implement. I wasn't trying to say anything about the stuff you'd do with them if you had them.

ragall 6y ago

ATS has linear types.

pcwalton 6y ago

> FWIW, I'd bet almost anything that this problem isn't solvable in any general way without linear types I think this part of your comment is absolutely right and it's fatal to the argument that Rust made the wrong decision about I/O models for Rust. Maybe in the context of some other language, Rust's decision was not the best one, but not for Rust, because Rust just doesn't have linear types.