So, you use Arch. You’re used to everything being “bleeding edge” and “just working” as long as you follow the almighty ArchWiki, right? Wrong. The moment you decide to develop for a standard ESP32 or ESP32-S3 in Rust, you’ve effectively opted into a specialized form of digital torture. Because the Xtensa architecture isn’t in the upstream LLVM, you can’t just pacman -S rust and call it a day. You are forced to use espup to install a bespoke, fork-of-a-fork toolchain that bypasses your beautifully maintained system packages and dumps a massive, opaque blob of binaries into your already fucking bloated home directory. Zou’re no longer building a clean system, you’re hosting a parasitic ecosystem of LLVM forks that don’t know your $PATH exists and you need to run a fucking script every time you want to do anything useful.
The dependency hunt on Arch is particularly ironic. You likely have the latest version of everything, which is exactly what the ESP-IDF build system hates. You’ll find yourself wrestling with pkgconf, openssl, and libusb because the build scripts are expecting specific, older paths or versions common in the Debian world. Then there’s the python-venv requirement. The ESP-IDF insists on creating its own virtual environment during the build process, often getting into a fist fight with updates from Arch repositories.
Actually building a project is where the “bleeding edge” meets the “brick wall.” If you’re going the std route, cargo build isn’t just a command, it’s a commitment to heat your room with your CPU for the next fifteen minutes. Because it has to compile the C-based ESP-IDF from source and link it to your Rust code, you’re basically running two build systems in a trench coat. One minor change to sdkconfig and you’re back to square one, watching thousands of lines of C code scroll by while you contemplate why you didn’t just buy a RISC-V based ESP32-C3 that actually supports standard Rust targets.
Finally, there’s the “hardware handshake” You’ve survived the toolchain, the dependencies, and the glacial build times, only to have espflash fail because your user isn’t in the uucp group or some obscure udev rule is blocking the USB-to-UART bridge. Back in the terminal, fixing group permissions, all to see a LED blink SOS sequence. It’s a specialized kind of hell that only an Arch user could appreciate - a perfectly optimized system running a completely unoptimized, fragmented mess of a development environment. But hey, at least my LED controller is memory-safe.