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

91–100 of 227 posts

Re: Rust 1.45

#91

Post by steveklabnik »

hellofunk wrote: post #82
steveklabnik wrote: post #40

Earlier quoted context omitted.

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

That is not entirely correct for Rust. I know because I helped a friend of mine debug the porting process. (Apple did not see fit to give me access to the hardware, alas.)

https://github.com/rust-lang/rust/issues/73908 has the full details.

(Also, not to be super pedantic, but this (among other things) is partially why I said "and is only going to get better in the future," that is, the support is generally good (I know, I am literally doing some of that in another tab right now) but not flawless.)

Re: Rust 1.45

#92

Post by FartyMcFarter »

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

Can it "often" solve the halting problem as well?

The hope that this kind of optimization will happen sounds a bit fanciful for any non-trivial part of a program.

Re: Rust 1.45

#93

Post by kibwen »

jfkebwjsbx wrote: post #77
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…

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

For consistency you would also expect `257u32 as u8` to panic (which it doesn't, and never has); the `as` operator has always been about fast-and-lossy conversions, with the standard library ideally providing methods for more principled conversions.

Re: Rust 1.45

#94

Post by laszlokorte »

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…

It should be `assert!(len(arr) >= 255)` (greater instead of less than), right?

Re: Rust 1.45

#95

Post by hellofunk »

steveklabnik wrote: post #91
hellofunk wrote: post #82

Earlier quoted context omitted.

> 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

That is not entirely correct for Rust. I know because I helped a friend of mine debug the porting process. (Apple did not see fit to give me access to the hardware, alas.) https://github.com/rust-lang/rust/issues/73908 has the full details. (Also, not to be super pedantic, but this (among other things) is partially why I said "and is only going to get better in the future," that is, the support is generally good (I k…

Very interesting, thanks for the link!

Re: Rust 1.45

#96

Post by oblio »

hellofunk wrote: post #82
steveklabnik wrote: post #40

Earlier quoted context omitted.

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

That platform is not even out yet. Outside of Apple's stuff, I doubt any ecosystem supports it.

Some probably won't support it years after it's available for actual commercial products...

Re: Rust 1.45

#97

Post by Spivak »

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?

Yep! Dumb example.

    main()
      x = get_from_some_external_data_source()
      if x:
        print("Hello World")
        trigger_ub()
You might expect this code to always print if x is true but the optimizer can look at this and say "welp, if x is true then it would trigger ub, therefore it must be false, and since x must always be false we can just remove that entire branch."

Re: Rust 1.45

#98

Post by steveklabnik »

hellofunk wrote: post #95
steveklabnik wrote: post #91

Earlier quoted context omitted.

That is not entirely correct for Rust. I know because I helped a friend of mine debug the porting process. (Apple did not see fit to give me access to the hardware, alas.) https://github.com/rust-lang/rust/issues/73908 has the full details. (Also, not to be super pedantic, but this (among other things) is partially why I said "and is only going to get better in the future," that is, the support is generally good (I k…

Very interesting, thanks for the link!

You're welcome! And I'm sorry you're downvoted, I think that's a little overly harsh. Had I not known, that would have been helpful.

Re: Rust 1.45

#99

Post by hellofunk »

oblio wrote: post #96
hellofunk wrote: post #82

Earlier quoted context omitted.

> 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

That platform is not even out yet. Outside of Apple's stuff, I doubt any ecosystem supports it. Some probably won't support it years after it's available for actual commercial products...

No need to yell, it’s a relevant point to make since we’re talking about ARM.

Not sure also what you mean by giving it a rest, this is the first time I’ve made a comment on this point.

Update: thanks for editing your comment to be less offensive.

Re: Rust 1.45

#100

Post by oblio »

hellofunk wrote: post #99
oblio wrote: post #96

Earlier quoted context omitted.

That platform is not even out yet. Outside of Apple's stuff, I doubt any ecosystem supports it. Some probably won't support it years after it's available for actual commercial products...

No need to yell, it’s a relevant point to make since we’re talking about ARM. Not sure also what you mean by giving it a rest, this is the first time I’ve made a comment on this point. Update: thanks for editing your comment to be less offensive.

I've removed the yelling :-)

Someone else was saying the same thing in the comment you linked. I'll summarize it as:

"Rust takes time to port to a platform which is not even commercially available".

Post reply on HN