There's a great talk [1] in which C++17 features are used to build an efficient Pong clone on C64. As I recall, the author wound up writing an (obviously limited) x86-to-6502 translator to get around the lack of 6502 support.
FWIW: really the best example of that kind of thought was OSS's "Action!" language for the Atari computers. Unlike all the modern ideas in this space, this was actually a contemporary product (released in 1983). It's a little like K&R C in terms of semantics, with a bunch of concessions[1] to the limitations of the device.
Alas it came at a time in history where it couldn't make much impact. The Atari platform was being eclipsed by Commodore at the time, and the market for Serious Tool Development in the desktop world was swinging hard toward IBM (Turbo Pascal for MSDOS was arriving right about the same time).
[1] Like a more pascal-ish syntax. Atari didn't have curly braces on its keyboard! Also IIRC "POINTER" types were limited to being statically linked into the zero page, as that matched the operation of the hardware without requiring the runtime to move stuff around for you every time you wanted in do a load.
Not the Atari itself, which never had a C compiler. But systems like that, yeah. Lots of 70's systems were designed for non-ASCII or ASCII-subset[1] character sets, whereas Unix had made very comfortable use of every funny symbol it could find.
[1] e.g. the original Apple II character ROM had only the 64 characters from 0x20 to 0x5f (no lower case, even) squished into 6 bits of addressing. The keyboard reflected that limitation, as did those from Atari and Commodore. This wasn't rectified by Apple itself until the IIe, though there were 80 column cards on the market from 1980 on that implemented the full
CC65 is just not a very good compiler by modern standards. There's an experimental 6502 backend for LLVM that outputs fairly good code. (A Z80 backend also exists, AIUI.)
The "floating point" support that's in 6502 BASIC ROMs is not real IEEE 754 floating point though, see https://en.wikipedia.org/wiki/Microsoft_Binary_Format So it shouldn't be used to replace that, though of course one can use it for other purposes with some care. (It goes without saying that this is not hardware floating point, so the only potential gain from piggybacking on these ROM routines will be some saving in code size.)
The people old enough to want to program on the c64 are not the same group of younger hipster who want to rustify the world. It would take someone to bridge these groups.
Yup, it's fun to think that the rust_embedded ecosystem could be repurposed with comparable ease to support bare-metal retro programming. Similar to how Rust itself bridges the "low-level C/C++" and "hipster high level language" worlds.
I hope there is one for more advanced ones such as PS (which already have great doc) and GBA (again good doc already) and such.
Sadly computing has advanced so much that making games on console is far from the older days when programmers need to be smart to think out of box to do stuffs. I guess maybe Switch is closer?
https://www.xtof.info/coding-c-8-bit-6502-cpu.html