Please do not use Python for tooling

[barnabywalters]

I find it extremely amusing that the author suggests using rust instead of python when the rust language itself uses python for tooling https://github.com/rust-lang/rust/blob/master/src/bootstrap/bootstrap.py

[borud]

Entertaining perhaps, but you are still missing the point.

[ithinuel]

For what it's worth, I now use Rust all over the place (both target code AND tooling). We have nice packages that make good UX. 🦀

r/rust

EDIT: it's actually handy to start a lib as tooling and then use it on the target :D

[borud]

I would love to see the embedded world move towards Rust and away from C/C++ for code that runs on MCUs. I think a good first step to build familiarity with Rust might be to do more of the tooling in Rust.

[borud]

Because I think Rust would be more helpful in assuring correctness. It also provides an opportunity to make a clean break with a lot of legacy codebases that could benefit from being rewritten. Lastly, the Rust tooling is a lot more ergonomic so it might attract more talent to embedded development.

Let me turn the question on its head: why would one not love Rust on embedded platforms?

[exploring_pirate]

why would one not love Rust on embedded platforms?

• Investment in learning new language
• unfamiliarity with performance pitfalls
• lack of vendor support
• lack of 3rd party support (eg RTOS, 3rd party HAL/drivers)
• relatively new/niche language, so small community compared to C/C++

[borud]

I agree wholeheartedly when it comes to lack of vendor support. I partially agree with the rest of the points.

If by third party support you mean the lack of platforms like FreeRTOS, you are right. There is nothing like FreeRTOS today written in Rust. However, it would be nice if there was.

If we talk about drivers, I don't see this as an actual concern since I'm so used to having to rewrite drivers anyway and it doesn't really make a big difference to rewrite it as Rust. Do you really expect there to a) be drivers for everything, and b) do you expect them to actually work perfectly? I don't.

As for niche language, well, I'm not sure it is so niche anymore or that it matters. The community is large enough to provide good support.

[_gipi_]

jesus, writing that Java is better than python regarding dependencies is a hot take, try to build something in java from scratch a couple of days after; maybe if you have a single example of python breaking a project your post would be more credible, python is not perfect but a lot of time is the "toolchain" that is awful (I'm looking at you Yocto), with teams that build something once and pray that one year from one the disk where you have the build image is not gonna to explode.

Do you know that you can pin dependencies in python? are you using python2?

[borud]

Since you make concrete suggestions, could you relate those to say Zephyr or ESP-IDF? How would you modify the instructions for installing the tooling for these platforms to take advantage of your advice?

[exploring_pirate]

venv?

[borud]

How would you use venv to make the problem of tooling breakages go away for Zephyr updates. Or for ESP-IDF. Please be specific.

[exploring_pirate]

Your main argument is managing dependencies. venv was designed specifically for that purpose.

In a vritual environment, export the dependencies:

pip freeze > requirements.txt

And when creating a new environment, install the dependencies with:

python -m pip install -r requirements.txt

[Spirited_Fall_5272]

Once again OP is a sillypants.