Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A guide to closures in Rust

hashrust.com

Post reply on HN
Print view View original

41–50 of 102 posts

Re: A guide to closures in Rust

#41

Post by dontlaugh »

bheadmaster wrote: post #37
dontlaugh wrote: post #20

Earlier quoted context omitted.

An Optional defaulting to None when created can still fail to compile if you don't check whether it's None when you use it. Same with a Result defaulting to an Error. The problem with nil for any pointer or interface is that you can compile code dereferencing it without first checking if it's nil.

> The problem with nil for any pointer or interface is that you can compile code dereferencing it without first checking if it's nil. Yes, Go doesn't stop you from making mistakes. I think we've already rehashed that a couple of times...

It does stop me from trying to treat a float as an int. It could have trivially also stopped me from many other mistakes.

Re: A guide to closures in Rust

#42

Post by skitter »

weinzierl wrote: post #10
gdcbe wrote: post #3

Earlier quoted context omitted.

It has a massive threshold for beginners for sure. Personally I have a background in C/C++ and moved towards C#, Go, JS etc. With an interest in many more, but the above were my main languages for a decennia. 9 years ago I picked up Go, and have used it the most as my main language since then. 7 Years ago I picked up Rust, but only since 6 months ago really intensive (including publishing the guide that came out of m…

"And sure, plenty of people will tell if you do it "right" you'll have no issues." My answer to that is always that if you are able to do it right in C or C++ (and maybe golang) you should not run into any issues with Rust. Especially you should not ever have to fight to borrow checker because it does the job you should be doing as a C/C++ programmer in your head anyway.

The borrow checker rejects many otherwise valid programs. So if you do your job in correctly in C/C++, the borrow checker might accept the Rust equivalent or it might not.

Re: A guide to closures in Rust

#43

Post by duped »

FridgeSeal wrote: post #27

> let add_closure = |a, b| a + b; let sixty_six = add_closure(42, 24); Woah woah, how did it not occur to me that I could just…construct a closure that directly in Rust? This feels like one of those “incredibly obvious and reasonable in hindsight” things. I don’t know why I was labouring under the assumption they could only be invoked in very special and specific places, but it’s good to know I was wrong.

If you want to do anything with the closure it gets a little tricker, for example if you did something naive like

    fn fn_that_takes_closure (f: fn (i32, 3i2) -> i32) { ... }

    let x = |a, b| a + b;
    fn_that_takes_closure(x);
That would not compile, because `x` does not have the type `fn (i32, i32) -> i32` (that's reserved for "normal" functions). Every closure in Rust has a unique anonymous type, which means if you want to do anything with them besides calling them, you need to understand `Fn`, `FnOnce`, and `FnMut` traits and/or `dyn` trait objects. To write that above you'd need to do something like this:

    fn fn_that_takes_closure (f: F)
    where
        F: Fn(i32, i32) -> i32

Re: A guide to closures in Rust

#44

Post by duped »

gdcbe wrote: post #3
bjarneh wrote: post #2

> I'll explain what the move keyword does later in the article. For now just trust me that it is needed for the code to compile. That does not take a lot of trust, after a few rounds with that compiler. At least error messages are good with the Rust compiler. I've got very limited experience with Rust, but it does seem like a language with a massive threshold for beginners.

It has a massive threshold for beginners for sure. Personally I have a background in C/C++ and moved towards C#, Go, JS etc. With an interest in many more, but the above were my main languages for a decennia. 9 years ago I picked up Go, and have used it the most as my main language since then. 7 Years ago I picked up Rust, but only since 6 months ago really intensive (including publishing the guide that came out of m…

> Compared to that, Go(lang) is super easy to get into. Ridiculously easy.

A couple weeks ago I tried to get started with Go and the hello world code example wouldn't work with `go run` with some obscure module error that's meaningless to a noob, but sure it's "ridiculously easy"

Re: A guide to closures in Rust

#45

Post by proto_lambda »

duped wrote: post #43
FridgeSeal wrote: post #27

> let add_closure = |a, b| a + b; let sixty_six = add_closure(42, 24); Woah woah, how did it not occur to me that I could just…construct a closure that directly in Rust? This feels like one of those “incredibly obvious and reasonable in hindsight” things. I don’t know why I was labouring under the assumption they could only be invoked in very special and specific places, but it’s good to know I was wrong.

If you want to do anything with the closure it gets a little tricker, for example if you did something naive like fn fn_that_takes_closure (f: fn (i32, 3i2) -> i32) { ... } let x = |a, b| a + b; fn_that_takes_closure(x); That would not compile, because `x` does not have the type `fn (i32, i32) -> i32` (that's reserved for "normal" functions). Every closure in Rust has a unique anonymous type, which means if you want…

> That would not compile

It does compile.

> because `x` does not have the type `fn (i32, i32) -> i32` (that's reserved for "normal" functions).

Closures can cast to function pointers just fine as long as they don't capture anything.

Re: A guide to closures in Rust

#46

Post by returningfory2 »

amelius wrote: post #23

There's a lot to be said in favor of Rust's approach to memory management but closures in Rust suck compared to garbage collected languages.

True, but isn't the complexity of Rust closures essential rather than accidental?

Fundamentally closures are easy in e.g. Go because you don't have to think about lifetimes, at all. As soon as you capture a variable, the GC guarantees it won't be dropped from underneath your feet. With non-GC'd languages that responsibility moves from the GC to the programmer. The trickyness of using closures in Rust seems largely to be the trickyness of managing the lifetimes of captured variables.

Re: A guide to closures in Rust

#47

Post by FpUser »

weinzierl wrote: post #10
gdcbe wrote: post #3

Earlier quoted context omitted.

It has a massive threshold for beginners for sure. Personally I have a background in C/C++ and moved towards C#, Go, JS etc. With an interest in many more, but the above were my main languages for a decennia. 9 years ago I picked up Go, and have used it the most as my main language since then. 7 Years ago I picked up Rust, but only since 6 months ago really intensive (including publishing the guide that came out of m…

"And sure, plenty of people will tell if you do it "right" you'll have no issues." My answer to that is always that if you are able to do it right in C or C++ (and maybe golang) you should not run into any issues with Rust. Especially you should not ever have to fight to borrow checker because it does the job you should be doing as a C/C++ programmer in your head anyway.

>"...it does the job you should be doing as a C/C++ programmer in your head anyway."

False. Too many false positives

Re: A guide to closures in Rust

#48

Post by DonaldPShimoda »

bjarneh wrote: post #2

> I'll explain what the move keyword does later in the article. For now just trust me that it is needed for the code to compile. That does not take a lot of trust, after a few rounds with that compiler. At least error messages are good with the Rust compiler. I've got very limited experience with Rust, but it does seem like a language with a massive threshold for beginners.

> it does seem like a language with a massive threshold for beginners.

Programming with manual memory management should be (comparatively) hard. It's not where beginners should start. C makes it far too easy to write code with objectively bad effects on the system, as evidenced by the countless vulnerabilities discovered in critical real-world systems over the last half-century.

> after a few rounds with that compiler.

I find this phrasing curious. Do you feel that you are fighting the compiler?

Re: A guide to closures in Rust

#49

Post by runevault »

This is the first time I've understood what the compiler is meaning with FnOnce (that it is moving the captured item back out of the closure, whether by Drop or other means). Glad I read the article now.

Re: A guide to closures in Rust

#50

Post by oleganza »

skitter wrote: post #42
weinzierl wrote: post #10

Earlier quoted context omitted.

"And sure, plenty of people will tell if you do it "right" you'll have no issues." My answer to that is always that if you are able to do it right in C or C++ (and maybe golang) you should not run into any issues with Rust. Especially you should not ever have to fight to borrow checker because it does the job you should be doing as a C/C++ programmer in your head anyway.

The borrow checker rejects many otherwise valid programs. So if you do your job in correctly in C/C++, the borrow checker might accept the Rust equivalent or it might not.

Maybe that was true in 2017, but today borrow checker and compiler in general has covered so much of the Rust design space that the "correct programs" it rejects are more like rejecting Duff's Device kind of code. You are more likely to find yourself implementing low-level data structure or device interface where you need raw pointers tightly localized in the unsafe{} scope.
Post reply on HN