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

81–90 of 227 posts

Re: Rust 1.45

#81

Post by jfkebwjsbx »

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 is't about performance because array indexing also panics.

Re: Rust 1.45

#82

Post by hellofunk »

steveklabnik wrote: post #40
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 smallest Rust binary ever produced was 145 bytes. https://github.com/tormol/tiny-rust-executable That is a bit extreme but it demonstrates the lower bound. There's a lot of things you can do to drop sizes, depending on the specifics of what you're doing and the tradeoffs you want to make. Architecture support is where stuff gets tougher than size, to be honest. ARM stuff is well supported though, and is only goin…

> ARM stuff is well supported though

FYI Rust (and Go) currently don’t work on the new Apple ARM macs.

https://news.ycombinator.com/item?id=23856806

Re: Rust 1.45

#83

Post by staticassertion »

steveklabnik wrote: post #10
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?

Nope, you're right, it was me that got caught up by it. :) Thanks, I'll fix that now. https://github.com/rust-lang/blog.rust-lang.org/commit/fe241... (should roll out in a few minutes)

And this is why we need bounds checking.

Re: Rust 1.45

#84

Post by dathinab »

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.

1. Panicing is not in line with how `as` casts are supposed to act. (e.g. `u32value as u8` does not panic but just takes the "lower" one byte.)

2. This might (I haven't profiled it) introduce performance regressions in ways which should not happen.

3. Besides in some usages around `dyn` other usages of `as` get increasingly more alternatives. It's just a question of time until `as` (for int/float casts) is recommended to not be used at all, maybe even linted against.

4. Given precedence of many other programming languages people don't expect a "simple" float to int cast to be failable. (The new methods replacing `as` make the fallibility clear, as it's e.g. `u64::try_from(bigf64)`).

5. It's udef-ness is only detected/handled in llvm, _I don't know_ if llvm provides similar well integrated mechanisms for this as it does for integer overflows. If not that would be another problem.

Re: Rust 1.45

#85

Post by TomMarius »

Sharlin wrote: post #68
chowells wrote: post #47

Earlier quoted context omitted.

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

That could literally produce no output program?

Re: Rust 1.45

#86

Post by rjeli »

TomMarius wrote: post #85
Sharlin wrote: post #68

Earlier quoted context omitted.

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.

That could literally produce no output program?

c.f. “nasal demons”

Re: Rust 1.45

#87

Post by kibwen »

davrosthedalek wrote: post #12
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.

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.

> Why not?

For better or worse, Rust 1.0 released with the philosophy that the `as` operator is for "fast and loose" conversions where accuracy is not prioritized; e.g. casting a u32 to a u8 would always risk silently truncating in the event the value was too large to represent. Over the years the language has added a lot of standard library support for bypassing the `as` operator entirely, and I think the prevailing opinion at this point might be that if they had the to do it all over again they might not have had the `as` operator at all, instead making do with a combination of ordinary error-checked conversion methods and the YOLO unsafe unchecked methods as seen here.

Which is to say: it's not that they technically couldn't have gone with the panic approach, but (performance implications aside) I think they'd rather just start moving away from `as` in general wherever possible.

Re: Rust 1.45

#88

Post by wtetzner »

ldng wrote: post #35
trait wrote: post #2

https://github.com/SergioBenitez/Rocket on stable rust finally!

IMHO, it's a shame So Much time has been spent (~3 years ?) on async at the cost of basic features like multipart and CORS. But I understand it could be more fun for the devs :-)

I think it makes sense to get your foundation and ergonomics correct before piling on features. Otherwise you end up building features that may need to be completely restructured/redone later.

Re: Rust 1.45

#89

Post by kd5bjo »

dathinab wrote: post #84
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.

1. Panicing is not in line with how `as` casts are supposed to act. (e.g. `u32value as u8` does not panic but just takes the "lower" one byte.) 2. This might (I haven't profiled it) introduce performance regressions in ways which should not happen. 3. Besides in some usages around `dyn` other usages of `as` get increasingly more alternatives. It's just a question of time until `as` (for int/float casts) is recommende…

> Panicing is not in line with how `as` casts are supposed to act. (e.g. `u32value as u8` does not panic but just takes the "lower" one byte.)

So, instead of this being traditional UB, it was a combination of two separate issues:

- Rustc erroneously emitting code that exercised an LLVM UB case, and

- Imprecise Rust documentation around the exact behavior of float -> int ‘as’ casts

Re: Rust 1.45

#90

Post by estebank »

lucasmullens wrote: post #59
mas3god wrote: post #45

Earlier quoted context omitted.

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.

Be aware that Rust gives you the tools to be fast, it is not necessarily fast by default, although a lot of constructs it guides you towards usually help with that. You still need to profile your code to see what you need to optimize, whereas other languages with fewer knobs will perform optimizations that you otherwise need to manually annotate in your code in Rust. I prefer this approach, but it can be surprising to people used to the alternative.
Post reply on HN