121–130 of 159 posts
Earlier quoted context omitted.
What do you mean by visually debug? If you install `probe-rs` and do `cargo run`, you can print whatever you want to console; not related to the IDE. (Not sure if this is what you're looking for, or something else)
Visual Studio-type ide debugging, viewing structs, run to cursor, etc.
https://marketplace.visualstudio.com/items?itemName=vadimcn....
For low level, hard realtime control and interrupt handling rust gets in the way. Many embedded applications stop here. For things like parsing, protocol stacks and business logic rust has a clear advantage. Interoperability with C is therefore essential. The current situation is good for ARM and RISC (ESP32) but impossible for weirder stuff like C28x. (See my demo here: https://github.com/driftregion/bazel-c-rust-x86_linux-armv7_... )
And why is the std_library less performant than, let's say, C's counterpart?
The paper may be Rust specific, but I found the CVE break down chart on p. 25 interesting. When looking at the percentages of the CVE causes (focused on the 59 bugs classified as those Rust prevents) I got the following: Out of Bounds Reads => 18.6%; Out of Bounds Writes => 62.7%; Null-Ptr Deref => 8.5%; Use-After-Free => 5.1%; Type Confusion, Uninitialized Pointer Access, Memory Leak => EACH 1.5%; I have to wonder a…
I used it for a custom board I made and it not only consumed less power overall due to the automatic chip sleep state handling but has been drastically easier to work with than the provided C firmware.
Developer is also super responsive on Matrix and a nice guy.
These are all real issues with Rust, though it's worth noting that many of the integration challenges mentioned also apply to external code written in C and C++. Some of the survey responses highlight one of the biggest hurdles to rust adoption I've experienced though: Rust has an education problem. People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of fail…
> People dramatically overestimate the correctness of their [C/C++] code Genuinely interested: what do people think of their tons of third-party dependencies in Rust? My experience building Rust projects is that there are orders of magnitudes more dependencies than what would make me comfortable. At least in C/C++ it's much harder to get there.
Interesting take. Poor package management as a security feature.
As others have pointed out, instead of potentially poorly written third-party dependencies C/C++ will just have potentially poorly written homebrew replacements.
Earlier quoted context omitted.
To be clear, I don't think there is any hope of implementing any protections at the language level in C, the push back would be exceptionally fierce. Although I do agree that a 'slice' type in the stdlib would not be to much to ask for. My comment was more for consideration in the design of new languages, in particular, the development of the frequently cited as not existing, simple, C-like language with memory safet…
The problem with slices in C being added in stdlib would be that they really are a generic data type. It would be similar to atomic types. While C++ could just add std::atomic , C needed to add a special construct: _Atomic(T). C++ already has a slice type. It’s called std::span . Porting it to C would probably require something similar to atomics. At which point I guess you may just as well get on with it and switch…
Buffer overflow vulnerabilities are where programmers thought they don’t need a bounds check, so having this as a choice every time, with the safer option looking worse, is working against it.
A nice minimal built-in syntax for spans (like Rust’s slices) could be an incentive to keep the bounds checks, and eventually make bare pointer arithmetic stand out as riskier.
Earlier quoted context omitted.
The problem with slices in C being added in stdlib would be that they really are a generic data type. It would be similar to atomic types. While C++ could just add std::atomic , C needed to add a special construct: _Atomic(T). C++ already has a slice type. It’s called std::span . Porting it to C would probably require something similar to atomics. At which point I guess you may just as well get on with it and switch…
C++ chose not to have bounds checking on span’s operator[] by default. Like with vector, approximately nobody will use .at(). Buffer overflow vulnerabilities are where programmers thought they don’t need a bounds check, so having this as a choice every time, with the safer option looking worse, is working against it. A nice minimal built-in syntax for spans (like Rust’s slices) could be an incentive to keep the bound…
FWIW you can enable bounds checks for the bracket operator by default for STL types in GCC and Clang. So for interfacing with Rust it is both obvious how to translate between slices in Rust and std::span in C++, and you can verify to a degree that this std::span isn’t corrupted on C++ side (to a degree).
These are all real issues with Rust, though it's worth noting that many of the integration challenges mentioned also apply to external code written in C and C++. Some of the survey responses highlight one of the biggest hurdles to rust adoption I've experienced though: Rust has an education problem. People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of fail…
For professional embedded programmers, faith in silver bullets disappears with the growth of professionalism.
Earlier quoted context omitted.
It's just something you have to care about, but it's not a show-stopper. We use a bunch of crates in our projects at work, I left some example sizes in a comment a while back https://news.ycombinator.com/item?id=34032824
It's a show stopper when size matters and you can't fit the binaries into flash. I'm sure "sorry for getting everyone to switch to this unestablished language" will go over very well with your boss and upper management. At least in C and C++ you can blame your tools. If you've stupidly convinced management the existing tooling is shit, then you've got a problem. And I don't mean a technical one, I mean a problem with…