3 ms·

"As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself

"As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving. I know the friction is greater because I am still a Rust learner, not a veteran, but I think this experience stops a lot of new comers, speaking as someone who already conquered the uncomfortable syntax of Rust, coming from a C/C++ background." To be honest, this article seems somewhat ingenuous. The author wasn't comfortable with Rust, and it seems like he missed the point of the borrow checker. This article will now be circulated whenever Rust is discussed. Here is a good article that arrives at the opposite conclusion: https://kyren.github.io/2018/09/14/rustconf-talk.html https://kyren.github.io/2018/09/14/rustconf-talk.html I've been writing Rust full time for the last month and a half or so and the language is a joy to use. The main difference is that the code I write feels very sturdy and permanent. I've heard other people say the same thing.

nraynaud 8y ago
XML didn't work? use more XML. Everybody has a breaking point, and they reached theirs. I have been studying rust for embedded since January and I am not really impressed by what I have seen. I am mostly hacking around the deficiencies of the libraries, the crazy organisation of the stack, and the issues with the community. I am sticking with rust for now because I feel like there is a bandwagon and there might eventually be money in it, but I am certainly not a convert.
- adamnemecek 8y ago
  > XML didn't work? use more XML. Everybody has a breaking point, and they reached theirs. This argument could be applied to anything. What's crazy about Rust stack organization? What are the issues with the community?
  - nraynaud 8y ago
    Basically you have some kind of hierarchy of crates according to the abstraction level, and those crates are owned by some loose organisation. The trick is that the those crates are new and there is only very few MCU features exposed in them (and modern MCUs are so "big" that there is no real hope to get out of the situation quickly), so when you're doing a project, you either have to send a PR upstream and have it die there immediately or argue for days before it dies, or you have to fork the crate yourself. I couldn't find a way to add code in the namespace of a crate without actually re-compiling it. It was extremely naive to split the crates horizontally and have only a limited group of people able to access the register they want to use, and not expose some kind of extension mechanism. some examples: STM32F103 doesn't expose DMA, there is no provision for async SPI, no provision for changing the speed of any communication device (nor any bus for that matter). Which we could attribute to the thing being new, but drivers are already being written in such a way that thing are getting calcified like that, and the task of exposing all the functions of the MCU in rust is infinite, it has to be open to outsiders and that involve having a different slicing of API, and always making sure that from any configuration we can call release().
  - sanxiyn 8y ago
    There are lots of issues with using Rust for embedded development, most of them long standing, which are often felt to be neglected, and some suspicion that progress is slow because it is not the highest priority for decision-making people. https://github.com/rust-embedded/wg/issues/64 https://github.com/rust-embedded/wg/issues/64 details some of these technical issues. Personally issues with Cargo are the most pressing, and math/compiler_builtins is very annoying.

nraynaud 8y ago

XML didn't work? use more XML. Everybody has a breaking point, and they reached theirs. I have been studying rust for embedded since January and I am not really impressed by what I have seen. I am mostly hacking around the deficiencies of the libraries, the crazy organisation of the stack, and the issues with the community. I am sticking with rust for now because I feel like there is a bandwagon and there might eventually be money in it, but I am certainly not a convert.

adamnemecek 8y ago
> XML didn't work? use more XML. Everybody has a breaking point, and they reached theirs. This argument could be applied to anything. What's crazy about Rust stack organization? What are the issues with the community?
- nraynaud 8y ago
  Basically you have some kind of hierarchy of crates according to the abstraction level, and those crates are owned by some loose organisation. The trick is that the those crates are new and there is only very few MCU features exposed in them (and modern MCUs are so "big" that there is no real hope to get out of the situation quickly), so when you're doing a project, you either have to send a PR upstream and have it die there immediately or argue for days before it dies, or you have to fork the crate yourself. I couldn't find a way to add code in the namespace of a crate without actually re-compiling it. It was extremely naive to split the crates horizontally and have only a limited group of people able to access the register they want to use, and not expose some kind of extension mechanism. some examples: STM32F103 doesn't expose DMA, there is no provision for async SPI, no provision for changing the speed of any communication device (nor any bus for that matter). Which we could attribute to the thing being new, but drivers are already being written in such a way that thing are getting calcified like that, and the task of exposing all the functions of the MCU in rust is infinite, it has to be open to outsiders and that involve having a different slicing of API, and always making sure that from any configuration we can call release().
- sanxiyn 8y ago
  There are lots of issues with using Rust for embedded development, most of them long standing, which are often felt to be neglected, and some suspicion that progress is slow because it is not the highest priority for decision-making people. https://github.com/rust-embedded/wg/issues/64 https://github.com/rust-embedded/wg/issues/64 details some of these technical issues. Personally issues with Cargo are the most pressing, and math/compiler_builtins is very annoying.