To the author of this blog post: please write the code examples as syntax-colored text,
and definitely not as images.
I'd love to copy the code and paste it into the Rust playground or godbolt,
so I can see exactly what the compiler does and how the code behaves.
I can't do that with screenshots of code.
You can on Apple’s OSs, and some googling suggests you can do it on windows too if you save the image and open in the image viewer. Therefore I’d be surprised if you couldn’t get it working on various linux distros too...
You have to understand how ridiculous this answer sounds.
This is a technical forum. There is an expectation of how things are shared. Images and relying on built in OCR is not anywhere in line with that expectation.
But the difference between a closure and a function pointer is essential complexity, not accidental complexity.
If a language were to provide only closures and not function pointers, it would not be low level enough to interface with C code and C ABI. That's definitely not what Rust needs.
Whether or not it's "essential" is kind of irrelevant for the ergonomics; Languages do exist that provide only closures. (And yes, the likes of Java do struggle a bit with function pointer ffi) Similarly, "we need this because low level" has never made C++ more tolerable.
The thing about rust is that it's complexity is self-contained and follows established rules. If one understands data ownership, one only needs to be told what a closure is for all these edge cases and problems to make sense.
Contrast the complexities of JavaScript, many of which still boil down to "Some doofus 30 years ago didn't do any homework and made bad design decisions for type coercion". Just "fuck you, go memorize these behaviours".
> Whether or not it's "essential" is kind of irrelevant for the ergonomics;
The thing about essential complexity is you always pay for it. Either during compile or execution. Java has concept of thread safe but doesn't track it via types. You still need to take it into account when working with it.
Really can’t see how it could be made simpler. Function pointer can’t be a closure because it means something different. You can pass pointers different functions without having multiple versions of the function you are calling. Closures have a unique type and they require you to use generics.
What? All of this stuff has been in the language since 2014 at least. If you want stack-allocated closures which can safely close over references, this is the machinery you need. Rust's implementation is the state of the art.
Would be interesting to see a comparison with GCC's C closures[1].
[1] https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
To the author of this blog post: please write the code examples as syntax-colored text, and definitely not as images. I'd love to copy the code and paste it into the Rust playground or godbolt, so I can see exactly what the compiler does and how the code behaves. I can't do that with screenshots of code.
You can on Apple’s OSs, and some googling suggests you can do it on windows too if you save the image and open in the image viewer. Therefore I’d be surprised if you couldn’t get it working on various linux distros too...
You have to understand how ridiculous this answer sounds.
This is a technical forum. There is an expectation of how things are shared. Images and relying on built in OCR is not anywhere in line with that expectation.
Still it would be nice if the author used the right format for the job.
[dead]
You'd never have written "behing" if your keyboard's firmware, all the drivers, OS and the GUI and input control were written in Rust!
[flagged]
But the difference between a closure and a function pointer is essential complexity, not accidental complexity.
If a language were to provide only closures and not function pointers, it would not be low level enough to interface with C code and C ABI. That's definitely not what Rust needs.
Whether or not it's "essential" is kind of irrelevant for the ergonomics; Languages do exist that provide only closures. (And yes, the likes of Java do struggle a bit with function pointer ffi) Similarly, "we need this because low level" has never made C++ more tolerable.
The thing about rust is that it's complexity is self-contained and follows established rules. If one understands data ownership, one only needs to be told what a closure is for all these edge cases and problems to make sense.
Contrast the complexities of JavaScript, many of which still boil down to "Some doofus 30 years ago didn't do any homework and made bad design decisions for type coercion". Just "fuck you, go memorize these behaviours".
> Whether or not it's "essential" is kind of irrelevant for the ergonomics;
The thing about essential complexity is you always pay for it. Either during compile or execution. Java has concept of thread safe but doesn't track it via types. You still need to take it into account when working with it.
Nah, lots of higher level languages interface with C.
by dynamically allocating FFI trampolines, which add their own performance and lifetime issues that would be unacceptable for Rust.
This has been in Rust since before the 1.0 release.
Also, you can’t converge to a diverging number, for Rust to get close to C++’s level of complexity, the C++ WG would have to stop with their garbage.
Really can’t see how it could be made simpler. Function pointer can’t be a closure because it means something different. You can pass pointers different functions without having multiple versions of the function you are calling. Closures have a unique type and they require you to use generics.
What? All of this stuff has been in the language since 2014 at least. If you want stack-allocated closures which can safely close over references, this is the machinery you need. Rust's implementation is the state of the art.