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

61–70 of 227 posts

Re: Rust 1.45

#61

Post by zozbot234 »

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…

> 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 and the "cost of protection"?

Relevant: https://news.ycombinator.com/item?id=23496107

Re: Rust 1.45

#62

Post by person_of_color »

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.

I was more thinking of correctness - static typing + memory safety would reduce likelihood of runtime errors.

Re: Rust 1.45

#63

Post by rockmeamedee »

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 like

  assert!(len(arr)
I'm guessing it would work like this with casts?

  assert!(x = 0);
  let y: u8 = x as u8; // no check

Re: Rust 1.45

#64

Post by GolDDranks »

kd5bjo wrote: post #60
GolDDranks wrote: post #55

Earlier quoted context omitted.

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.

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 containing these operations, a big performance regression would be nasty.

Re: Rust 1.45

#65

Post by sjwright »

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.

Why would you want math errors to be less obnoxious?

Re: Rust 1.45

#66

Post by riquito »

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…

The following is a very good resource, going from safe/practical ways to reduce the size (like `strip`) to more advanced and unpractical builds (up to 8KiB hello world, removing... a lot).

https://github.com/johnthagen/min-sized-rust

Re: Rust 1.45

#68

Post by Sharlin »

chowells wrote: post #47
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…

> meaning the compiler is not even obligated to keep it consistent from one build to another. Way worse than that. The compiler wasn't obligated to act like anything at all. It would be totally legal to compile it so that the first time the value was accessed you got 0, the next time you got 1 - within the same program execution, with no mutation of the value. That is the sort of thing that is observed behavior of UB…

Way worse than that, even. UB poisons every state of the program that eventually results in UB. For example, the optimizer is well within its rights to remove as dead code any branch that, if taken, would provably lead to UB at some arbitrary future point of execution.

Re: Rust 1.45

#69

Post by oconnor663 »

cjhanks wrote: post #57

Doesn't this mean that a conditional branch is added to all existing code which performs casting?

I think in the specific case of casting a float to an int, more instructions will be added, but it doesn't have to be a branch. Here it looks like rustc emits a conditional move: https://godbolt.org/z/1cfqof

Re: Rust 1.45

#70

Post by PudgePacket »

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…

Rust also statically links by default.
Post reply on HN