141–150 of 172 posts
Earlier quoted context omitted.
> 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.
Why, given the existence of editions?
Editions exist to avoid breaking code over time.
Earlier quoted context omitted.
You could do (it is simple), but all the code is stored on crates.io so there's no real need. An exception is for crates that wrap C code which might get the code from elsewhere but those are quite rare.
And they’re immutable, forever? No one can pull a leftpad?
Earlier quoted context omitted.
And they’re immutable, forever? No one can pull a leftpad?
Yes, they are immutable. It's only possible to "yank" a specific version, which will prevent new dependencies, but it will still be available for download for existing dependencies. https://doc.rust-lang.org/cargo/commands/cargo-yank.html
Earlier quoted context omitted.
> You can still use the same old toolchain. Unless you find out the compiler was buggy and was producing faulty binaries, but the new compiler can no longer compile the old code.
What you are describing happens all the time. Usually the toolchain provider will continue updating a list of known issues for some time after EOL. Beyond that you have third parties that do it for decades, if the platform is big enough. They collect bug reports from the industry, investigate them, then create lists that you subscribe to. Those lists include detailed examples, explanations, and usually linter rules t…
This reaction to toolchain stability is quite defensive, and was needed for C, but isn't universally needed. C toolchain updates could break your product because of how loose the C language can be; I've had code that had benign undefined behaviour, until a toolchain update brought in an optimisation that broke it.
Another outcome of a toolchain update could be "no bugs introduced, existing bugs in your codebase now found by diagnostics".
Earlier quoted context omitted.
Strip_suffix won't break with new compiler versions. Anything explicitly imported takes precedence over the prelude, or else everything is a breaking change and would have to wait for an edition.
https://rust.godbolt.org/z/4bsb91Krf is code which calls our strip_suffix in 1.40 Switch to Rust 1.50 and now it's calling the stdlib strip_suffix silently, I actually wasn't expecting it to be silent, and obviously if they have the same exact behaviour (mine instead panics to show we're calling it) you wouldn't even notice, but it is a change.
But on the other hand, it could be a bug as the trait resolver is commonly mentioned as the buggiest part of the language. I'm scared of the breakage if they fix it though.
Authors are from STMicro, polytechnic Turin, Freie universitat Berlin, and Inria. Examined writing firmware for an IOT sensor platform. From the abstract: > Two teams concurrently developing the same functionality (one in C, one in Rust) are analyzed over a period of several months. A comparative analysis of their approaches, results, and iterative efforts is provided. The analysis and measurements on hardware indica…
This is even less serious than the typical pattern of grabbing random students for experiments and then drawing conclusions about the general population.
Earlier quoted context omitted.
https://rust.godbolt.org/z/4bsb91Krf is code which calls our strip_suffix in 1.40 Switch to Rust 1.50 and now it's calling the stdlib strip_suffix silently, I actually wasn't expecting it to be silent, and obviously if they have the same exact behaviour (mine instead panics to show we're calling it) you wouldn't even notice, but it is a change.
Oh, wow. I am wrong. So much of the rust community must be wrong as this is commonly mentioned when discussing breakage. This is awful. But on the other hand, it could be a bug as the trait resolver is commonly mentioned as the buggiest part of the language. I'm scared of the breakage if they fix it though.
So we didn't bring str::strip_prefix from the prelude in preference to our custom trait, we made a string literal and those have type &'static str -- an immutable reference to a string which lives forever. So the "prelude doesn't win" rule does not apply for &str because it didn't come from the prelude.
If we were talking about a type which implements Iterator for example, new Iterator features would come from Iterator, which is in the prelude and you didn't specifically ask for Iterator so the things you did ask for beat Iterator. But here the language primitive type grew new methods, a thing which Rust does but many languages don't do - Rust has methods on pointers and bytes and anything, whereas a language like Java or C++ can only put methods on "classes" not the ordinary types.
Earlier quoted context omitted.
> 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.
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.
I'll take C written by people who've learned and improved since then any & every day of the week.
Earlier quoted context omitted.
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 th…
> 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. Rust 1.0 is 11 years old and it's still trivial to compile Rust code from then. I doubt that will change in the next 9 years. C is an absolute nightmare in comparison. I tried to compile some old C code I had for Nordic nRF51 chips, only a few years after the chips became available. I gave u…
https://github.com/sshine/dikumud/commits/master/
It wasn't plug-and-play.
My guess is that when Rust code gets 30 years old, the problem would more likely be that you can't find an already compiled compiler that will work for that old code, and that the compilers themselves need bootstrapping. So you'll just fast-forward the code to work on a new compiler instead.
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…
If the toolchain moves on, the product is suck on whatever architecture and developers are stuck running an emulator/docker of some particular vintage of Debian sid.