Blocks with return values are super useful too!
A guide to closures in Rust
91–100 of 102 posts
Re: A guide to closures in Rust
#92Re: A guide to closures in Rust
#93Earlier quoted context omitted.
> Functions do not capture environments. They might not do that in Rust, they do in Haskell, JavaScript and plenty of others.
No, they do not. This is the technical distinction that I'm trying to get at. A "function", in the academic literature, is a form that has two parts: a set of variables that it binds (called the parameters ) and a bit of encapsulated functionality (called the body ). The function itself has no knowledge of the outside world. This is why the notion of free variables is important, or even relevant. A free variable is a…
Haskell and JavaScript and the majority of humans call these things functions. That there exist a different context (a very specific academic context) where these terms have a slightly different technical meaning is completely irrelevant in the context of a normal user-level discussion on about programming languages.
Re: A guide to closures in Rust
#94Earlier 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.
> 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 adds mental overhead. I don't even like the "const" qualifier for functions in C++. It is so hard to get a design right upfront when thinking about non trivial 'const'-chains.
"It adds mental overhead."
To me `const` removes mental overhead -- if I pass a const object somewhere, I can be sure it doesn't get changed. I don't need to inspect the code to make sure it doesn't call any methods that modify the object or trust a probably outdated comment or documentation.
Re: A guide to closures in Rust
#95Earlier quoted context omitted.
> You have to allocate a closure That's incorrect, a closure in Rust compiles down to a static function that takes its environment as an argument. None of that requires a heap allocation in the above code.
Stack allocation is still allocation.
Literally no considers that to be the case? Like I have never met anyone who would consider declaring an integer variable "allocation"
Re: A guide to closures in Rust
#96There'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.
That's because Rust wants you to use the stack almost exclusively for memory allocation because that's the obvious way to do automatic memory management w/o a GC. So the moment you want to return closures you have to allocate them on the heap (Box them). Rust is a modern, functional programming language where the programmer works in a straightjacket, and this is most painfully evident the moment you want to use closu…
Think it's pretty dubious to call Rust a functional language at all: most Rust is written in an almost imperative style, but with some extra immutability sprinkled in when easy.
Coming from a functional background, when I first started programming Rust I really tried to leverage FP concepts as much as possible. However, I slowly began to realize that the FP version of the code I wanted to write was more complicated, more lines of code, and slower than the naive imperative version.
Clean FP without GC seems really difficult, and I think Rust team did as good a job as they could given the current state of research.
Re: A guide to closures in Rust
#97Earlier quoted context omitted.
> 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 adds mental overhead. I don't even like the "const" qualifier for functions in C++. It is so hard to get a design right upfront when thinking about non trivial 'const'-chains.
"It adds mental overhead." To me `const` removes mental overhead -- if I pass a const object somewhere, I can be sure it doesn't get changed. I don't need to inspect the code to make sure it doesn't call any methods that modify the object or trust a probably outdated comment or documentation.
When you are using the function, ye. Not when you are writing it. And if you someday want to change a const method to non-const you could have a cascading constness change all over the place.
Re: A guide to closures in Rust
#98Earlier quoted context omitted.
Stack allocation is still allocation.
Literally no considers that to be the case? Like I have never met anyone who would consider declaring an integer variable "allocation"
Write a compiler sometime; it'll be more obvious why the term of art is "stack allocation" instead of something that doesn't include the word "allocation." You'll understand why C's "alloca" function and C#'s "stackalloc" keyword are named like that. Stack overflows will make more sense--obviously you can't allocate forever, because you are indeed allocating memory.
As a parting gift, I'll give you one guess what the title of the Wikipedia article on thread stacks is.
Re: A guide to closures in Rust
#99Earlier quoted context omitted.
That's because Rust wants you to use the stack almost exclusively for memory allocation because that's the obvious way to do automatic memory management w/o a GC. So the moment you want to return closures you have to allocate them on the heap (Box them). Rust is a modern, functional programming language where the programmer works in a straightjacket, and this is most painfully evident the moment you want to use closu…
Think it's pretty dubious to call Rust a functional language at all: most Rust is written in an almost imperative style, but with some extra immutability sprinkled in when easy. Coming from a functional background, when I first started programming Rust I really tried to leverage FP concepts as much as possible. However, I slowly began to realize that the FP version of the code I wanted to write was more complicated,…
That sounds right to me, yeah.
Re: A guide to closures in Rust
#100Earlier quoted context omitted.
No, they do not. This is the technical distinction that I'm trying to get at. A "function", in the academic literature, is a form that has two parts: a set of variables that it binds (called the parameters ) and a bit of encapsulated functionality (called the body ). The function itself has no knowledge of the outside world. This is why the notion of free variables is important, or even relevant. A free variable is a…
Haskell and JavaScript and the majority of humans call these things functions. That there exist a different context (a very specific academic context) where these terms have a slightly different technical meaning is completely irrelevant in the context of a normal user-level discussion on about programming languages.
I want to point out that I started the discussion by explicitly admitting up front that my point was pedantic in nature. It should have come as no surprise, then, that the point was... pedantic in nature.
The reason I feel this stuff is important to mention is because it is not uncommon to find discussions where the conflation does cause people headaches. The problem is exacerbated by the prevalence of people who claim that the difference is "irrelevant", up until the point that the difference actually matters, at which point those people are simply not around. There are a ton of small sets of terms of this nature that, when speaking to laypeople, you would think are just synonyms, except that it turns out that sometimes the technical distinction is important. It means people who actively seek out spaces to educate those who want to learn (like myself) have to do extra work to undo the faulty learning and then start over with correct definitions. Like you said: for most people it's not a big enough deal to worry about, but the distinction is present and there are times when it does matter.
I like informing people of things, and I happen to find interest in minute details, definitions of terms, and so on. I know that's not for everyone. To solve this "problem" (if I can call it that), I try to start my discussions by being honest about my intentions: I explicitly state that the point is minor or pedantic or something to that effect. That way I get to write about the things I want to write about while also giving people plenty of room to just choose not to worry about it if they don't care, and everybody comes out the other side happy. Except you, I guess. Sorry about that.