Live data from Hacker News

Rust 1.45

blog.rust-lang.org

201–210 of 227 posts

Re: Rust 1.45

#201
post #39

I'm building an embedded project that currently runs a python script for automatic brightness. It takes a brightness value from a sensor over I2C, applies a function to get an appropriate LCD brightness value and then sends that to the display driver over a serial port. Would this be an appropriate project to write in Rust to learn the basics of this language?

Yup, I've got a small little rust component that translates a couple industrial sensors on modbus + rtl_r443 over to an influx database and it's been happily running along for a few months now.

Re: Rust 1.45

#202
post #133

Can we please deprecate the "as" operator? Something so lossy and ill-conceived should not be a two-letter operator.

Then what do you propose for replacement? C++ style casts `(int) x` ?

Re: Rust 1.45

#203

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…

Some simple firmware I'm writing (controls some lights, takes rotary encoder input, prints stuff on serial) is currently 8K. It's written in Rust and targets the stm32f1xx and stm32f4xx chips.

Re: Rust 1.45

#204

Earlier quoted context omitted.

`as` is not considered idiomatic in Rust code,. `.into()` for infallible cases and `.try_into()` for fallible cases are preferred in almost all cases (in the case of floats there's still discussion around the correct behavior of `.try_into()` for edge cases). > So I think this is again an example of rust making a decision that hurts program correctness. Could you expand on other examples?

> `as` is not considered idiomatic in Rust code Yes it is. It's used all the time . There's a reason as_conversions defaults to Allow in clippy. Of course, there are lots of situations where `as` is the wrong tool for the job, but I think it's a bit of a stretch to call `as` "not idiomatic". It's perfectly idiomatic in lots of situations. Whether or not it should be idiomatic is a separate question.

But clippy will also scream at you if you convert a larger type to a smaller one.

Re: Rust 1.45

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

You would have to use unsafe and you'd be better off with C++. Also people who care about latency do not bother with the OS network stack. It's not a simple matter of picking language and magically going faster.

Re: Rust 1.45

#206

Earlier quoted context omitted.

I’m not a rust programmer, reading your explanation here it’s not anymore clear why some macros exist (println for instance). They very much look similar to functions in most of the cases I’ve seen (again from the perspective of trying to find a reason besides safety to learn rust) so why exactly do these exist? They are a great source of confusion for those of us with C/C++ experience (or at least me) which is the t…

println is a macro in Rust because 1) the language currently lacks support for variadic functions and 2) being a macro allows the format string to be parsed at compile time.

Long-term, with const generics, and VG (or a macro that creates a (a, (b, (c, ()))) nesting like the hlist crate), we could maybe replace format_args! and friends.

However, there is one more thing a function can't do: borrowing arguments. Formatting never moves arguments because the format_args! macro generates references to them, which it then creates std::fmt::Argument out of.

Re: Rust 1.45

#207
post #202
post #133

Can we please deprecate the "as" operator? Something so lossy and ill-conceived should not be a two-letter operator.

Then what do you propose for replacement? C++ style casts `(int) x` ?

Using `x.into()` instead or `x.try_into()` if it can fail.

Re: Rust 1.45

#208
post #198
post #29

> Rust 1.45.0 adds the ability to invoke procedural macros in three new places! Rust 1.45 will be the Rocket Release. It unblocks Rocket running on stable as tracked here https://github.com/SergioBenitez/Rocket/issues/19 This is so excellent, and I love seeing long term, multiyear goals get completed. It isn't just this release, but all the releases in between. The Rust team and community is amazing.

For those out of the loop like me, Rocket is a web framework for Rust that apparently was using a lot of experimental features. https://rocket.rs/ Or maybe it's an explosive weapon crafted with metal pipe and gunpowder. https://rust.fandom.com/wiki/Rocket

Hadn’t heard of it, but it looks a lot like flask. Good stuff, maybe I should consider looking into Rust after all.

Re: Rust 1.45

#209
post #202
post #133

Can we please deprecate the "as" operator? Something so lossy and ill-conceived should not be a two-letter operator.

Then what do you propose for replacement? C++ style casts `(int) x` ?

into()/try_into() and methods designed for each of the other cases (e.g. truncate(), saturating_to_int(), approx_to_float(), etc.)
Post reply on HN