4 ms·

Without numbers and sensible tests that allow us to compare this in a systematic manner, neither of your manage to make a strong case for your position. That b

by bborud 3y ago

Without numbers and sensible tests that allow us to compare this in a systematic manner, neither of your manage to make a strong case for your position. That being said, my professional opinion is that Python on MCUs is a dead end. The only attraction I can see is that people who aren't comfortable with C have an easier time programming microcontrollers. And to be very direct: I really, really would not hire someone who is uncomfortable with C to program MCUs. I think Rust is the right direction to move in for MCUs. Low power devices are getting faster and now have more RAM, Flash and onboard goodies. That means they are going to do more stuff and more sophisticated stuff. They'll get more "responsibility". Which means that more will be asked of programmers in an industry that isn't exactly known for good software design. Rust is a step towards better helping programmers write better software. It is a step towards helping developers write software with much larger footprints and deal with project scale. It has a compiler that can help you and there are more and more tools that help you verify code for correctness. This is important when you a) write code for a constrained environment and b) write code that may interact directly with the physical world. This is the _opposite_ of going in the direction of Python. We don't need less rigor and discipline. We need a lot more rigor and discipline. We also need better tooling. C/C++ compilers are stuck in the past and make for brittle and messy build systems. The fact that Python is often used to automate embedded SDKs and RTOS doesn't exactly make things better. A lot of time is wasted every year on trying to deal with the fact that Python isn't a compiled language and thus keeps breaking whenever some configuration changes. Python isn't even suitable for writing stable tooling. Rust has much better tooling. I don't doubt that there are people who are happy with micropython. Good. Go be happy. But it is not what the industry needs (or even uses) for embedded development.

markhahn 3y ago
it's funny that when "discipline and rigor" is advocated for, the underlying premise is basically "pain builds character".
- bborud 3y ago
  Quite the opposite. You can essentially choose what kind of pain you want. On one hand you can have the pain of having to work with a compiler and toolchain that aims to eliminate problems early by requiring you to be more consistent and more correct. On the other hand you can choose to deal with the pain later - as your errors and inconsistencies come back to haunt you later. Or if you are a professional: have to invent your own consistency and error checks through extensive testing. Not that I would expect rigorous test from someone who chooses to avoid compilers that can help them write higher quality code. It is a lot more painful to have to deal with errors later, than it is to deal with them as you write the code. Not least in terms of financial pain and risk. For a lot of embedded systems "just updating the software" isn't always easy, it usually carries significant risk, and it isn't always even possible depending on how something is deployed. Or to express the above with fewer words: you can choose between pain now and pain later. As for tooling: using an interpreted language like Python means that it will only work for as long as the runtime environment is in a particular state. That all the right libraries are available in the right versions, and even the language runtime itself. Thousands upon thousands of files splattered across your filesystem. Every update of any part of the environment risking you suddenly have to spend days figuring out how to get things to work again. Brittle toolchains are a pain. Don't waste time on things that lead to brittle toolchains. I see a lot of hobbyists downplaying this online. I don't see a lot of people who work on this full time downplaying it. Be it people I know at MCU manufacturers who have to support customers or companies that manufacture devices and have large teams of embedded developers who regularly have to waste time because every new release means weeks of getting builds to behave somewhat predictably and reproducibly. Having more modern compilers and tooling that can be relied upon isn't about more pain. It is about considerably less pain. If dealing with a compiler that is strict is too much pain for you, then embedded programming probably isn't for you. Because having lax compilers (or no compiler) means you'll learn about your mistakes when it is quite possibly too late to do anything about them. C/C++ are not very nice languages if you want to ensure quality. Python gives you a sense of productivity over C/C++, but it provides no added benefit in terms of quality and de-risking. Rather the opposite because even the meager discipline a C/C++ compiler gives you is more than what Python gives you.
pjmlp 3y ago
Fortunely there are lots of companies out there in the industry, many of which have more open minded folks regarding what toolchains to use. Those that decide to be stuck in C, might one day wake up and realise the world has moved on without asking for permission.
sgt 3y ago
I think the jury's still out on whether Rust will make it long term. Even if all the technology checks out, the project can easily be mismanaged into the ground. We've already seen hints of that. Outside of C/C++ and Rust (seeing that MicroPython is irrelevant, as per your comment), what other options will be viable going into the future?
- bborud 3y ago
  You are probably right about Rust: it has challenges that seems to make a lot of people want to keep it at arms length. Viability isn't just about technical fitness, but also about momentum, community size, pace and having sensible "taste makers" that teach the community good design and programming practices. At the moment I don't see any viable alternatives. Rust has a good sized community AND people have been working on embedded use of it for many years already. It took a lot of work to get there. For an alternative to be viable it would have to achieve at least what Rust has achieved so far. What will ultimately determine if Rust becomes the new go-to language for embedded programming is the community forming around embedded Rust projects. Ruby is a good example of the power of a community trying to solve a given problem. I think Ruby would not have made it if it were not for Rails. Ruby started out as an interesting language with an atrociously bad runtime and ratty standard library. Yet it Rails had a community that vastly outperformed the qualities of the language/runtime it was based on. Perhaps embedded programming is where Rust will ultimately make such a huge difference the application of Rust becomes greater than Rust itself. Perhaps a Rust based RTOS, and a sensible approach to how embedded software is structured, modularized, and designed may be the thing that becomes greater than the language itself?
- brianhorakh 3y ago
  Linux & Microsoft win 11 both support native drivers in rust. Rust is a great (possibly best) way to build wasm. Wasm is extremely powerful. Name one language to do both secure blockchain smart contracts, & device drivers, and embedded systems. And it can use pyo3/maturing to expose code to python. Many significant python libraries are rewriting into rust. Clang/llvm targets means that rust can go anywhere C or C++ can go, including very esoteric systems. I don't think the jury is out, it just doesn't have mainstream corporate penetration yet, it may never have that and that's fine. Rust community can/will write bindings to anything, there is no need for other options, people don't realise how powerful rusts polyglot approach is.
jmull 3y ago
> I really, really would not hire someone who is uncomfortable with C to program MCUs. I was under the impression Espressif was aimed at DIYers, prototypers, etc. looking to move fast and optimize later. I'm a C guy myself, but I think you're looking at this wrong. There is no blessed stack. It's about tradeoffs.
- bborud 3y ago
  That’s kind of like assuming AVR chips were only for hobbyists because you’re only familiar with the Arduino. And assuming that what hobbyists do has to be how the embedded industry works. I’m looking at this from the point of view of someone who runs a company that does about 2-3 custom MCU based design per year, and spends at least 30% of our software development effort on embedded. We don’t write firmware in C because it is fun, but because we don’t actually have any real choice. But please, do tell me that I’m looking at this wrong when I say that I’d rather not write software that controls machines that can kill people in C.
  - jmull 3y ago
    No one is telling you what language to use for your purposes. Just trying to point out that not everyone has the same purposes, and therefore may correctly draw different conclusions.
    - bborud 3y ago
      You might want to figure out what actual challenges professional firmware developers face before you start assuming how they "correctly" draw conclusions.

by bborud 3y ago

markhahn 3y ago

it's funny that when "discipline and rigor" is advocated for, the underlying premise is basically "pain builds character".

bborud 3y ago
Quite the opposite. You can essentially choose what kind of pain you want. On one hand you can have the pain of having to work with a compiler and toolchain that aims to eliminate problems early by requiring you to be more consistent and more correct. On the other hand you can choose to deal with the pain later - as your errors and inconsistencies come back to haunt you later. Or if you are a professional: have to invent your own consistency and error checks through extensive testing. Not that I would expect rigorous test from someone who chooses to avoid compilers that can help them write higher quality code. It is a lot more painful to have to deal with errors later, than it is to deal with them as you write the code. Not least in terms of financial pain and risk. For a lot of embedded systems "just updating the software" isn't always easy, it usually carries significant risk, and it isn't always even possible depending on how something is deployed. Or to express the above with fewer words: you can choose between pain now and pain later. As for tooling: using an interpreted language like Python means that it will only work for as long as the runtime environment is in a particular state. That all the right libraries are available in the right versions, and even the language runtime itself. Thousands upon thousands of files splattered across your filesystem. Every update of any part of the environment risking you suddenly have to spend days figuring out how to get things to work again. Brittle toolchains are a pain. Don't waste time on things that lead to brittle toolchains. I see a lot of hobbyists downplaying this online. I don't see a lot of people who work on this full time downplaying it. Be it people I know at MCU manufacturers who have to support customers or companies that manufacture devices and have large teams of embedded developers who regularly have to waste time because every new release means weeks of getting builds to behave somewhat predictably and reproducibly. Having more modern compilers and tooling that can be relied upon isn't about more pain. It is about considerably less pain. If dealing with a compiler that is strict is too much pain for you, then embedded programming probably isn't for you. Because having lax compilers (or no compiler) means you'll learn about your mistakes when it is quite possibly too late to do anything about them. C/C++ are not very nice languages if you want to ensure quality. Python gives you a sense of productivity over C/C++, but it provides no added benefit in terms of quality and de-risking. Rather the opposite because even the meager discipline a C/C++ compiler gives you is more than what Python gives you.

pjmlp 3y ago

Fortunely there are lots of companies out there in the industry, many of which have more open minded folks regarding what toolchains to use. Those that decide to be stuck in C, might one day wake up and realise the world has moved on without asking for permission.

sgt 3y ago

I think the jury's still out on whether Rust will make it long term. Even if all the technology checks out, the project can easily be mismanaged into the ground. We've already seen hints of that. Outside of C/C++ and Rust (seeing that MicroPython is irrelevant, as per your comment), what other options will be viable going into the future?

bborud 3y ago
You are probably right about Rust: it has challenges that seems to make a lot of people want to keep it at arms length. Viability isn't just about technical fitness, but also about momentum, community size, pace and having sensible "taste makers" that teach the community good design and programming practices. At the moment I don't see any viable alternatives. Rust has a good sized community AND people have been working on embedded use of it for many years already. It took a lot of work to get there. For an alternative to be viable it would have to achieve at least what Rust has achieved so far. What will ultimately determine if Rust becomes the new go-to language for embedded programming is the community forming around embedded Rust projects. Ruby is a good example of the power of a community trying to solve a given problem. I think Ruby would not have made it if it were not for Rails. Ruby started out as an interesting language with an atrociously bad runtime and ratty standard library. Yet it Rails had a community that vastly outperformed the qualities of the language/runtime it was based on. Perhaps embedded programming is where Rust will ultimately make such a huge difference the application of Rust becomes greater than Rust itself. Perhaps a Rust based RTOS, and a sensible approach to how embedded software is structured, modularized, and designed may be the thing that becomes greater than the language itself?
brianhorakh 3y ago
Linux & Microsoft win 11 both support native drivers in rust. Rust is a great (possibly best) way to build wasm. Wasm is extremely powerful. Name one language to do both secure blockchain smart contracts, & device drivers, and embedded systems. And it can use pyo3/maturing to expose code to python. Many significant python libraries are rewriting into rust. Clang/llvm targets means that rust can go anywhere C or C++ can go, including very esoteric systems. I don't think the jury is out, it just doesn't have mainstream corporate penetration yet, it may never have that and that's fine. Rust community can/will write bindings to anything, there is no need for other options, people don't realise how powerful rusts polyglot approach is.

jmull 3y ago

> I really, really would not hire someone who is uncomfortable with C to program MCUs. I was under the impression Espressif was aimed at DIYers, prototypers, etc. looking to move fast and optimize later. I'm a C guy myself, but I think you're looking at this wrong. There is no blessed stack. It's about tradeoffs.

bborud 3y ago
That’s kind of like assuming AVR chips were only for hobbyists because you’re only familiar with the Arduino. And assuming that what hobbyists do has to be how the embedded industry works. I’m looking at this from the point of view of someone who runs a company that does about 2-3 custom MCU based design per year, and spends at least 30% of our software development effort on embedded. We don’t write firmware in C because it is fun, but because we don’t actually have any real choice. But please, do tell me that I’m looking at this wrong when I say that I’d rather not write software that controls machines that can kill people in C.
- jmull 3y ago
  No one is telling you what language to use for your purposes. Just trying to point out that not everyone has the same purposes, and therefore may correctly draw different conclusions.
  - bborud 3y ago
    You might want to figure out what actual challenges professional firmware developers face before you start assuming how they "correctly" draw conclusions.