> I wouldn't call Rust difficult to learn

I agree with this too.

This is because you know what Rust brings you compared to what you used in the past that cause you pain.

Unfortunately, some people that have difficulty learning Rust (or hear about it) focus solely on the learning process and not what they gain by learning it.

Learning a low-level language is inherently hard because there are more at stake, it is simply more complex. For people that work where dangling pointer, data-races, is never a problem, they are learning about the problem the same time they are learning about the solution (Rust's ownership concept), and I came from that place too.

> Or, look at embedded, where C is considered a simple language. In C, it's not obvious how I'd start. Use something like Cube-MX or Keil? GCC? All the options are messy and tough to learn. In Rust, I clone a template repo, cargo-install 2 or 3 tools and targets, and `cargo run` to compile and flash.

Keil is a company that builds an IDE, compiler and debuging tools for microcontrollers. CubeMx is a configuration tool/code generator for STM microcontrollers. You comment makes no sense in regards to C language, unless you are saying that rust/cargo automagically does everything that Keil products and CubeMx do?

Correct:

- `cargo install probe-run`

- `rustup add `thumbv8m.main-none-eabihf`

- `git clone some-template`

- `cargo run`

Wait, these 4 commands create an IDE with with JTAG debugging support, tracer and a profiler and than configure all the chip's peripherals, add low level drivers (UART, SPI, USB, FS, I2C, ETHERNET,...), setup clocking and power settings and add RTOS? I took Keil probably decades and STM years to write all that complex tooling. I'm mean it probably takes an engineer a month to bring new HW to life with the help of all those tools before they can start writing application firmware. Are you really saying 4 lines of rust tooling do the same in couple of seconds? That would be some amazing AI behind those 4 lines.

Those lines let you compile, flash, and debug. For IDE, I prefer the IntelliJ Rust plugin. Some people prefer VsCode instead. The point here is that you choose an editor suitable to the language, with the code-editing and project-management features you like.

Low level drivers are usually handled using libraries of 2 general categories: Peripheral access crates (PAC) (mostly) auto-generated from SVD files; HALs that provide an abstraction over the PAC.

A month to get started sounds... intense, depending on the project. What drove (drives?) that? Let's say I want to do a simple project using STM32. Something simple that reads sensors, has a few buttons, and outputs to a display. I'd choose parts, put together a layout in a PCB design software, and order the boards, which arrive within 2 weeks. In the meanwhile, use a dev board as required. Find a driver for the sensor, screen etc if it exists. If not, write them using the datasheet. Use a HAL to take configure clocks and peripherals, write the control flow logic (Perhaps based on interrupts). For anything the HAL doesn't support, use the Reference Manual and the PAC to set the appropriate fields.

Setting up I2C might be something like this, using a HAL:

    let mut scl = gpiob.new_pin(PinNum::P6, PinMode::Alt(AltFn::Af4));
    scl.output_type(OutputType::OpenDrain, &mut gpiob.regs);

    let mut sda = gpiob.new_pin(PinNum::P7, PinMode::Alt(AltFn::Af4));
    sda.output_type(OutputType::OpenDrain, &mut gpiob.regs);

    let i2c = I2c::new(dp.I2C1, I2cDevice::One, 100_000, &clock_cfg, &mut dp.RCC);

The only thing that I did for STM32 was writing drivers for dual FLASH quad SPI external memory. Since I didn't know much about STM32 and there was no sample driver for the flash chip I was using, CubeMX helped quite a lot. It still took me a good week to get it working.

Usually when developing a new platform for our products, I/we need to bring to life: SDRAM, LCD, touch controller, external flash for code and data, SD card + FAT32, USB, ETH, plus a bunch of other components (ADC, DAC, BT, other uC, latches,...) using the usual peripherals (UART, SPI, I2C, timers,...). Keil provides a good compiler and linker, fast JTAG debugger, RTOS and a bunch of middleware libraries (some are quality, some are lacking). While I dislike its IDE for writing code, it is a lot better than VS code for debugging purposes. It also supports flashing and erasing MCUs with internal and external memory, which sometimes requires special programming algorithms.

For us stability, tooling and good library support is the most important part of doing our job. Language follows from there. C and C++ have the advantage of the GNU/Linux ecosystem of open source to draw from and they map to the hardware almost perfectly. On higher level systems (Android, Linux) we use higher languages (with GC) which have even nicer tooling and better libraries for writing application code.

Nice. It sounds like the time sink there is writing drivers for a range of peripherals. The silver lining is next time you use that periph, it's easier.

C/C++ and Rust are both hard IMHO. D is way easier, one gets productive quite fast and there are also more advanced language features once you get proficient in it, unlike Go.