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

Rust 1.46

blog.rust-lang.org

Post reply on HN
Print view View original

61–70 of 157 posts

Re: Rust 1.46

#61

Post by estebank »

trumpeta wrote: post #58
thenewwazoo wrote: post #23

Earlier quoted context omitted.

I don't have time for an exhaustive answer, so I'll give you some rules of thumb when using Functional-style combinators: * If you need to keep unchanged the input, you must either use a reference-to (.iter()) or copy-of (.iter().cloned()) of each item * If you don't need the input ever again, you should move the items (.into_iter()) These rules follow for each step of the chain. I very very often write very Function…

I've been using .to_owned() liberally, that often does the trick in the first instance, albeit at the potential cost of a copy.

This is a perfectly reasonable solution. You might be leaving performance on the table but

1) if perfomance isn't a measurable problem for you, then there's on point on eking the last bit of performance from these allocations

2) it simplifies the code itself

3) sometimes clones are actually efficient, people forget to make their small ADTs Copy

4) if you're learning the language this lets you delay the moment when you have to fully understand the way lifetimes actually behave in complex cases, which means that when you do do that you will have a better grasp of the rest of the language and will be able to form a better mental model of how it fits with other features

Re: Rust 1.46

#62

Post by saagarjha »

zozbot234 wrote: post #48
sfvisser wrote: post #6

I’m learning rust right now and there is a lot to like. Steady updates like this are also very motivating. The ecosystem feels very sane - especially compared to npm. Top notch Wasm support, cross compiling is a breeze. That said, coming from a FP background (mostly Haskell/JS, now TS) Rust is... hard. I do understand the basic rules of the borrow checker, I do conceptually understand lifetimes, but actually using th…

> The ecosystem feels very sane [] compared to npm Now that's damning with faint praise.

Parts of Rust's ecosystem are just npm but with saner people using it at the moment.

Re: Rust 1.46

#63

Post by ragnese »

estebank wrote: post #59
ragnese wrote: post #15

Earlier quoted context omitted.

> Anyways, I guess this gets easier over time, right? Yes. > Should I avoid using closures all over the place? Not necessarily. > Should my code look more like C and less like Haskell? Yes. Others sometimes don't like to hear this, but IMO, Rust is not at all functional. Passing functions around is not ergonomic (how many function types does Rust have again? Three?). Even making heavy use of Traits, especially generi…

> how many function types does Rust have again? Three?). Depending on what you meant, there are more than three: * There are 3 traits, used by closures depending on their needs: * Fn(Args) -> Output * FnMut(Args) -> Output * FnOnce(Args) -> Output * *Every* `fn` is its own type (`fn() {foo}`) * Function pointers (`fn()`), which is how you pass the above around in practice > Rust is very much procedural. I think this…

I realized after I wrote the comment that I was really referring to the closure traits when I said that. And I really should have said "kind" instead of "type" because, like you said, every different function has its own type.

But anyway, I don't really disagree with your point about categorizing languages as OOP, Procedural, or Functional.

But honestly, in this case, I think it's pretty damn clear than Rust is procedural WAY more than it's either OOP or FP. (Note: By OOP, I mean Java-style with tall ownership hierarchies and object-managed mutable state, not necessarily caring about inheritance. And definitely not referring to Alan-Kay-Style-OOP a la Lisp and Smalltalk).

Scala can be looked at as FP and/or OOP. C++ can be looked at as Proc and/or OOP. Python, IIRC, can kind of do all of them, but I don't remember it being easy to make copies/clones in Python, so FP is questionable.

Have you ever tried to write two versions of a complex async function in Rust? One with async and one with Futures combinators? Due to ownership, the Futures combinators approach very quickly devolves into a nightmare. The language doesn't "want" you to do that.

What about function composition? Very awkward to do with matching up the different Fn traits.

And deeply nested object hierarchies are a no-go, too, because of the inability to do "partial borrows" of just a single field of a struct.

I mean, yes, it's not C because it has a real type system and generics. But... it's pretty much C in that you just write functions and procedures that operate on structs.

EDIT: Perhaps my "hardline" approach on calling Rust procedural is in response to people who have come to Rust from non-FP languages, see `map`, `filter`, and `Option` and start calling Rust functional. That's not functional programming! Ask someone who does OCaml to try out Rust and see if they call Rust functional afterwards.

Re: Rust 1.46

#64

Post by tgb »

eloff wrote: post #32
mijamo wrote: post #17

Earlier quoted context omitted.

Why not? By definition the output does not depend on runtime property so you should be able to compute it at compile time right?

Pure functions are functions where the return value only depends on the function arguments. If the function arguments are not known at compile time, obviously you can't evaluate it at compile time. It would only be possible to do that when all the arguments are also known at compile time (constants).

But a const fn can also do that: if given non-constant parameters it will be evaluated at run-time. So I (having never used Rust before) still haven't see the distinction between pure and const. What's an example of a function that is pure but cannot be evaluated at compile time with constant parameters?

Re: Rust 1.46

#65

Post by ragnese »

saagarjha wrote: post #62
zozbot234 wrote: post #48

Earlier quoted context omitted.

> The ecosystem feels very sane [] compared to npm Now that's damning with faint praise.

Parts of Rust's ecosystem are just npm but with saner people using it at the moment.

And it's probably going to be a pretty big issue in a few years, IMO.

Re: Rust 1.46

#67

Post by eloff »

tgb wrote: post #64
eloff wrote: post #32

Earlier quoted context omitted.

Pure functions are functions where the return value only depends on the function arguments. If the function arguments are not known at compile time, obviously you can't evaluate it at compile time. It would only be possible to do that when all the arguments are also known at compile time (constants).

But a const fn can also do that: if given non-constant parameters it will be evaluated at run-time. So I (having never used Rust before) still haven't see the distinction between pure and const. What's an example of a function that is pure but cannot be evaluated at compile time with constant parameters?

The parent didn't specify calling with constant parameters, which makes a huge difference. To answer your question, basically anything the compiler doesn't know how to evaluate - which has been expanded in this release, but does not include everything still.

Re: Rust 1.46

#68

Post by tick_tock_tick »

adsjhdashkj wrote: post #56
nemothekid wrote: post #35

Earlier quoted context omitted.

> the borrow checker, I do conceptually understand lifetimes, but actually using them is tricky. I've been using Rust for a little over year, almost daily at work, and for several projects. I have a pretty good intuition about how the borrow checker works and what needs to be done to appease it. That said, I don't think I'm any closer to understanding lifetimes. I know conceptually how they are supposed to work (I ne…

As someone in a similar description as you - i find my lifetime understanding... moderate. Complex lifetime usage still can tweak my brain - notably how i can design it. But simple lifetime usage is intuitive. A simple example i often run into is wanting to do something with a string, without taking owned parts of the string. Very intuitive how the str matches the lifetime of the owned value. On the otherhand, the ot…

These kind of optimization are incredibly painful in Rust one common suggestion is to sidestep the issue and store an offset + length in the nodes and then you take that to look up the value from the original string when you need the value.

Re: Rust 1.46

#69

Post by tgb »

eloff wrote: post #67
tgb wrote: post #64

Earlier quoted context omitted.

But a const fn can also do that: if given non-constant parameters it will be evaluated at run-time. So I (having never used Rust before) still haven't see the distinction between pure and const. What's an example of a function that is pure but cannot be evaluated at compile time with constant parameters?

The parent didn't specify calling with constant parameters, which makes a huge difference. To answer your question, basically anything the compiler doesn't know how to evaluate - which has been expanded in this release, but does not include everything still.

Looks like we have some terminology confusion. I read mijamo's question as being about the theoretical ability to evaluate at compile time (the value is knowable) not whether the compiler does do it, and that's what I meant in my comment too.

If you say that 'pure' functions are not compile-time-evaluatable because they may be given parameters that are not known at compile time, then you must also say that const fns are not compile-time-evaluatable. I think it's also clear that we mean for const fns to count, so the assumption that the parameters are known at compile time was implicit in the question.

Under those two assumptions: are pure functions evaluatable (in theory) at compile-time (on values known at compile time)? As far as I can think, the answer is yes? In which case, I'm not entirely sure what the distinction between 'pure' and 'cosnt fn' is supposed to be except to separate out the part of 'pure' functions that can are evaluated in practice. Is there anything more to it?

Re: Rust 1.46

#70

Post by jandrese »

kumarvvr wrote: post #19

So, I want to learn Rust. I am a C# / Python programmer, experienced. Are there any particular set of problems that I can solve systematically, so that I can learn all the features of Rust?

One thing I'd be wary of is Googling error messages and taking answers from Stack Exchange. Rust has mutated (heh) a fair bit over the years and many SE answers to noob problems are obsolete and sometimes incorrect. At the very least check the datestamp on any answer and be wary of anything more than a year or two old. This goes double if the answer has some extremely awkward looking syntax with lots of modifiers and underscores sprinkled throughout. There's probably a better way to do it now, or an alternative solution that works better. Or maybe you're just trying to do something that Rust makes hard, like concurrent processing on a shared data structure.

The manual is safer even though it's harder to find your exact problem and solution, especially when you're just starting out.

Post reply on HN