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

101–110 of 157 posts

Re: Rust 1.46

#101

Post by edflsafoiewq »

noctune wrote: post #93
ragnese wrote: post #63

Earlier quoted context omitted.

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 proc…

>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'm not totally sure if this is what you mean, but FYI you can borrow multiple fields mutably using destructuring: struct Foo(u8, u8); fn main() { let mut bar = Foo(1, 2); let Foo(ref mut x, ref mut y) = &mut bar; *x += 1; *y -= 1; println!("{} {}", bar.x, bar.y); }

Just let x = &mut bar.0 will work, but this "intelligence" is confined to the body of a single function. Rust possesses the somewhat curious property that there are functions that are intended to always be called like this

  foo(&bar.x, &bar.y, &bar.z)
which cannot be refactored to

  foo(&bar)

Re: Rust 1.46

#102

Post by steveklabnik »

edflsafoiewq wrote: post #101
noctune wrote: post #93

Earlier quoted context omitted.

>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'm not totally sure if this is what you mean, but FYI you can borrow multiple fields mutably using destructuring: struct Foo(u8, u8); fn main() { let mut bar = Foo(1, 2); let Foo(ref mut x, ref mut y) = &mut bar; *x += 1; *y -= 1; println!("{} {}", bar.x, bar.y); }

Just let x = &mut bar.0 will work, but this "intelligence" is confined to the body of a single function. Rust possesses the somewhat curious property that there are functions that are intended to always be called like this foo(&bar.x, &bar.y, &bar.z) which cannot be refactored to foo(&bar)

This is a complex topic, but what it boils down to is that the function signature is the API. If you borrow the whole thing, you borrow the whole thing, not disjoint parts of it.

This is also why it's okay in the body of a single function; that doesn't impact a boundary.

We'll see what happens in the future.

Re: Rust 1.46

#103

Post by ragnese »

noctune wrote: post #93
ragnese wrote: post #63

Earlier quoted context omitted.

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 proc…

>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'm not totally sure if this is what you mean, but FYI you can borrow multiple fields mutably using destructuring: struct Foo(u8, u8); fn main() { let mut bar = Foo(1, 2); let Foo(ref mut x, ref mut y) = &mut bar; *x += 1; *y -= 1; println!("{} {}", bar.x, bar.y); }

The problem comes when someone else needs to also borrow the Foo, even immutably. In Java-style OOP, you typically have "objects" that own other objects, all the way down. And you manage state internally.

So it often comes up that you might call several methods in a given scope. If even one of those mutably borrows one field of one sub-object, then you can't have any other borrows of that object anywhere else in that scope.

Newbies from other languages trip on that often enough that I used to see questions about it in r/rust fairly frequently.

Re: Rust 1.46

#104

Post by brundolf »

steveklabnik wrote: post #100
brundolf wrote: post #98

Earlier quoted context omitted.

Once you've learned the basics (plenty of links in the siblings, including the official Rust Book), this is a key (and entertaining!) unofficial resource that really hammered home for me the ways that Rust is different from the C family when it comes to working with references: https://rust-unofficial.github.io/too-many-lists/ It also taught me about Boxes and Rc's, which are essential for certain kinds of things, an…

https://doc.rust-lang.org/stable/book/ch15-01-box.html https://doc.rust-lang.org/stable/book/ch15-04-rc.html

Yeah, I figured they were probably in there somewhere. It's possible I read the book before they were added, or that I skipped them (I glossed over some of the final chapters), or it's possible I just didn't fully grasp how important they were until I followed the linked-list tutorial.

What I like about the latter is how closely it steps through the problem-solving process within the context of a very familiar task, teaching you at each stage 1) why the borrow-checker is upset and 2) what tool you need to apply in order to satisfy it. If the Book taught me "what is Rust and what are its features?", this taught me "how do I use Rust in practice?".

Re: Rust 1.46

#105

Post by apendleton »

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?

Meta-answer: my default when picking up a new language is usually to learn just enough to be able to start writing code, and then learn new things piecemeal as necessary to solve whatever thing I'm working on, and it sounds like you're hoping to do something like that here.

I found that approach for Rust in particular to not work well at all, and have colleagues who've reported the same. There are some fairly complicated, fundamental concepts that are unique to Rust that I think need to be tackled before you can really do much of anything (mostly borrowing and lifetimes), and that's not immediately obvious from starter programs -- because of lifetime elision, some early programs can look deceptively familiar, but there's a bunch of barely-hidden complexity there, and as soon as you start to stray from the tutorial path, you'll run headfirst into a wall of compiler errors that you're not yet equipped to understand. For Rust I'd highly recommend just reading a book cover to cover first (either TRPL or the O'Reilly one), and then starting to write code.

Re: Rust 1.46

#106

Post by steveklabnik »

brundolf wrote: post #104
steveklabnik wrote: post #100

Earlier quoted context omitted.

https://doc.rust-lang.org/stable/book/ch15-01-box.html https://doc.rust-lang.org/stable/book/ch15-04-rc.html

Yeah, I figured they were probably in there somewhere. It's possible I read the book before they were added, or that I skipped them (I glossed over some of the final chapters), or it's possible I just didn't fully grasp how important they were until I followed the linked-list tutorial. What I like about the latter is how closely it steps through the problem-solving process within the context of a very familiar task,…

Oh yeah, don't get me wrong, the linked-list tutorial is amazing. :)

Re: Rust 1.46

#107

Post by kibwen »

scott31 wrote: post #8

Note that entire rust team was recently fired from Mozilla, so it is unclear how the future looks like for the language. Especially since it does not have a spec and only have single reference implementation

> entire rust team was recently fired from Mozilla

This is completely incorrect, verging on FUD. Mozilla had very few people working full-time on Rust; of the people who were laid off in the recent wave, the ones working on projects adjacent to Rust were working on Servo or WASM-related codebases. In particular, the person at Mozilla who was most central to Rust development, Niko Matsakis, is still employed there and still working full-time on Rust.

Re: Rust 1.46

#108

Post by thomasahle »

eloff wrote: post #88
tgb wrote: post #69

Earlier quoted context omitted.

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…

I think that's it in a nutshell. You can't evaluate everything at compile time, even when you could theoretically. So you need some way to mark the subset of pure functions that can be evaluated at compile time, which is what const fn does. That way if a const fn only calls other const functions you know you can evaluate it. It's a convenient way of tagging functions.

That's what I thought I said in the original comment. I wonder what people disliked.

Re: Rust 1.46

#109

Post by brundolf »

datanecdote wrote: post #75
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?

I am in similar boat. Python centric data scientist. Very tempted to try to learn Rust so I can accelerate certain ETL tasks. Question for Rust experts: On what ETL tasks would you expect Rust to outperform Numpy, Numba, and Cython? What are the characteristics of a workload that sees order-of-magnitude speed ups from switching to Rust?

I'm far from an expert, but I would not expect hand-written Rust code to outperform Numpy. Not because it's Rust and Numpy is written in C, but because Numpy has been deeply optimized over many years by many people and your custom code would not have been. When it comes to performance Rust is generally comparable to C++, as a baseline. It's not going to give you some dramatic advantage that offsets the code-maturity factor.

Now, if you're doing lots of computation in Python itself - not within the confines of Numpy - that's where you might see a significant speed boost. Again, I don't know precisely how Rust and Cython would compare, but I would very much expect Rust to be significantly faster, just as I would very much expect C++ to be significantly faster.

Re: Rust 1.46

#110

Post by wtetzner »

ragnese wrote: post #80
int_19h wrote: post #71

Earlier quoted context omitted.

I think that Rust is often assumed to be functional because it has ADTs and nice pattern matching, both of which have historically been a feature specific to FP. Just goes to show how fuzzy our definition of FP really is...

Agreed. Same with "OOP". Who the hell knows what people really mean when they say that. Those people who think that "FP" means "type system like Haskell" are wrong, though, IMO. It precludes languages that are much more function-based, such as Clojure, Schemes, Elixir.

Functional in my mind more or less means means working with immutable values.
Post reply on HN