5 ms·

Authors are from STMicro, polytechnic Turin, Freie universitat Berlin, and Inria. Examined writing firmware for an IOT sensor platform. From the abstract: > Tw

• noosphr 6mo ago
  [flagged]
  • staticassertion 6mo ago
    > Rust is evolving far too fast to be used in code which needs to run for years to decades down the line. That statement deserves support.
    • pezo1919 6mo ago
      [flagged]
    • fluffybucktsnek 6mo ago
      Why, given the existence of editions?
      • whytevuhuni 6mo ago
        Very surprised to hear that, since editions are exactly the kind of mechanism Rust is using to make sure software will keep working unchanged for decades. The Rust compiler can build a 2024 edition application which depends on a 2015 edition library, which in turn depends on a 2018 edition library. Every crate can upgrade at their own pace, or even never at all.
        • fluffybucktsnek 6mo ago
          Oh, I'm aware about the benefits of editions. For some reason, I've misread OP's comment.
      • staticassertion 6mo ago
        It's a very strong, plainly stated assertion that contradicts stated goals of the project so it seems like it deserves supporting evidence. Editions exist to avoid breaking code over time.
        • fluffybucktsnek 6mo ago
          Ah, sorry. I got confused about your comment.
  • jagged-chisel 6mo ago
    The code won't magically stop running because the Rust community continued evolving the language. The old toolchains will be available if there's a compatibility change. Where's the problem exactly?
    • ShyCodeGardener 6mo ago
      Probably just depends on what you are doing. Library support could move forward and new features / security updates for libraries that are not part of core Rust could possibly be an issue if they don't work on older versions. Might not matter for a lot of embedded, but if you are doing something like exposing functionality via a webserver or something that would be network-connected, then security updates in third-party libraries may be important. For example, it would be really easy for me to run old code that's pinned to something like Python 3.7, but if libraries have updated to Python 3.x without backwards compatibility, then I'm stuck using the out of date versions or just backporting myself.
  • lawn 6mo ago
    Are you implying Rust will stop working or something?
  • estebank 6mo ago
    Can you point at any piece of code from 5 years ago that doesn't work today?
    • oytis 6mo ago
      I only tried Rust for small hobby projects, but I did experience weird code rot when you just leave the code there and after a while it does not compile. Might have something to do with how Cargo manages dependencies
      • Aurornis 6mo ago
        > Might have something to do with how Cargo manages dependencies Build against the lockfile to use the same versions. Unless they were pulled from upstream, they won’t suddenly stop building against the same compiler version. Rustup makes it easy to switch compiler versions to get back to the same one you used, too.
        • estebank 6mo ago
          Even if a crate is yanked, if you have the version in a lock file it will still download and build. (This was done precisely after seeing the left-pad incident.)
          • tredre3 6mo ago
            I'm sure you have ways to entirely purge a crate. And the situation will arise that you need to do so. In which case all the old code will, indeed, break. Vendoring is the only solution to this but it's really discouraged in rust-land and there is no first-party support for it. You can kind of manually vendor your deps with cargo, and there are third party tools. But compare that to go-land where `go mod vendor` gets you 95-100% of the way there.
            • kibwen 6mo ago
              > I'm sure you have ways to entirely purge a crate. No, the lesson from left-pad that every centralized package manager learned was that you cannot allow users to remove uploaded packages at their leisure. All outright code removal can only be done manually by the admins themselves, and it's unlikely to happen outside of some legal compulsion. > Vendoring is the only solution to this but it's really discouraged in rust-land and there is no first-party support for it. This is completely incorrect. Cargo ships with `cargo vendor` out of the box, it's neither discouraged nor unsupported by first-party tools: https://doc.rust-lang.org/cargo/commands/cargo-vendor.html https://doc.rust-lang.org/cargo/commands/cargo-vendor.html
  • whiatp 6mo ago
    I'm curious what the concern is with the rust editions mechanics in place. Each crate gets to define the language edition it is compiled with. Even if dependencies up convert to later editions they can still be linked against by crates that are an older edition. As for the broader crate ecosystem, if crates you depend on drop support for APIs you depend on, that could cause you to get stuck on older unsupported releases. Though that is no different of a problem than any other language.
  • IshKebab 6mo ago
    Rust is much more stable than C in my experience. Try compiling a decade old C code and see how that goes...
    • irishcoffee 6mo ago
      How do you figure? I do that weekly.
      • JoshTriplett 6mo ago
        I've often found that trying to compile decade-old C code with a current toolchain and current libraries will have issues. It isn't always clear what versions the code is expecting (no equivalent to a lockfile), newer C compilers or standards can break old code, and newer libraries especially can break old code. It might still build if you could recreate exactly what it expects, but it becomes decreasingly possible to do that if you weren't compiling it a decade ago and archived off exactly what worked then.
  • Aurornis 6mo ago
    > 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 switching to an older Rust tool chain to build something than all of the games we played to keep entire VMs archived with a snapshot of a vendor tool chain that worked to build something.
    • whiatp 6mo ago
      I remember a coworker having to fight with an old platform's build not working because our user/group IDs were bigger than 2^16. I can't remember which utility was causing the problem, I'd have to guess tar. This is when we learned to play the archive a VM game.
      • butvacuum 6mo ago
        I can't imagine theres much overlap between "we will need to update this firmware for the next decade." and "Let's bet the farm on the documentation being perfect, and all the downloads still available."
      • cyberpunk 6mo ago
        I know a defence company that has a bunch of vaxes stored in low oxygen environments because they legally have to be able to provide software updates to firmware they’ve written for the next 20 or so years and it was written on a vax. They had some great stories trying to get something or other running again where they had to fly one of the original designers over to hand solder a board back into action. How we do that today is a bit of an interesting problem I don’t think they’ve convincingly solved; basically maintaining nightly builds forever — a couple 1U’s of kubernetes in deep storage ain’t gonna do it, you’re not gonna be able to solder a xeon back to life.. I know I’d rather be trying get a load of c99 rebuilt for some mips or other after 20 years that some random version of rust.
  • xandrius 6mo ago
    Wait, are you implying that code written in Rust somehow "rusts"?
    • estebank 6mo ago
      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.
      • mananaysiempre 6mo ago
        Stretch or not, MDAC can no longer be installed on Windows. (The Microsoft Data Access Components are a rollup of database interface libraries from when they seemed to do around one a year, to the point that Spolsky remarked on it[1].) This means a significant corpus of old but still 32-bit line-of-business apps no longer runs, like anything written in VB6 or VBA that needs to access a database. [1] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
  • kitd 6mo ago
    Isn't that (part of) the purpose of using something like Ariel OS, to isolate you from changes?
  • api 6mo ago
    I think that was true maybe 5-10 years ago. We have Rust code in a living code base that is more than 5 years old and it's required maybe one touch in the last 5 years to fix some issues due to stricter rules. It was simple enough it could have been automated.
  • vmg12 6mo ago
    > 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.
    • fluidcruft 6mo ago
      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.
      • nine_k 6mo ago
        > using tools and getting proficient with them rather than relearning tools 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.
        • estimator7292 6mo ago
          That's exactly the point. This is not normal even in software. You can, in fact, learn C exactly once. Or any number of other languages. The entire argument being made here is that the world you're suggesting is a problem. Software developers should not have to continually relearn their tools and it is abnormal to suggest they should.
          • dwattttt 6mo ago
            I've seen C written by people who learned it "exactly once", in let's say the 2000s. They're the same people who insist that all the safety & linting introduce since was pointless. I'll take C written by people who've learned and improved since then any & every day of the week.
  • rowanG077 6mo ago
    Rust is evolving too fast? Rust is evolving EXTREMELY slowly. I dare say even slower than C++ or Python.
  • drzaiusx11 6mo ago
    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.
    • jonathanstrange 6mo ago
      That invariably leads to bitrot and low maintainability. It's one among many reasons why I don't use Rust.
      • monocasa 6mo ago
        I don't see how that leads to bitrot, or low maintainability.
      • orochimaaru 6mo ago
        You have the same issue with C, no? C is upgrading versions, compilers have changed, hardware evolves and somethings in the past aren't supported as well anymore.
        • megous 6mo ago
          Not really. Not in the scale of my C dev life, which has been 20 years so far.
          • fluffybucktsnek 6mo ago
            Neither have we with Rust.
          • orochimaaru 6mo ago
            I did C and C++ till about 2010 or so. The major platform which I did dev for (hp ux) is no longer supported.
    • elcritch 6mo ago
  • iknowstuff 6mo ago
    Rust is stable. If you don’t plan on changing crates, newer compilers will compile your 5yo code.
  • Lvl999Noob 6mo ago
    Aren't there companies that still use C89 for their production systems? I don't know any in particular but I have read comments here on HN implying that. Just do the same for Rust. Stick to the one major version you started with instead of trying to update the toolchain regularly.
  • pjmlp 6mo ago
    K&R C, C89, C90, C11, C17, C23, C2y. Not counting compiler specific extensions from GCC, clang, Microsoft, Intel, NVidia, AMD, IBM, Oracle, Apple, Green Hills, TI, Microbit, Mikroe, and many more C compiler vendors that could have been used to compile a specific project during the last 50 years.
• blub 6mo ago
  One of the authors commented below that the “teams” were actually persons and the Rust person was an intern. This is even less serious than the typical pattern of grabbing random students for experiments and then drawing conclusions about the general population.
  • torginus 6mo ago
    Not sure about your life experiences, but every new, from-scratch project I have undertaken has looked like 1-2 or at most 3-4 people on good terms who really pulled their weight, with the rest being basically not dead weight, but the management overhead they caused ate up most of the productivity they brought to the table.
    • blub 5mo ago
      Even if that were the case, working in a team is very different from working solo.