Let's assume your C SDK defines MY_GPIO as a pointer to a volatile memory mapped I/O register. Lets further assume that your project uses interrupts (or preemptive multitasking).
Your trivial one-liner is an example of terribly seductive simplicity enabled by a broken design. It works until MY_GPIO is concurrently modified. Which can happen if the memory mapped peripheral changes the register content on its own or if other code can preempt read/modify/write sequence. To make it worse unless MY_GPIO is heavily contested it will work most of the time.
I'm not familiar with embedded Rust, but it looks like APIs are designed to make the programmer explicitly lay claim hardware peripheral (or fail trying) instead of corrupting the system state. Most of the unwrap() and unsafe code is executed once during setup. Once the hardware resources are divided up and configured the normal runtime code should be a lot less verbose (from a quick look at the API documentation).
Your trivial one-liner is an example of terribly seductive simplicity enabled by a broken design. It works until MY_GPIO is concurrently modified. Which can happen if the memory mapped peripheral changes the register content on its own or if other code can preempt read/modify/write sequence. To make it worse unless MY_GPIO is heavily contested it will work most of the time.
I'm not familiar with embedded Rust, but it looks like APIs are designed to make the programmer explicitly lay claim hardware peripheral (or fail trying) instead of corrupting the system state. Most of the unwrap() and unsafe code is executed once during setup. Once the hardware resources are divided up and configured the normal runtime code should be a lot less verbose (from a quick look at the API documentation).