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

111–120 of 227 posts

Re: Rust 1.45

#111

Post by swagonomixxx »

laszlokorte wrote: post #94
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?

Assuming a unsigned byte, that range of values is between 0 and 255 inclusive, so `len(arr) <= 255` is correct.

Re: Rust 1.45

#112

Post by wtetzner »

laszlokorte wrote: post #94
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?

If you want to omit a bounds check, the compiler needs to know that the length of the array covers the upper bound of the loop, right?

Re: Rust 1.45

#113

Post by swagonomixxx »

person_of_color wrote: post #62
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.

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

It's rare that I've run into such issues when using Python for building trading algorithms - most of the overhead (for me) seems to be building a strategy using the data that you have available. Numerical computing libraries such as NumPy, Pandas, and so on in the Python ecosystem make this much easier to do in Python.

I feel like static typing would get in the way there, making code more verbose and more difficult to prototype while running possibly thousands of backtests (e.g, to tune hyperparameters of your model) but if that your preference, by all means, Rust should be usable for that.

Re: Rust 1.45

#115

Post by diffuse_l »

tialaramex wrote: post #105
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.

Saturated addition is indeed the correct way to add two PCM streams together. Especially back in the 1980s and 1990s you'd get awful code that did things like averaging the two streams because wrapping sounds awful and the authors were ignorant of the theory and/or unaware that saturated addition is a thing. You can tell when somebody did this because it means playing silence makes everything else quieter, or worse t…

At least on x86, saturated adds didn't become a thing until MMX was released. Doing saturated adds was simply too expensive on older machines, and usually required a branch.

Re: Rust 1.45

#116

Post by kibwen »

mesaframe wrote: post #104
steveklabnik wrote: post #72

Earlier quoted context omitted.

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.

Do you have specification of a memory model?

I believe it's safe to assume that Rust's memory model is (a subset of) C++11's memory model, since that's what LLVM implements. At this point I don't see how any specification could deviate significantly from that without breaking tons of code.

Re: Rust 1.45

#118

Post by kbenson »

staticassertion wrote: post #83
steveklabnik wrote: post #10

Earlier quoted context omitted.

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.

The thing that keeps the "two hardest things in CS" joke alive and still funny is that it's so, so true.

Re: Rust 1.45

#119

Post by kibwen »

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

There are some people who have already gotten Rust to work (with caveats) on Apple silicon: https://twitter.com/JakeGoulding/status/1279207843711811585

Re: Rust 1.45

#120

Post by Spartan-S63 »

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

They've really only spent about a year or so on async support in Rocket. They were waiting for async/await to stabilize and the async runtime story to centralize a bit (though they picked Tokio as the default).

Features like CORS are available via third party fairings, but I could see them being incorporated in the future in the `rocket_contrib` portion. I think the goal is to keep the overall framework pretty light and put more things into the `rocket_contrib` portion.

Post reply on HN