6 ms·

These features are slow to be accepted for good reasons, not just out of some sort of pique. For example, the design space around combining `if let` pattern mat

These features are slow to be accepted for good reasons, not just out of some sort of pique. For example, the design space around combining `if let` pattern matching with boolean expressions has a lot of fraught issues around the scoping of the bindings declared in the pattern. This becomes especially complex when you consider the `||` operator. The obvious examples you want to use work fine, but the feature needs to be designed in such a way that the language remains internally consistent and works in all edge cases. > Pin didn't take much work to implement in the standard library. But its not a "lean" feature. It takes a massive cognitive burden to use - to say nothing of how complex code that uses it becomes. I'd rather clean, simple, easy to read rust code and a complex borrow checker than a simple compiler and a horrible language. Your commentary on Pin in this post is even more sophomoric than the rest of it and mostly either wrong or off the point. I find this quite frustrating, especially since I wrote detailed posts explaining Pin and its development just a few months ago. https://without.boats/blog/pin/ https://without.boats/blog/pin/ https://without.boats/blog/pinned-places/ https://without.boats/blog/pinned-places/

adwn 2y ago
> Your commentary on Pin in this post is even more sophomoric than the rest of it and mostly either wrong or off the point. I find this quite frustrating, especially since I wrote detailed posts explaining Pin and its development just a few months ago. To me, this sounds as if the Pin concept is so difficult to understand that it's hard to even formulate correct criticism about it. I get that Pin serves a critical need related to generators and async, and in that it was a stroke of genius. But you as the creator of Pin might not be the right person to judge how difficult Pin is for the more average developers among us.
- withoutboats3 2y ago
  If you actually read my posts you would see that I acknowledge and analyze the difficulty with using Pin and propose a solution which makes it much easier to deal with. My understanding is that the Rust project is now pursuing a solution along the lines of what I suggested in these posts.
senorrib 2y ago
I think you just proved his point on how hard it is to understand and correctly use Pin.
- withoutboats3 2y ago
  I agree with that assessment of Pin. That's why the second post I linked to presents a set of features that would make it as easy to use as mutability (pinning is really the dual of immutability: an immutable place cannot be assigned into, whereas a pinned place cannot be moved out of).
- oneshtein 2y ago
  Pinned is life time, similar to 'static, but written as Pin!() for an unknown reason.
adastra22 2y ago
A properly designed feature shouldn’t require an entire blog post, let alone multiple, to understand.
- withoutboats3 2y ago
  [flagged]
- dartos 2y ago
  So… all programming languages are not properly designed? People usually need to study for months to be able to use their first one. Sometimes you need knowledge to understand things.
- cogman10 2y ago
  I disagree. Some features are more complex than others and design has little to do with that complexity. Async is a good example of a complex feature that needs a fairly detailed blog post to understand the nuances. Pretty much any language with coroutines of some sort will have 1 or many blog posts going into great detail explaining exactly how those things work. Similarly, assuming Rust added HKT, that would also require a series of blog posts to explain as the concept itself is foreign to most programmers.
  - adastra22 2y ago
    Languages using pure versions of the pi calculus support concurrency without any of the usual headaches. Async is a great example of this problem. It is way more cumbersome in Rust then it could be, in a different universe where Rust concurrency made different choices.
    - cogman10 2y ago
      > A properly designed feature shouldn’t require an entire blog post, let alone multiple, to understand. After reading though the wiki about pi calculus and looking up the few languages that support it, I would be pretty shocked to find a language that adds a pi calculus feature wouldn't need several blog posts explaining what it is and how to understand it.
josephg 2y ago
> The obvious examples you want to use work fine, but the feature needs to be designed in such a way that the language remains internally consistent and works in all edge cases. True. How long should that process take? A month? A year? Two years? I ask because this feature has been talked about since I started using rust - which (I just checked) was at the start of 2017. Thats nearly 8 years ago now. 6 years ago this RFC was written: https://rust-lang.github.io/rfcs/2497-if-let-chains.html https://rust-lang.github.io/rfcs/2497-if-let-chains.html - which fixes my issues. But it still hasn't shipped. Do I have too high expectations? Is 6 years too quick? Maybe, a decade is a reasonable amount of time to spend, to really talk through the options? Apparently 433 people contributed to Rust 1.81. Is that not enough people? Do we need more people, maybe? Would that help? Yes, I do feel piqued by the glacial progress. I don't care about the || operator here - since I don't have any instinct for what that should do. And complex match expressions are already covered by match, anyway. Rust doesn't do the obvious thing, in an obvious, common situation. If you ask me, this isn't the kind of problem that should take over 6 years to solve. > Your commentary on Pin in this post is even more sophomoric than the rest of it and mostly either wrong or off the point. I find this quite frustrating, especially since I wrote detailed posts explaining Pin and its development just a few months ago. If I'm totally off base, I'd appreciate more details and less personal insults. I've certainly given Pin an honest go. I've used Pin. I've read the documentation, gotten confused and read everything again. I've struggled to write code using it, given up, then come back to it and ultimately overcame my struggles. I've boxed so many things. So many things. The thing I've struggled with the most was writing a custom async stream wrapper around a value that changes over time. I used tokio's RwLock and broadcast channel to publish changes. My Future needed a self-referential type (because I need to hold a RwLockGuard across an async boundary). So I couldn't just write a simple, custom struct. But I also couldn't use an async function, because I needed to implement the stream trait. As far as I can tell, the only way to make that code work was to glue async fn and Futures together in a weird frankenstruct. (Is this a common pattern? For all the essays about Pin and Future out there, I haven't heard anyone talk about this.) I got the idea from how tokio implements their own stream adaptor for broadcast streams[1]. And with that, I got this hairy piece of code working. But who knows? I've written hundreds of lines of code on top of Pin. Not thousands. Maybe I still don't truly get it. I've read plenty of blog posts, with all sorts of ideas about Pin being about a place, or about a value, or a life philosophy. But - yes, I haven't yet, also read the 9000 words of essay you linked. Maybe if I do so I'll finally, finally be enlightened. But I doubt it. I think Pin is hard. If it was simple, you wouldn't have written 9000 words talking about it. As you say: > Unfortunately, [pin] has also been one of the least accessible and most misunderstood elements of async Rust. Pin foists all its complexity onto the programmer. And for that reason, I think its a bad design. Maybe it was the best option at the time. But if we're still talking about it years later - if its still confusing people so long after its introduction - then its a bad part of the language. I also suspect there are way simpler designs which could solve the problems that pin solves. Maybe I'm an idiot, and I'm not the guy who'll figure those designs out. But in that case, I'd really like to inspire smarter people than me to think about it. There's gotta be a simpler approach. It would be incredibly sad if people are still struggling with Pin long after I'm dead. [1] https://github.com/tokio-rs/tokio/blob/master/tokio-stream/src/wrappers/broadcast.rs https://github.com/tokio-rs/tokio/blob/master/tokio-stream/s...
wokwokwok 2y ago
> The obvious examples you want to use work fine, but the feature needs to be designed in such a way that the language remains internally consistent and works in all edge cases. ?? Then why did the language team put it on the 2024 roadmap? Am I looking at something different? (Specifically on under the 'Express yourself more easily' (1) goal, which links to the RFC issue (2)). It certainly looks like the implementation is both complete and unblocked, and actively used. It looks more like the issue is (despite being put on the roadmap and broadly approved as a feature), being argued about because of the alternative proposal for 'is' syntax. ie. If you want to generalize then yes, there are features which are difficult to implement (yeah, I'll just make a Move trait... yeah... No. It's not that easy). BUT. That's not a problem. A lot of clever folk can work through issues like that and find solutions for that kind of problem. The real problem is that RCFs like this end up in the nebulous 'maybe maybe' bin, where they're implemented, have people who want them, have people who use them, have, broadly the approval of the lang team (It's on the roadmap). ...but then, they sit there. For months. Or years. While people argue about it. It's kind of shit. If you're not going to do it, make the call, close the RFC. Say "we're not doing this". Bin the code. Or... merge it into stable. Someone has to make the call on stuff like this, and it's not happening. This seems to happen to a fair few RFCs to a greater or less extent, but this one is particularly egregious in my opinion. [1] - https://lang-team.rust-lang.org/roadmaps/roadmap-2024.html#the-plan-so-far https://lang-team.rust-lang.org/roadmaps/roadmap-2024.html#t... [2] - https://github.com/rust-lang/rust/issues/53667 https://github.com/rust-lang/rust/issues/53667
criticalfault 2y ago
Given that your proposal is backwards compatible, what is preventing it from moving to standard language faster? Especially if it improves the situation drastically. Also, why would pinned be a syntactic sugar for Pin and not the other way around?

adwn 2y ago

> Your commentary on Pin in this post is even more sophomoric than the rest of it and mostly either wrong or off the point. I find this quite frustrating, especially since I wrote detailed posts explaining Pin and its development just a few months ago. To me, this sounds as if the Pin concept is so difficult to understand that it's hard to even formulate correct criticism about it. I get that Pin serves a critical need related to generators and async, and in that it was a stroke of genius. But you as the creator of Pin might not be the right person to judge how difficult Pin is for the more average developers among us.

withoutboats3 2y ago
If you actually read my posts you would see that I acknowledge and analyze the difficulty with using Pin and propose a solution which makes it much easier to deal with. My understanding is that the Rust project is now pursuing a solution along the lines of what I suggested in these posts.

senorrib 2y ago

I think you just proved his point on how hard it is to understand and correctly use Pin.

withoutboats3 2y ago
I agree with that assessment of Pin. That's why the second post I linked to presents a set of features that would make it as easy to use as mutability (pinning is really the dual of immutability: an immutable place cannot be assigned into, whereas a pinned place cannot be moved out of).
oneshtein 2y ago
Pinned is life time, similar to 'static, but written as Pin!() for an unknown reason.

adastra22 2y ago

A properly designed feature shouldn’t require an entire blog post, let alone multiple, to understand.

withoutboats3 2y ago
[flagged]
dartos 2y ago
So… all programming languages are not properly designed? People usually need to study for months to be able to use their first one. Sometimes you need knowledge to understand things.
cogman10 2y ago
I disagree. Some features are more complex than others and design has little to do with that complexity. Async is a good example of a complex feature that needs a fairly detailed blog post to understand the nuances. Pretty much any language with coroutines of some sort will have 1 or many blog posts going into great detail explaining exactly how those things work. Similarly, assuming Rust added HKT, that would also require a series of blog posts to explain as the concept itself is foreign to most programmers.
- adastra22 2y ago
  Languages using pure versions of the pi calculus support concurrency without any of the usual headaches. Async is a great example of this problem. It is way more cumbersome in Rust then it could be, in a different universe where Rust concurrency made different choices.
  - cogman10 2y ago
    > A properly designed feature shouldn’t require an entire blog post, let alone multiple, to understand. After reading though the wiki about pi calculus and looking up the few languages that support it, I would be pretty shocked to find a language that adds a pi calculus feature wouldn't need several blog posts explaining what it is and how to understand it.

josephg 2y ago

> The obvious examples you want to use work fine, but the feature needs to be designed in such a way that the language remains internally consistent and works in all edge cases. True. How long should that process take? A month? A year? Two years? I ask because this feature has been talked about since I started using rust - which (I just checked) was at the start of 2017. Thats nearly 8 years ago now. 6 years ago this RFC was written: https://rust-lang.github.io/rfcs/2497-if-let-chains.html https://rust-lang.github.io/rfcs/2497-if-let-chains.html - which fixes my issues. But it still hasn't shipped. Do I have too high expectations? Is 6 years too quick? Maybe, a decade is a reasonable amount of time to spend, to really talk through the options? Apparently 433 people contributed to Rust 1.81. Is that not enough people? Do we need more people, maybe? Would that help? Yes, I do feel piqued by the glacial progress. I don't care about the || operator here - since I don't have any instinct for what that should do. And complex match expressions are already covered by match, anyway. Rust doesn't do the obvious thing, in an obvious, common situation. If you ask me, this isn't the kind of problem that should take over 6 years to solve. > Your commentary on Pin in this post is even more sophomoric than the rest of it and mostly either wrong or off the point. I find this quite frustrating, especially since I wrote detailed posts explaining Pin and its development just a few months ago. If I'm totally off base, I'd appreciate more details and less personal insults. I've certainly given Pin an honest go. I've used Pin. I've read the documentation, gotten confused and read everything again. I've struggled to write code using it, given up, then come back to it and ultimately overcame my struggles. I've boxed so many things. So many things. The thing I've struggled with the most was writing a custom async stream wrapper around a value that changes over time. I used tokio's RwLock and broadcast channel to publish changes. My Future needed a self-referential type (because I need to hold a RwLockGuard across an async boundary). So I couldn't just write a simple, custom struct. But I also couldn't use an async function, because I needed to implement the stream trait. As far as I can tell, the only way to make that code work was to glue async fn and Futures together in a weird frankenstruct. (Is this a common pattern? For all the essays about Pin and Future out there, I haven't heard anyone talk about this.) I got the idea from how tokio implements their own stream adaptor for broadcast streams[1]. And with that, I got this hairy piece of code working. But who knows? I've written hundreds of lines of code on top of Pin. Not thousands. Maybe I still don't truly get it. I've read plenty of blog posts, with all sorts of ideas about Pin being about a place, or about a value, or a life philosophy. But - yes, I haven't yet, also read the 9000 words of essay you linked. Maybe if I do so I'll finally, finally be enlightened. But I doubt it. I think Pin is hard. If it was simple, you wouldn't have written 9000 words talking about it. As you say: > Unfortunately, [pin] has also been one of the least accessible and most misunderstood elements of async Rust. Pin foists all its complexity onto the programmer. And for that reason, I think its a bad design. Maybe it was the best option at the time. But if we're still talking about it years later - if its still confusing people so long after its introduction - then its a bad part of the language. I also suspect there are way simpler designs which could solve the problems that pin solves. Maybe I'm an idiot, and I'm not the guy who'll figure those designs out. But in that case, I'd really like to inspire smarter people than me to think about it. There's gotta be a simpler approach. It would be incredibly sad if people are still struggling with Pin long after I'm dead. [1] https://github.com/tokio-rs/tokio/blob/master/tokio-stream/src/wrappers/broadcast.rs https://github.com/tokio-rs/tokio/blob/master/tokio-stream/s...

wokwokwok 2y ago

> The obvious examples you want to use work fine, but the feature needs to be designed in such a way that the language remains internally consistent and works in all edge cases. ?? Then why did the language team put it on the 2024 roadmap? Am I looking at something different? (Specifically on under the 'Express yourself more easily' (1) goal, which links to the RFC issue (2)). It certainly looks like the implementation is both complete and unblocked, and actively used. It looks more like the issue is (despite being put on the roadmap and broadly approved as a feature), being argued about because of the alternative proposal for 'is' syntax. ie. If you want to generalize then yes, there are features which are difficult to implement (yeah, I'll just make a Move trait... yeah... No. It's not that easy). BUT. That's not a problem. A lot of clever folk can work through issues like that and find solutions for that kind of problem. The real problem is that RCFs like this end up in the nebulous 'maybe maybe' bin, where they're implemented, have people who want them, have people who use them, have, broadly the approval of the lang team (It's on the roadmap). ...but then, they sit there. For months. Or years. While people argue about it. It's kind of shit. If you're not going to do it, make the call, close the RFC. Say "we're not doing this". Bin the code. Or... merge it into stable. Someone has to make the call on stuff like this, and it's not happening. This seems to happen to a fair few RFCs to a greater or less extent, but this one is particularly egregious in my opinion. [1] - https://lang-team.rust-lang.org/roadmaps/roadmap-2024.html#the-plan-so-far https://lang-team.rust-lang.org/roadmaps/roadmap-2024.html#t... [2] - https://github.com/rust-lang/rust/issues/53667 https://github.com/rust-lang/rust/issues/53667

criticalfault 2y ago

Given that your proposal is backwards compatible, what is preventing it from moving to standard language faster? Especially if it improves the situation drastically. Also, why would pinned be a syntactic sugar for Pin and not the other way around?