61–70 of 172 posts
Earlier quoted context omitted.
[flagged]
> Rust is evolving far too fast to be used in code which needs to run for years to decades down the line. Code doesn’t stop running on existing hardware when the language changes in a future compiler. You can still use the same old toolchain. I’ve done a lot of embedded development in a past life. Keeping old tool chains around for each old platform was standard. I would much rather go through the easy process of swi…
Earlier quoted context omitted.
[flagged]
Rust uses "Editions" (e.g., 2015, 2018, 2021, 2024) to introduce breaking changes without splitting the ecosystem. Every edition remains supported by newer compiler versions _indefinitely_. The only churn is on projects targeting "nightlies" but there's no reason you can't target a stable one for projects that need that stability.
Earlier quoted context omitted.
[flagged]
Rust uses "Editions" (e.g., 2015, 2018, 2021, 2024) to introduce breaking changes without splitting the ecosystem. Every edition remains supported by newer compiler versions _indefinitely_. The only churn is on projects targeting "nightlies" but there's no reason you can't target a stable one for projects that need that stability.
Now I’ve not extensively used Rust but almost everytime I did it ended up needing nightly to use some library or other.
> It is concluded that Rust is a sound choice today for firmware development in this domain. This conclusion was reached with a single experiment. > Two teams concurrently developing the same functionality — one in C, one in Rust — are analyzed over a period of several months. > Furthermore, Ariel OS is shown to provide an efficient and portable system runtime in Rust whose footprint is smaller than that of the state…
> In Figure 12, they simply stop optimizing the code once desired rate is reached. Yes. The goal was to handle the maximum data rate of the used sensor, and stop there. Time was limited on both ends. > Just at the end of the project the Rust firmware gets over a third performance boost, most likely from their OS developers. The ST intern found those boosts all by himself. They compared the exact MCU & peripheral init…
I understand, and I understand that there were limits to what could be done with the resources there were. What irks me is the strength of the claim made without enough evidence to make it.
> The ST intern found those boosts all by himself. They compared the exact MCU & peripheral initialization of the C and Rust firmwares, tightened I2C timings (where STM Cube has vendor tuned & qualified values), and enabled the MCU's instruction cache, which somehow is not default in Embassy's HAL. We were quite impressed actually, the last days before the deadline were quite productive, optimization wise.
Fair enough, hats off to the intern. This kind of thing is common in MCUs, even on low-end CPUs weird defaults can be selected. But the involvement and influence of the OS developers remains unclear.
Again, there's just not enough data to make such strong claims. I think the paper could easily make recommendations, it could say that at least in some cases (as evidenced) Rust could be a reasonable choice, and it could make an argument for further work.
Earlier quoted context omitted.
Rust uses "Editions" (e.g., 2015, 2018, 2021, 2024) to introduce breaking changes without splitting the ecosystem. Every edition remains supported by newer compiler versions _indefinitely_. The only churn is on projects targeting "nightlies" but there's no reason you can't target a stable one for projects that need that stability.
Unfortunately quite a few useful Rust libraries seem to require nightly. Now I’ve not extensively used Rust but almost everytime I did it ended up needing nightly to use some library or other.
Earlier quoted context omitted.
> Rust is evolving far too fast I'm curious why I've seen this sentiment repeated in so many places, I learned Rust once 5 years ago and I haven't had to learn any new idioms and there have been no backwards incompatible changes to it that required migrating any of my code.
I think people don't like the JavaScript treadmill. People want to think about using tools and getting proficient with them rather than relearning tools. I'm not saying rust is like that, but I do feel that way about python and JavaScript. Those are dynamic languages but it is what all this editions stuff evokes. It's an if it were stable, it wouldn't be changing sort of thing.
This attitude works in carpentry, but not in software. You need to get proficient, but your tools will keep evolving, like everything else in the software world.
Earlier quoted context omitted.
[flagged]
> Rust is evolving far too fast to be used in code which needs to run for years to decades down the line. Code doesn’t stop running on existing hardware when the language changes in a future compiler. You can still use the same old toolchain. I’ve done a lot of embedded development in a past life. Keeping old tool chains around for each old platform was standard. I would much rather go through the easy process of swi…
Unless you find out the compiler was buggy and was producing faulty binaries, but the new compiler can no longer compile the old code.
Earlier quoted context omitted.
Rust uses "Editions" (e.g., 2015, 2018, 2021, 2024) to introduce breaking changes without splitting the ecosystem. Every edition remains supported by newer compiler versions _indefinitely_. The only churn is on projects targeting "nightlies" but there's no reason you can't target a stable one for projects that need that stability.
That invariably leads to bitrot and low maintainability. It's one among many reasons why I don't use Rust.
We passed on Rust for Ada/SPARK2014 to write to bare metal on Cortex-M processor for real-time, high-integrity, and verifiable mission-critical software. Rust is making strides to be a future competitor, but it's new to the formal verification tooling and lacks any real world legacy in our domain. Ada's latest spec. is 2022. Other than AdaCore's verified Rust compiler, Rust still does not have a stable language speci…
Edit: With c, you can do memory safety analysis on all system libraries and entire Linux kernel. Some OS kernels, libs and languages do not have dynamic memory allocation at all!
Some languages are memory safe! Learn more about embedded programming!
Earlier quoted context omitted.
Wait, are you implying that code written in Rust somehow "rusts"?
Code in all languages bitrots. Even if your dependencies are "done", the language is unchanging, the toolchain mature, a vendor can introduce a new platform and all of a sudden your code won't compile anymore, because IBM introduced a new RISC server platform, or macOS changed the definition of time_t, or Windows blocked direct win32.DLL access (I know, a stretch), that your older libraries didn't know about.
[1] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/