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

221–227 of 227 posts

Re: Rust 1.45

#221

Post by Bx6667 »

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.

I have no idea what you’re talking about. Rust is not faster than c or anything else necessarily that is not garbage collected. It is almost as fast, and it has memory safety and as is made apparent in this thread many advantages in terms of usability and undefined behavior. Being the quickest i s not something rust is known for. So you wouldn’t be saving milliseconds. And calling an api is pretty simple so the security aspect wouldn’t be of much use. So you are wrong and the guy you are responding to is right.

Re: Rust 1.45

#222

Post by TheRealKing »

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.

In Fortran, there is the ieee_arithmetic intrinsic module that can very nicely and robustly handle undefined behavior. If people do not use it, it is their problems.

Re: Rust 1.45

#223

Post by kazinator »

The_rationalist wrote: post #215
kazinator wrote: post #181

Earlier quoted context omitted.

> plenty of libraries with stable APIs that are buggy piles of hacks. E.g. the API: char *gets(char *s); has not changed in probably forty years. Rock stable!

Not A imply not B, does not imply that A imply B.

Nobody on the internet but you knows about the contrapositive; but you can fix that!

Re: Rust 1.45

#224

Post by person_of_color »

proverbialbunny wrote: post #121
person_of_color wrote: post #13

Any algo-trading backtest frameworks in Rust?

Not that I'm aware of. I wrote my own. Rust has great libraries to make life easy, eg https://docs.rs/fixed/1.0.0/fixed/ (Note: I haven't benchmarked the 4 or 5+ fixed precision libraries Rust offers to see which is best.)

Are you open sourcing it?

Re: Rust 1.45

#225

Post by maxkrieger »

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…

Dunno if it's apples and oranges for you, but I've seen Zig [0] being thrown around here previously as a "safer" embedded C alternative, albeit more minimal than Rust. May be worth comparing (I haven't tried either language).

[0] https://ziglang.org/

Re: Rust 1.45

#226

Post by pwdisswordfish2 »

kd5bjo wrote: post #89
dathinab wrote: post #84

Earlier quoted context omitted.

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

That phrasing seemingly implies that there was a generally-agreed intended behaviour for that case that was unfortunately neither documented nor actually exhibited. But that was not the case. The overflow behaviour of float-to-int casts was undefined, full stop. There was some consensus as to what such casts should not do, but no agreement on what the actual behaviour should be. Eventually, the discussion settled on defining casting overflow to saturate, and the implementation was altered to match.

Re: Rust 1.45

#227

Post by The_rationalist »

kazinator wrote: post #223
The_rationalist wrote: post #215

Earlier quoted context omitted.

Not A imply not B, does not imply that A imply B.

Nobody on the internet but you knows about the contrapositive; but you can fix that!

Well I guess I have to expand the symbols for you, here we go: No api stability heuristically imply no production readiness does not imply that api stability imply production readiness.

As you snarkily imply, the contrapositive should be common sense and not need to be stated. Yet your brain failed to see that your comment on gets() is exactly such a needless truism.

Post reply on HN