267
White House: Future Software Should Be Memory Safe
(www.whitehouse.gov)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 26 Feb 2024
267 points (96.5% liked)
Programming
17314 readers
93 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
I don't even think we really need to eek out every MHz or clock cycle of performance these days unless your shipping code for a space vehicle or something (But that's an entirely different beast)
We've got embedded devices shipping with 1GHz+ processors now
It's just time to move on from C/C++, but some people just can't seem to let go.
That is the mindset that gives us text editors using 100% cpu to blink a cursor because their css triggers a bug in the web browser they ship to render the text editor.
You can be memory save without shipping a whole browser, but disregarding power and memory efficiency will just make performance gained by hardware evaporate in overhead.
Battery life is a reason. I've had clients come to me complaining their solution from another vendor didn't last very long. Turns out it was running Java on an embedded device.
Why would java have an impact on battery performance ? Pretty much all credit cards run java for their encryption algorithms, and they need pretty much no power to run.
The JVM isn't free. It was a simple data collection device that interfaces with a sensor which ideally doesn't need maintenance as long as possible. Something light written in C is more than enough.
There are orders of magnitude in what is considered low current. I've worked on a product that was guaranteed 2 years of lifetime for 3 AA batteries.
Because there is still market for small mcus. A 1GHz processor is a lot more expensive than a 32 bits 75MHz. If you produce even a low number of units, the price difference can be huge.
A lot of those mcus don't need to run particularly complex programs. Many of them don't do anything more complicated than reading the status of a pin and using that to activate another pin. 75MHz with a Rust program is more than enough.
For that matter, when Python was first released, the Intel Pentium wasn't even out yet. People made it work. Micropython could handle the above just fine provided the polling rate didn't need to be that high.
It'll all depend on the application, of course, but a huge number of mcu programs could easily be Rust. The performance hit is not that big. The code size on lower end mcus is also going to be naturally limited by their flash space, so even the compiler speed isn't going to be a big hit.
One thing is that the last time I tried using Rust on an esp32, the toolchain was still in its infancy and didn't work very well. Looks like Go has been ported in, as well, but it doesn't support wifi or bluetooth on the esp32. Or even i2c or pwm.
I haven't seen a test on the difference between rust and c, but your last point is the biggest caveat for rust.
If you have been running the same toolchain on multiple products, changing the language means a productivity loss because the devs need to learn the ins and outs of the new language, and if the toolchain is buggy, then it is another productivity loss.
I'm always eager to try out new stuff in products I design, but the incertitude and productivity loss is a no go because I can just spin a barebone code that works in half a day.
Until the tool chain is mature, C will still exist.
The Rust community has 2 websites that I keep periodically checking: Are we game yet? and Are we GUI yet?. The answers on those sites are respectively (as of February 2024, when this comment is written) "Almost. We have the blocks, bring your own glue" and "The roots aren't deep but the seeds are planted". I've seen the progress in Bevy and Slint, but it's still the same, those websites don't change, and my situation WRT to making a Rust project for fun or work it's the same.
I'll be happy to start doing Rust projects whenever I get the chance (which will be when it's a sufficient tool for my use cases). But I'm tired of smoke sellers.
Have you actually tried making a GUI or a game? I don't think you can summarize the state of the whole ecosystem in a sentence that doesn't change in years. I've made perfectly functional GUIs with iced, and imgui. Haven't tried slint yet.
Godot is a very popular game engine and it's written in rust, so you probably can use it in rust.
Godot is written in C++ not Rust…
That's true. I might've gotten confused because I saw godot rust bindings.
I've wanted to start a project in Rust, but for the ideas that I have (and the time that I have for a hobby project, as for work it's rarely starting a new one, but continuing and existing one), Rust seemed a viable, but not ideal alternative to just doing it all in C++, for which I already have enough knowledge and very well proven libraries. I will look again soon, and I will keep looking because eventually something will surely click, it's just that so far, the time has not been right.
Note that my point is not that it's unusable for everyone. Just that it's false that "some people just can't seem to let [C or C++] go", as the previous comment said. I can't let go something that works well for something that doesn't, given the projects that I have to work on.