> Last I asked anyone writing rust "for fun" - the answer I got was "latest compiler/features/shiny or GTFO" Funny. I skimmed the changelog for all the changes

> Last I asked anyone writing rust "for fun" - the answer I got was "latest compiler/features/shiny or GTFO" Funny. I skimmed the changelog for all the changes since that version of Rust, and the only change that looked like it might be must-have is the the one that stabilized inline assembly. The Rust language has matured to the point that it is fine to pick up new compiler versions as lackadaisically as other languages (e.g., C++). > Compare to C89 code that will happily build on any C compiler of any vintage on any system you dig up anywhere, even those that are big endian, have non-8-bit bytes, or are not 2s complement. Actually, a lot of C89 code is likely to get hung up on pointers being 64-bits instead of 32-bits. While it is possible to write C code that works on non-8-bit-bytes or not-2's-complement machines, it is easy to write code that is not robust to such assumptions. Furthermore, C programmers--especially older vintage--have this nasty habit of assuming that they're writing only a thin veneer over assembly code, which tends to cause portability issues if they're making very architecture-specific assumptions, not to mention issue when it turns out that the behavior they think is happening is actually undefined and the more powerful modern optimizers make it do something completely different. Oh, and I can think of two features in C89 which are no longer supported by modern compilers. And neither of them are trigraphs.