Rust Internals

zackw: > I'm going to call this the "it's not actually hard to stay on the treadmill in Rust, people shouldn't be worried about it" reaction. It doesn't work on anyone who is already worried about it, for the same reason that it doesn't work to try to calm down a small child who's scared of the monster under their bed by assuring them the monster doesn't exist. No amount of assurance that it's easy to check and actual problems are rare will make someone stop being scared of tripping over some breakage that will take weeks to fix and by the time they're done there'll be another release bump and they'll have to do all this validation all over again again and they are never going to get to work on the fun part of this project anymore. Fear is irrational thst is true. I don't think we should make the language measurably worse for everyone else though, by decreasing the release cadence. The child analogy falls apart when it comes to tjr responsiblity: if it is my child I'm willing to go out og my way for them, if it is some random enterprise user who isn't paying or contributing back, dealing with their fear is on them. That said, features like cfgs to check language festures / versions doesn't have much of a downside (depending on how complicated the implementation of it is), so I'm not against that. zackw: > You may be right about this! Does anyone want to pay my expenses to go to RustConf or EuroRust and run another field study on current Rust developers? I will be happy to do this if someone pays my expenses. Me too! I too would like a paied trip. zackw: > Case Rust: Once every six weeks, you need to spend one or two hours reading the release notes, running rustup, and testing your code with the new compiler. That is not a realistic number of hours for that. How it actually works as a hobbyist is that I set dependabot or renovate to create two PR once a month to lift dependencies. One for semver compst deps and one for semver breaking. If it builds and passes automated tests I can merge it. Otherwise I can look at the particular failure (sometimes new clippy lint and I deny warnings. If you don't want to deal with that just don't deny warnings in CI). That is nowhere near "a couple of hours". It might become a couple of hours in the worst case for semver major dependencies. zackw: > This is possible in C not just because C moves so very slowly, but also because C's metaprogramming capabilities are more powerful than Rust's in a couple of critical aspects, especially when augmented by a "configure" script -- it's no burden at all for me to put the handful of C2011 features that are useful to me under #ifdefs because I can trivially express "does this compiler have support for _Generic?" (for example) independently of "does this C library include the function strsignal?" As a hobbyist this isn't something I would aim for. Now I need to write the code twice, once for having the feature and once for not having it. Given my 1-2 hours per week for hobby programming, I'd rather not. Either I use the new way of doing things, or the old. Not both.

zackw: > ... this. If you have limited hours per week to devote to a task, it can easily be less annoying to get a big batch of potentially breaking changes to your infrastructure all at once, than to get a steady trickle of updates. The thing is that if there's a steady trickle of updates, you can get the "big batch" by skipping several updates in a row. This is something I've done in a work context many times - I've still got projects that are on Python 3.7, because it's not yet worth the time to jump to a newer Python. In the Rust context, this would be a case of "I want a big release every year or so, so I'll take minor versions divisible by 10" - 1.60, 1.70, 1.80, 1.90, and I'd be taking one in about 12 weeks to get 1.100. This is where a formally supported LTS can help - if there's enough people making this sort of judgement call, they can agree on which releases they're using, and work together to make that a supported release. You can't do the inverse, however; if I wanted a new Python version every 6 weeks, with a smaller amount of change, I'd be stuck.

programmerjake: > they are already unsound on some targets because some of the fp operations are implemented by changing the rounding mode and then changing it back, e.g. converting float to integer on i586-unknown-linux-gnu without additional target features works by temporarily changing the rounding mode using fldcw to round-towards-zero, converting to an integer using fistp, and then changes the rounding mode back using another fldcw. Oh, interesting. Always exciting to learn about new ways in which the non-SSE x86-32 targets are broken... Vorpal: > What about interrupt handlers or (as Alice pointed out) signal handlers? Do all targets guarantee that FP flags are saved/reset/restored when those happen? I'm pretty surr that isn't the case on embedded ARM at least, but maybe it is on Linux and similar. Yeah I hope they guarantee that, everything else sounds kind of broken. Vorpal: > The fact that this is stateful on most architectures is pretty bad. Yes, global state is bad. Sadly hardware engineers love global state so here we are... Vorpal: > Sorry, i somehow missed the last paragraph of your post. But it doesn't seem feasible to add this (safely) without declaring existing code for interrupt handlers unsound. That doesn't seem compatible with the Rust backward compatibility guarantee. I think it is already generally understood that it's fine to temporarily change the rounding mode in an inline asm block as long as you change it back before returning from that block. So I would argue that any setup where interrupt handlers inherit the rounding mode from whatever previous code that ran is already using a non-standard contract and has to manually ensure that all the code they link in will never change the rounding mode.

burakemir: > This is of course true. However, that notion also used to be called "safety" (e.g. Cardelli's 2004 Type Systems handbook article). The use of "memory safety" seems more recent, and the nuance that these are the same requires a detailed understanding. Indeed "memory safety" is a term with many meanings. I have met people who do "memory safety proofs of Java programs", by which they mean "prove that the program does not throw null pointer exceptions". If we take that definition, a Rust program that panics is also not "safe". I am not aware of any definition of memory safety where Rust would fall in a different bucket than Java. burakemir: > So including concurrency in safety is a real differentiator. I don't think so. Java had safe concurrency since ~forever. In fact, I think Go is pretty much the only language that is often claimed to be safe without being thread-safe (in the sense of a no-UB guarantee for concurrent programs). Swift might fall into the same bucket depending on where you draw the line between the safe and unsafe fragment of the language, though nowadays Swift does have safe forms of concurrency so unlike Go they are at least trying. I agree that Rust does more than Java to prevent concurrency bugs. But the same is true for sequential code, e.g. Rust statically prevents iterator invalidation. So concurrency is not a differentiator here either. I don't think that this difference can be captured by saying that Rust is safe in a sense that Java is not. Rust has a stronger type system, but the additional strength does not manifest in new metatheoretical properties. > If you look at it this way, then among the widely used, modern no-GC languages, Rust does seem to hold a special place. And the claim that it is unique is not all that silly. "no-GC" is doing all the heavy lifting here. All the other no-GC languages are "obviously" not memory safe, as far as I can tell. So yes, I agree that Rust is unique in that it achieves memory safety without a GC. I already said that in my previous post. But there were claims further up this thread which seemed to say that Rust is unique for achieving memory safety at all, and that "memory safety without a borrow checker" would be somehow a new thing. Those are the claims I pushed back against. Your reply now argues for something entirely different.

RalfJung: > Memory-safe languages (in the fairly strict sense of languages without Undefined Behavior) have existed for more than 3 decades (e.g. Lisp, Standard ML, Haskell, Java). This is of course true. However, that notion also used to be called "safety" (e.g. Cardelli's 2004 Type Systems handbook article). The use of "memory safety" seems more recent, and the nuance that these are the same requires a detailed understanding. Language designers have used built-in GC to elegantly avoid problems for a long time. However, concurrency was not as developed in all these languages. Multi-core CPUs became widely available only after 2005. So arguably, the "space of language designs" changed. And with that, the scope of what "safety" means changed as well. Of course I am on the same page with respect to "no memory safety without thread safety." Yet, people may disagree, and not only out of ignorance. Someone who wants to claim that go is memory safe has reasons to prefer talking about single-threaded [memory] safety. And that notion matches what safety meant before 2005 and is enough to "beat" C and C++ in terms of safety guarantee. So including concurrency in safety is a real differentiator. If you look at it this way, then among the widely used, modern no-GC languages, Rust does seem to hold a special place. And the claim that it is unique is not all that silly.