5 ms·

I had to read this 2-3 times to figure out what was going on, but I'm still not entirely sure what lead to proposing this change. I guess I'll write what I got

I had to read this 2-3 times to figure out what was going on, but I'm still not entirely sure what lead to proposing this change. I guess I'll write what I got out of it and hope I'm crazy and get corrected. It seems to me that we're restricting what a closure can do when it executes based on the type of closure that it is. Is this in the name of safety? If so, that seems like a good idea given Rust's goals. Right now it feels like a ton of mental overhead but I'll try and play around with it and see if I have an "A-ha!" moment. Some of the blog post, mainly the part about using a wrapper function so the compiler can still inline monomorphized functions, makes me feel like this is a bit half-baked at the moment. I mean, the very nature of closures is that they give the programmer dynamic abilities. I really enjoy Rust and the reason I enjoy Rust is the combination of low-level programming and safety. Maybe experiments like this are what gives us that. I hope I'm just confused right now. edit: Oh, one benefit I see already is that since these are "unboxed" there won't be an allocation.

kibwen 12y ago
The implementation is definitely half-baked at the moment, but will be improving drastically over the next week or two. :) As for the wrapper function presented in the post, it's only to demonstrate that closures are implemented via traits and act just like any other trait in that they can be used to facilitate virtual dispatch (though IMO you shouldn't strive to use traits in this way if you can help it, given that Rust gives you many tools to help you prefer static dispatch). Watching closures evolve in Rust over the past few years has actually been really interesting. We had an implementation that was "good" a few years ago, but was ultimately fundamentally inferior to the approach taken by C++ lambdas. The period since has been a fascinating exploration of ways to make closures safe, usable, and potentially zero-overhead in a language without garbage collection. For all I know it may be unprecedented.
- rubiquity 12y ago
  Thank you for replying. I do not have any experience with C++ so that's why this could be so confusing to me. I'm a weekend wannabe systems programmer (it's therapy after a long week of Web development) and was attracted to Rust from Ruby because C scares me (this is where Go users laugh that Rust attracted a Rubyist instead of a C++ user). I'll have to research C++ lambdas some more but given the safety, usability and performance gains that you mention this new implementation of closures seems impressive.
  - steveklabnik 12y ago
    > Rust attracted a Rubyist instead of a C++ user I would say that such people may be broader than "Go users," but my "Rust for Rubyists" was one of the very first community tutorials for the language, and Cargo takes a lot of inspiration from Bundler, given that both were written by Yehuda. :) Rust actually has quite a few Ruby/Python people, for exactly what you say: > C scares me This is basically what wycats said about himself in his GoGaruCo talk about Rust: https://www.youtube.com/watch?v=ySW6Yk_DerY https://www.youtube.com/watch?v=ySW6Yk_DerY TL;DR: People migrate from all kinds of places to all kinds of places. :)
    - rubiquity 12y ago
      Hah :) I was mostly having fun with the "We created this language for X but actually Y and Z like it instead" aspects of Go and Rust. Thanks for Rust for Rubyists, I remember reading it a while back. I should also thank you for the official Rust docs, which are a lot more robust now.
  - Dewie 12y ago
    > (this is where Go users laugh that Rust attracted a Rubyist instead of a C++ user) That would be the pot calling the kettle black.
  - dragonwriter 12y ago
    C doesn't scare me, but having used both dynamic languages like Ruby/Python and static languages with type inferencing and reasonably robust type systems (e.g., ML-family languages, Haskell), I find C-like languages that require a lot of type ceremony despite having fairly anemic type systems (and this is even more true of the whole C++/C#/Java family of static OO languages) to be quite annoying -- I don't feel like the type system is working for me, but that I'm doing extra work to make things easier for the compiler -- while Rust seems to be in a fairly reasonable place for a statically-typed language.
    - TheRubyist 12y ago
      Feels like we are all preparing for exciting adventure.
keeperofdakeys 12y ago
The new proposal gives three different types of closures, either immutable, mutable, or call-once. For each type of closure, variables can be either borrowed by reference, or moved into the closure. This gives six types of possible closures with this proposal. Currently, only two out of those six are supported (The current ||, and proc). So this proposal means closures are more powerful, and that two different, inconsistent types of closures can be unified. While the internals are probably going to stay the same (the traits), syntax sugar is still very much being thought about.
- kibwen 12y ago
  Keep in mind that that we expect that the "six types of possible closures" can be almost completely inferred at the use site, so people making use of APIs that accept closures should be able to be blissfully unaware of this distinction. Library authors will need to keep in mind the distinction between the three different closure traits when writing function signatures, but this is no different from how every other borrowed and owned thing in Rust works.

kibwen 12y ago

The implementation is definitely half-baked at the moment, but will be improving drastically over the next week or two. :) As for the wrapper function presented in the post, it's only to demonstrate that closures are implemented via traits and act just like any other trait in that they can be used to facilitate virtual dispatch (though IMO you shouldn't strive to use traits in this way if you can help it, given that Rust gives you many tools to help you prefer static dispatch). Watching closures evolve in Rust over the past few years has actually been really interesting. We had an implementation that was "good" a few years ago, but was ultimately fundamentally inferior to the approach taken by C++ lambdas. The period since has been a fascinating exploration of ways to make closures safe, usable, and potentially zero-overhead in a language without garbage collection. For all I know it may be unprecedented.

rubiquity 12y ago
Thank you for replying. I do not have any experience with C++ so that's why this could be so confusing to me. I'm a weekend wannabe systems programmer (it's therapy after a long week of Web development) and was attracted to Rust from Ruby because C scares me (this is where Go users laugh that Rust attracted a Rubyist instead of a C++ user). I'll have to research C++ lambdas some more but given the safety, usability and performance gains that you mention this new implementation of closures seems impressive.
- steveklabnik 12y ago
  > Rust attracted a Rubyist instead of a C++ user I would say that such people may be broader than "Go users," but my "Rust for Rubyists" was one of the very first community tutorials for the language, and Cargo takes a lot of inspiration from Bundler, given that both were written by Yehuda. :) Rust actually has quite a few Ruby/Python people, for exactly what you say: > C scares me This is basically what wycats said about himself in his GoGaruCo talk about Rust: https://www.youtube.com/watch?v=ySW6Yk_DerY https://www.youtube.com/watch?v=ySW6Yk_DerY TL;DR: People migrate from all kinds of places to all kinds of places. :)
  - rubiquity 12y ago
    Hah :) I was mostly having fun with the "We created this language for X but actually Y and Z like it instead" aspects of Go and Rust. Thanks for Rust for Rubyists, I remember reading it a while back. I should also thank you for the official Rust docs, which are a lot more robust now.
- Dewie 12y ago
  > (this is where Go users laugh that Rust attracted a Rubyist instead of a C++ user) That would be the pot calling the kettle black.
- dragonwriter 12y ago
  C doesn't scare me, but having used both dynamic languages like Ruby/Python and static languages with type inferencing and reasonably robust type systems (e.g., ML-family languages, Haskell), I find C-like languages that require a lot of type ceremony despite having fairly anemic type systems (and this is even more true of the whole C++/C#/Java family of static OO languages) to be quite annoying -- I don't feel like the type system is working for me, but that I'm doing extra work to make things easier for the compiler -- while Rust seems to be in a fairly reasonable place for a statically-typed language.
  - TheRubyist 12y ago
    Feels like we are all preparing for exciting adventure.

keeperofdakeys 12y ago

The new proposal gives three different types of closures, either immutable, mutable, or call-once. For each type of closure, variables can be either borrowed by reference, or moved into the closure. This gives six types of possible closures with this proposal. Currently, only two out of those six are supported (The current ||, and proc). So this proposal means closures are more powerful, and that two different, inconsistent types of closures can be unified. While the internals are probably going to stay the same (the traits), syntax sugar is still very much being thought about.

kibwen 12y ago
Keep in mind that that we expect that the "six types of possible closures" can be almost completely inferred at the use site, so people making use of APIs that accept closures should be able to be blissfully unaware of this distinction. Library authors will need to keep in mind the distinction between the three different closure traits when writing function signatures, but this is no different from how every other borrowed and owned thing in Rust works.