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

Rust 1.45

blog.rust-lang.org

Post reply on HN
Print view View original

71–80 of 227 posts

Re: Rust 1.45

#71

Post by kd5bjo »

GolDDranks wrote: post #64
kd5bjo wrote: post #60

Earlier quoted context omitted.

Right, but given that panicing was already allowable behavior, why was the new behavior chosen to be one likely to introduce subtle bugs? It seems much better to loudly proclaim the existence of an erroneous precondition, which is consistent with how things like array indexing behave. I guess I’ll have to go dig up the RFC discussion on this one; it should make for interesting reading.

I thing you are right about that, I'd prefer panicking too. Also, reading the RFC will surely clear up the motivation. Without knowing this case, I'd wager a guess: it's about performance. Panicking introduces a branch and side-effects which, again, affects negstively optimization potential and performance. The saturating cast affects performance too, but less. If some old code has a lot of number crunching containin…

It looks like ‘as’ is generally defined as a truncating cast operator for other numeric types. Since it doesn’t panic for other overflow situations (like u64->u32), they chose consistency with those cases.

https://github.com/rust-lang/rust/issues/10184#issuecomment-...

Re: Rust 1.45

#72

Post by steveklabnik »

crazypython wrote: post #58
angrygoat wrote: post #8

This rather niche fixing of unsafe behaviour is excellent: https://blog.rust-lang.org/2020/07/16/Rust-1.45.0.html#fixin... I spent a few years as a scientific programmer and this is exactly the sort of thing that just bites you on the behind in C/C++/Fortran: the undefined behaviour can actually manifest as noise in your output, or just really hard to track down, intermittent problems. A big win to get rid of it.

Rust has no specification.

Sort of; we have more than nothing, but not a full thing.

Some things are well specified. Some things are mostly specified. Some things are still very much up in the air.

Re: Rust 1.45

#73

Post by harikb »

p4bl0 wrote: post #44
harikb wrote: post #34

Earlier quoted context omitted.

Is this undergrad? Genuinely curious, how will you get someone to understand what ownership helps avoid without them having experienced the pain on the other side? I guess with younger and younger kids learning programming these, may be there can handle more? I am not sure if my son would understand all of the intricacies in his first semester.

Yes it is a course aimed at undergrad students, in their second year at university. Of course they won't be able to grasp everything that Rust has to offer, but that is true of any language. I think Rust will expose them to many theoretical and practical CS concepts that they will be glad to have at least heard of during their studies. In our degree, the first year students learn to program with Python, Racket (or OC…

sorry, when you said first semester, I assumed you meant first semester of the 4 yr course, as in intro classes. But you probably meant first semester of this year. Either way, it is good to experiment. Thank you for doing that.

Re: Rust 1.45

#74

Post by jwr »

fullstop wrote: post #36

I keep seeing more and more news about Rust, and figure that perhaps it is time that I learn something new. 99% of my development work these days is C with the target being Linux/ARM with a small-ish memory model. Think 64 or 128MB of DDR. Does this fit within Rust's world? I've noticed that stripped binary sizes for a simple "Hello, World!" example are significantly larger with Rust. Is this just the way things are…

Your devices are huge compared to what I use: ARM Cortex M0+ and M4 microcontrollers with anywhere from 8kB to 1MB of flash, and 4kB-128kB of RAM.

I really hope that more enlightened vendors (hi Nordic Semiconductor) will start supporting Rust on their platforms.

Re: Rust 1.45

#75

Post by steveklabnik »

rockmeamedee wrote: post #63

The post says The new API to cast in an unsafe manner is: let x: f32 = 1.0; let y: u8 = unsafe { x.to_int_unchecked() }; But as always, you should only use this method as a last resort. Just like with array access, the compiler can often optimize the checks away, making the safe and unsafe versions equivalent when the compiler can prove it. I believe for array access you can elide the bounds checking with an assert l…

Interestingly enough, it looks like that does not in fact change how the check works https://godbolt.org/z/rdxrh1

Here's an example of how when it can detect it, it does the right thing: https://godbolt.org/z/hPqf69

I am not an expert in these hints, maybe someone else knows!

Re: Rust 1.45

#77

Post by jfkebwjsbx »

pwdisswordfish2 wrote: post #23
davrosthedalek wrote: post #12

Earlier quoted context omitted.

I'm not sure I understand this. Does it not produce a run time error? Why not? This looks very dangerous, because it essentially does the "nearest to right" thing. Say, you cast 256 to a u8, it's then saturated to 255. That's almost right, and a result might be wrong only by 0.5%. Much harder to detect than if it is set to 0.

> I'm not sure I understand this. Does it not produce a run time error? Why not? It’s not supposed to. Type casting with ‘as’ is supposed to be lightweight and always succeed; there is no room in the type system to return an error. In case lossless casting is not possible, some value still has to be returned. Until now, this was outright UB — meaning the compiler is not even obligated to keep it consistent from one b…

> there is no room in the type system to return an error

There is: you panic, like in the array case.

That would have been much robust (at the cost of performance).

Re: Rust 1.45

#78

Post by baseballdork »

sjwright wrote: post #65
nitrogen wrote: post #53

Earlier quoted context omitted.

When working with audio as an example, saturation is much less obnoxious than wraparound. You can potentially destroy speakers and your hearing that way.

Why would you want math errors to be less obnoxious?

I think they just prefer them to be less destructive.

Re: Rust 1.45

#79

Post by p4bl0 »

bestouff wrote: post #50
p4bl0 wrote: post #14

By any chance if anyone is in the Paris area and is interested to teach Rust at university next year during the first semester. Please get in touch :).

Do you pay the daily transit from Grenoble area ?

Sadly no, we cannot do that :(.

Re: Rust 1.45

#80

Post by Tade0 »

baseballdork wrote: post #9

> array[i] will check to make sure that array has at least i elements. At least i+1 elements, right? Or am I getting caught up by one of the three hardest problems again?

IIRC there were two problems that were the hardest:

1. Naming things.

2. Cache invalidation.

3. Off by one errors.

Number 3 apparently the hardest one.

Post reply on HN