Comment by rubiquity | Hacker News Reader

Comment by rubiquity | Hacker News Reader

Parent Full thread

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.

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.

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.

  > I'm a weekend wannabe systems programmer
  > and was attracted to Rust from Ruby because C scares me

I myself was attracted from Javascript for the same reason, you're among friends. :)

  > this is where Go users laugh that Rust attracted a 
  > Rubyist instead of a C++ user

I don't think anyone's laughing at anybody. Different languages will appeal to different people, we don't need to begrudge anyone for that!

  > I'll have to research C++ lambdas some more but given 
  > the safety, usability and performance gains

Performance of Rust closures should be the exact same as C++ lambdas. Safety-wise, you get all the usual guarantees of Rust. Usability-wise, the main nicety of Rust closures over C++ lambdas is that Rust doesn't force you to specify a capture clause, and instead infers how to capture all of the closed-over variables based on context. I think that Rust may actually be strictly less powerful than C++ here (as C++ allows you to explicitly specify the capture mode for each and every upvar if you like), but we believe that you'll have all the power you need in practice. Whether or not this turns out to be true will have to be determined by experience.

While it's less important in a language with immutability as default, closures, especially in dynamic longhops, can be a good way of shooting yourself in the foot (eg, capture inside a loop a variable defined outside of it but which is modified at each iteration and wonder why you always get the value set at the last iteration). Capture lists are not always evil.

> 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

TL;DR: People migrate from all kinds of places to all kinds of places. :)

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.

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.

It probably helps that Rust's type system is close to what ML-family languages have (the compiler itself was originally developed in OCaml)

Feels like we are all preparing for exciting adventure.

> I'm a weekend wannabe systems programmer (it's therapy after a long week of Web development)

I love the fact that systems programming is becoming attractive again!

> this is where Go users laugh that Rust attracted a Rubyist instead of a C++ user

The members of the Rust community have very diverse backgrounds, so don't feel bad. We have systems programmers, pure FP folks, game devs, folks from the dynamic/web crowd... this is an encouraging thing! You will not be alone in coming from a dynamic language - some of our best contributors are also experienced Python, Ruby or Racket developers.

> (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.

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.

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.

Reply on news.ycombinator.com