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

51–60 of 227 posts

Re: Rust 1.45

#51

Post by gameswithgo »

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.

Agree, a lot of people focus on Rust and memory safety vs C/C++, but the lack (nearly) of undefined behavior is at least as important/helpful.

Re: Rust 1.45

#52

Post by kd5bjo »

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…

As it was UB anyway, wouldn’t the compiler also be within its rights to detect the problem and panic the thread?

Re: Rust 1.45

#53

Post by nitrogen »

milancurcic wrote: post #27
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.

Fortran predictably overflows the result, in contrast to fptoui which gives a poison value. I agree that even a predictable overflow can bite you on the behind. But it's better than undefined behavior. I'm not a fan of saturated cast, but having a defined behavior is for sure a great improvement.

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

Re: Rust 1.45

#54

Post by nicoburns »

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…

If you're running Linux with MBs of RAM, then you're well within Rust's comfort zone. If you're on embedded ARM (cortex-M) with KBs RAM, then Rust will be really nice and it does work today, but there's still a few missing features to make it nice to use.

Re: Rust 1.45

#55

Post by GolDDranks »

kd5bjo wrote: post #52
pwdisswordfish2 wrote: post #23

Earlier quoted context omitted.

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

As it was UB anyway, wouldn’t the compiler also be within its rights to detect the problem and panic the thread?

Yes, it would. However, it rarely does because of how the incentives are: it's useful for optimization to pretend that UB never happens, and more optimization leads to faster binaries, which are what the compiler engineers often pursue.

Re: Rust 1.45

#56

Post by pjmlp »

nitrogen wrote: post #53
milancurcic wrote: post #27

Earlier quoted context omitted.

Fortran predictably overflows the result, in contrast to fptoui which gives a poison value. I agree that even a predictable overflow can bite you on the behind. But it's better than undefined behavior. I'm not a fan of saturated cast, but having a defined behavior is for sure a great improvement.

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

Wraparound is also the bug that turns Ghandi into a huge dictator in Civilization, and killed a couple of people in cancer treatment devices.

Re: Rust 1.45

#58

Post by crazypython »

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.

Re: Rust 1.45

#59

Post by lucasmullens »

mas3god wrote: post #45
person_of_color wrote: post #13

Any algo-trading backtest frameworks in Rust?

All you need for algotrading is to query an api. Rust would be a poor choice for that anyways, like using a semi truck to carry your bike around.

Performance is super critical in high frequency trading, so Rust sounds like reasonable choice. Having your code run a millisecond faster means beating out a competitor with the same algorithm as you, getting you a better price.

Re: Rust 1.45

#60

Post by kd5bjo »

GolDDranks wrote: post #55
kd5bjo wrote: post #52

Earlier quoted context omitted.

As it was UB anyway, wouldn’t the compiler also be within its rights to detect the problem and panic the thread?

Yes, it would. However, it rarely does because of how the incentives are: it's useful for optimization to pretend that UB never happens, and more optimization leads to faster binaries, which are what the compiler engineers often pursue.

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.

Post reply on HN