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

121–130 of 157 posts

Re: Rust 1.46

#121

Post by Lendal »

nemothekid wrote: post #35
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 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…

I've tried and tried but I've never found a situation where explicit lifetimes was the answer. It's almost always more complex than that. I mean, everywhere that is complex enough that implicit lifetimes don't work is also too complex for explicit lifetimes and almost always required Rc or Arc to solve it. Maybe I'm missing something, but it seems like there are so many other missing topics the Rust Book could be spending time on that would be more effective than teaching about explicit lifetimes.

Re: Rust 1.46

#122

Post by crazypython »

est31 wrote: post #2

The most exciting component of this release is the const fn improvements. With loops and if available, you can now do non-trivial computation in const fn for the first time. It reduces the gap between Rust's const fn and C++'s constexpr to a large degree. Ultimately, the miri execution engine that this feature builds upon, supports a much larger set of features that even constexpr supports. It's been a project spanni…

Dlang has had CTFE for a long time. The engine just needs to be rewritten to reduce memory usage. https://tour.dlang.org/tour/en/gems/compile-time-function-ev...

Re: Rust 1.46

#123

Post by glandium »

jedisct1 wrote: post #86
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…

I've been writing Rust code since before the 1.0 days, and I still can't understand lifetimes in practice. When the compiler starts complaining about lifetimes issues, I tend to make everything clone()able (either using Rc, or Arc, or Arc+Mutex, or full clones). Because if you start introducing explicit lifetimes somewhere, these changes are going to cascade, and tons of annotations will need to be added to everythin…

I find that lifetimes are ok, albeit annoying sometimes, especially the cascade part, as you mention. The one thing I can't get to stick in my brain is variance. Every time, I need to go back to https://doc.rust-lang.org/nomicon/subtyping.html#variance

Re: Rust 1.46

#124

Post by glandium »

Matthias247 wrote: post #116
Arnavion wrote: post #115

Earlier quoted context omitted.

You sometimes have two Options that must both be Some to have any effect, but other reasons prevent you from making an Option of a tuple of those two fields. Eg think of deserializing a JSON that contains optional username and password strings, but you need both if you are to use them to authenticate to some remote. In that case, you currently have to write code like: if let (Some(username), Some(password)) = (userna…

The zip solution however requires any reviewer to look up on what it actually does, whereas the "if let" is more of a language fundamental and known to most reviewers. Therefore I would actually prefer the long/verbose form without the zip.

I think `Option::zip(&username, &password)` makes it somewhat clearer what it does.

Re: Rust 1.46

#125

Post by lenkite »

marricks wrote: post #41
est31 wrote: post #2

The most exciting component of this release is the const fn improvements. With loops and if available, you can now do non-trivial computation in const fn for the first time. It reduces the gap between Rust's const fn and C++'s constexpr to a large degree. Ultimately, the miri execution engine that this feature builds upon, supports a much larger set of features that even constexpr supports. It's been a project spanni…

I wonder why && and || are not allowed in const functions? > All boolean operators except for && and || which are banned since they are short-circuiting. I guess I'm missing something obvious but why does the short circuiting break const-ness?

That's a weird restriction on not allowing logical operators. AFAIK C++ allows this for constexpr functions - as long as it can be evaluated at compile time.

Re: Rust 1.46

#126

Post by Verdex »

Lendal wrote: post #121
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…

I've tried and tried but I've never found a situation where explicit lifetimes was the answer. It's almost always more complex than that. I mean, everywhere that is complex enough that implicit lifetimes don't work is also too complex for explicit lifetimes and almost always required Rc or Arc to solve it. Maybe I'm missing something, but it seems like there are so many other missing topics the Rust Book could be spe…

I wrote a parser that needed it. But yeah for the most part whenever explicit lifetimes came into the picture it means that I have made some sort of mistake and need to rethink my approach.

Re: Rust 1.46

#127

Post by datanecdote »

brundolf wrote: post #109
datanecdote wrote: post #75

Earlier quoted context omitted.

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…

I deal with a lot of ragged data that is hard to vectorize, and currently write cython kernels when the inner loops take too long. Sounds like Rust might be faster than cython? Thanks for the feedback.

Re: Rust 1.46

#128

Post by datanecdote »

Fiahil wrote: post #114
datanecdote wrote: post #75

Earlier quoted context omitted.

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?

column-wide map-reduce over large dataframes usually give you a 1000x or so speedup. With rust you can stream each record and leverage the insane parallelism and async-io libs (rayon, crossbeam, tokio) and a very small memory footprint. sure you have asyncio in python but that’s nowhere near the speed of tokio.

Thanks for the pointers, those crates seem great. The flaky multithreading libs are my least favorite part of python, and rust’s strength in this area seems very appealing.

Re: Rust 1.46

#129

Post by datanecdote »

IlyaOrson wrote: post #118
datanecdote wrote: post #75

Earlier quoted context omitted.

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?

Julia might be a better fit for this use case. That way you leverage a more developed data ecosystem, can call python when necessary and avoid writing low level code. Depends on the task of course.

I’m fascinated by Julia and have test driven it before but it didn’t click for me. Maybe I was doing it wrong and/or the ecosystem has matured since I last looked.

I guess I generally do like the pythonic paradigm of an interpreted glue language orchestrating precompiled functions written in other languages. I don’t need or want to compile the entire pipeline end to end after every edit, that slows my development iteration cycle times.

I just want to write my own fast compiled functions to insert into the pipeline on the rare occasions I need something bespoke that doesn’t already exist in the extended python ecosystem. It seems like a lower level language would be optimal for that?

Re: Rust 1.46

#130

Post by lmm »

Matthias247 wrote: post #116
Arnavion wrote: post #115

Earlier quoted context omitted.

You sometimes have two Options that must both be Some to have any effect, but other reasons prevent you from making an Option of a tuple of those two fields. Eg think of deserializing a JSON that contains optional username and password strings, but you need both if you are to use them to authenticate to some remote. In that case, you currently have to write code like: if let (Some(username), Some(password)) = (userna…

The zip solution however requires any reviewer to look up on what it actually does, whereas the "if let" is more of a language fundamental and known to most reviewers. Therefore I would actually prefer the long/verbose form without the zip.

It's just the opposite. zip is a normal function written in normal code, so if the reviewer doesn't know what it does then they can just click through to the definition in their IDE. Whereas "if let" is some kind of special language construct that a reviewer has to look up through some special alternative channel if they don't understand it.
Post reply on HN