Why Rust closures are somewhat hard
stevedonovan.github.io
Why Rust closures are somewhat hard
1–10 of 92 posts
Re: Why Rust closures are somewhat hard
#2Note that the workaround to force `change_x` out of scope in the section 'Implications of “Closures are Structs”' is no longer necessary with non-lexical lifetimes. So Rust closures are (somewhat) less hard now :)
Re: Why Rust closures are somewhat hard
#3The fact that you can even do stuff like this in Rust is amazing. It’s simultaneously: relatively clean code, very efficient and type-safe. I like it.
Re: Why Rust closures are somewhat hard
#4I feel most things in Rust are harder to do, at least at first sight. A compromise for the enhanced safeness I guess. Could give it a try again sometime.
Re: Why Rust closures are somewhat hard
#5I feel most things in Rust are harder to do, at least at first sight. A compromise for the enhanced safeness I guess. Could give it a try again sometime.
In general, it's not the safety alone, but the combination of safety and eschewing implicit runtime costs. It would be 100% safe for Rust to always implicitly box closures; it just wouldn't be as efficient in the cases where boxing them isn't needed.
Re: Why Rust closures are somewhat hard
#6The fact that you can even do stuff like this in Rust is amazing. It’s simultaneously: relatively clean code, very efficient and type-safe. I like it.
Not sure I agree with "relatively clean code" when one of the examples show "fn compose (f1: impl Fn(T)->T, f2: impl Fn(T)->T) -> impl Fn(T)->T {" which is just a mix-match of keywords and other things, with tons of syntax embedded in just one line.
But as always, depends on where you come from. I mostly deal with lisp languages nowadays, so guessing it's just my view that the line quoted above seems complex enough to not be interested one bit in Rust.
Re: Why Rust closures are somewhat hard
#7The fact that you can even do stuff like this in Rust is amazing. It’s simultaneously: relatively clean code, very efficient and type-safe. I like it.
Not sure I agree with "relatively clean code" when one of the examples show "fn compose (f1: impl Fn(T)->T, f2: impl Fn(T)->T) -> impl Fn(T)->T {" which is just a mix-match of keywords and other things, with tons of syntax embedded in just one line. But as always, depends on where you come from. I mostly deal with lisp languages nowadays, so guessing it's just my view that the line quoted above seems complex enough t…
While that may be an extreme example I agree. nothing clean about that code. I've only just begun to dive into rust, but I feel like I'd need a concordance to navigate the meaning of that snippet alone.
Bt then again, maybe it depends on where you come from.
Re: Why Rust closures are somewhat hard
#8I don't understand the intuition of closures and they turn me off to languages immediately. They feel like a hack from someone who didn't want to store a copy of a parent-scope variable within a function. The idea that I can touch variables that have gone out of scope (and that have ostensibly been GC'd) makes me feel that it is impossible to reason about variable lifetimes when dealing with closures. Is there some perspective I'm missing here? Is it literally just the language invisibly adding the parent-scope variables and their values to the top of my function?
Re: Why Rust closures are somewhat hard
#9I feel most things in Rust are harder to do, at least at first sight. A compromise for the enhanced safeness I guess. Could give it a try again sometime.
It seems to me that it's not that Rust is hard, it's that all programming is hard but Rust exposes the complexity so we can make a more informed decision about the trade offs of safety and performance etc, while other languages tend to hide the complexity (null reference, race conditions, etc).
Re: Why Rust closures are somewhat hard
#10I don't understand the intuition of closures and they turn me off to languages immediately. They feel like a hack from someone who didn't want to store a copy of a parent-scope variable within a function. The idea that I can touch variables that have gone out of scope (and that have ostensibly been GC'd) makes me feel that it is impossible to reason about variable lifetimes when dealing with closures. Is there some p…
There are indeed some nuances you are missing as well as at least one misconception you are holding:
> The idea that I can touch variables that have gone out of scope (and that have ostensibly been GC'd)
You can't touch variables that have been garbage collected, indeed. A variable captured in a closure will have a reference to it and therefore not be garbage collected until the closure itself goes out of scope and is garbage collected.
Closures allow encoding some state into a function, which is especially useful for higher order functions that return specialized functions, for example. This is, for example, how decorators in Python work - a function is captured in a closure, which is then referenced and called by a new function wrapping the original function.