nrf-hal VS chirp8-engine

You should try again. I think that code is verbose because of the borrowing and because you're trying to do a one-liner. I use the nrf-hal library with the nrf52840, and the code reads pretty nicely. Here's an example:

https://github.com/nrf-rs/nrf-hal/blob/master/examples/blink...

Reading nrf-hal source, unfortunately new does re-configure the UARTE, and there is not a new_unchecked. The solution I can think of is to duplicate the write code with nrf52833_hal::pac::UARTE0. The Uarte type does not contain any metadata, it exists purely to guard the init of UARTE.

Really good. Check out the examples in the nrf-hal repo. Also, if you don't mind forking out for some extra components the Knurling sessions by Ferrous Systems are ace.

The embedded HAL crates do this with extensive use of macros, for example: https://github.com/nrf-rs/nrf-hal/blob/aae17943efc24baffe30b...

This solution makes sense given the constraints of Rust, but there's quite a cost in terms of compiler time and cognitive overhead to understand what is going on.

(Aside: I didn't use the HAL in my Rust firmware, that's a higher layer of abstraction; I only used the PAC crates.)

The value add is not in the parts that interface with the C64 internals; probably using C for that would make for nicer code. But I wanted to push as much into Rust as I could in the short amount of time I spent on this.

The real advantage of using Rust is in the actual program logic. E.g. the instructions are decoded into an algebraic datatype (in https://github.com/gergoerdi/chirp8-engine/blob/7623353a8bf0...) and then that is consumed in the virtual CPU (https://github.com/gergoerdi/chirp8-engine/blob/7623353a8bf0...). Rust's case-of-case optimization takes care of avoiding the intermediate data representation at runtime.