4 ms·

I wouldn't call Rust difficult to learn. The syntax quirks (Knowing where to put `&` etc takes time, and traits are abstract, but used all over Rust codebases).

I wouldn't call Rust difficult to learn. The syntax quirks (Knowing where to put `&` etc takes time, and traits are abstract, but used all over Rust codebases). For example: Look at Python which is typically considered easy to learn. In Rust, I know that I can create a project using official tooling; specify dependencies cleanly in `Cargo.toml`; use the built-in linter, and formatter. Check the Rust docs page for any dependencies, including type signatures for all functions, and a list of struct fields. Look in the `examples` folder of a dependency's repo for code snippets. In Python, I'm likely to find a comparative mess of sparingly-documented documented third-party tools, dependency docs, and Stack Overflow posts. 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.

petre 6y ago
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.
valand 6y ago
> 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.
nec4b 6y ago
> 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?
- the__alchemist 6y ago
  Correct: - `cargo install probe-run` - `rustup add `thumbv8m.main-none-eabihf` - `git clone some-template` - `cargo run`
  - nec4b 6y ago
    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.
    - the__alchemist 6y ago
      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);

petre 6y ago

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.

valand 6y ago

> 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.

nec4b 6y ago

> 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?

the__alchemist 6y ago
Correct: - `cargo install probe-run` - `rustup add `thumbv8m.main-none-eabihf` - `git clone some-template` - `cargo run`
- nec4b 6y ago
  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.
  - the__alchemist 6y ago
    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);