6 ms·

> C is not going to be replaced on embedded any moment soon. Why? Doesn't for example Rust without stdlib already cover the use cases? Note I'm not experienced

by dmos62 7y ago

> C is not going to be replaced on embedded any moment soon. Why? Doesn't for example Rust without stdlib already cover the use cases? Note I'm not experienced in embedded.

pjc50 7y ago
I think most users are going to wait until CMSIS or their local equivalent is available: https://github.com/ARM-software/CMSIS_5 https://github.com/ARM-software/CMSIS_5 Besides, it's a big retraining effort.
MrBuddyCasino 7y ago
Its slowly getting there, but no, right now there is a very limited number of target platforms that are supported, and the ecosystem is still very small and immature. You have to remember that there is a huge number of microcontrollers out there, with exotic architectures you have never heard of, and that LLVM definitely doesn't support. I'm not sure embedded Rust would even meaningfully exist without the work of Jorge Aparicio.
- uxp100 7y ago
  Yeah. Even on the best supported platforms it is very immature. If you want to use embedded rust you kinda have to let language drive your choice of platform, which isn’t ideal. I wouldn’t use it at work yet, but it’s coming along.
scoutt 7y ago
My personal opinion, is basically for 3 reasons: 1) There is no need to. C already has all we need to build our systems. The rest is seen as overhead/over-complication. Regarding Rust, I try to keep up to date about its progress. Unfortunately most of the diseases that Rust cures are not much of a trouble in embedded. My last UB, memory leak of loose pointer happened years ago. It will happen again and when it happens, I'll debug it. That's it. I'm not afraid of UB or dealing with pointers, even if there are 10K Rust users trying to FUD me. I know what I'm doing. Every embedded/kernel/driver developer know what they are doing. When shit happens, that's it, no big deal. You plug your debugger and solve the issue. It's not a nightmare that chases us in the middle of the day. FUD alone is not enough for switching. So, why should I start thinking that a variable cannot change, because it's a constant (wasn't it a variable?), unless it can mutate, so it's a constant variable that can change because now is mutable? Or constrain myself into borrow-checker torture for a thing I can do in a couple of instructions? WHY? 2) This is not about a language problem, is about solving a programmer problem with language. If C = math, then you cannot do math simpler/better because today's mathematicians are sloppier. Or because bosses pressures people to deliver crappy products. I'm not a genius. I'm far from it, and if any seasoned C programmer challenges me I'll probably run away. But embedded/kernel/driver development is harsh, so if a developer thinks that he/she cannot make it because language, then it's mostly about searching for an excuse. Time to change jobs. The key is to think that a lot of people did (and does) a lot with so much less, for 40 years now. It's not a language problem. People have to learn to deal with it. I was there too 20 years ago, when every C++ developer was afraid that they would lose their jobs because C#. It never happened. C++ is still one of the most used languages. 3) In my case, there are official libraries from manufacturers you have to use. Sometimes receiving customer support depends on if and how you use those libraries. All those libraries are in C. All the support is in C. All the examples are in C. Yes, I know there is that engineer that has a Github repo with a library that works fine with that STM32 for that specific language, that now is getting support for embedded so in 5 years we could maybe put something in production. But, not for now. Sorry for the length. Edited some typos.
- dx87 7y ago
  > Every embedded/kernel/driver developer know what they are doing. Yet we still see security issues in all of those. I'm not saying that everything should be re-written in a different language, but C developers saying "I'm a good developer, all those safety mechanisms would hold me back" doesn't hold water considering all the security vulnerabilities we see that would have been prevented if they had used a language with better safeguards.
  - scoutt 7y ago
    > Yet we still see security issues in all of those That's the typical excuse. That's the FUD I mentioned about. Bugs will keep existing and so security issues, no matter the language you use.
    - pjmlp 7y ago
      We need regulation to make companies liable for CVEs, then this will stop being FUD, easy.
      - jcranmer 7y ago
        It says something of our profession that we have all of our products come with a legal document that effectively says it's not our fault if the product doesn't do what it's supposed to do.
        perl4ever 7y ago
        We should just outlaw those damn statements (and binding arbitration for consumers) and see how the market naturally evolves. Don't force standards on programmers, don't regulate in some novel way, just get rid of the stupid disclaimers and let the old-fashioned legal framework return to primacy.
    - hurrrrrrrr 7y ago
      But if we get rid of a whole class of bugs and vulnerabilities, the number of bugs will go down, no?
pjmlp 7y ago
The issue is social, not technical. There are several alternatives to C, when a team is open minded.
baybal2 7y ago
Rust is not mature, and people don't like Mozilla now
michaelt 7y ago
C's strength is the ecosystem: * Your microprocessor has a C compiler and standard library, as does every processor you might ever switch to. All the hardware documentation that isn't tables in a PDF will be in C. * Your target's static analysis tools and interactive debuggers will all support C. * Every RTOS and embedded library/filesystem/whatever will support (and likely be written in) C. * All experienced embedded developers are fluent in C. * Nobody ever got fired for choosing C for an embedded project. The disadvantages of C are many and well known.
- AnimalMuppet 7y ago
  > The disadvantages of C are many and well known. Which, in a way, is an advantage. I know (much of) what to look out for. There are tools that can help me with some of those issues. There are techniques that avoid some of them, and there are people who are expert in many of them. But if I pick some other language, it won't have those problems. It will have other problems. (There is no language that does not have problems.) I won't know what to avoid doing. There may not be tooling to help with them. The techniques for avoiding them may not be widely known. I may not be able to find people who know how to handle them. To me, "well known problems" may be better than "not well known problems". More predictable, at least. The "not well known" problems have to be significantly better to be worth it. They probably have to be proven significantly better. That means either that someone else has to prove them better, or else I have to have a project that doesn't matter much that I can use as a testbed.

by dmos62 7y ago

> C is not going to be replaced on embedded any moment soon. Why? Doesn't for example Rust without stdlib already cover the use cases? Note I'm not experienced in embedded.

pjc50 7y ago

I think most users are going to wait until CMSIS or their local equivalent is available: https://github.com/ARM-software/CMSIS_5 https://github.com/ARM-software/CMSIS_5 Besides, it's a big retraining effort.

MrBuddyCasino 7y ago

Its slowly getting there, but no, right now there is a very limited number of target platforms that are supported, and the ecosystem is still very small and immature. You have to remember that there is a huge number of microcontrollers out there, with exotic architectures you have never heard of, and that LLVM definitely doesn't support. I'm not sure embedded Rust would even meaningfully exist without the work of Jorge Aparicio.

uxp100 7y ago
Yeah. Even on the best supported platforms it is very immature. If you want to use embedded rust you kinda have to let language drive your choice of platform, which isn’t ideal. I wouldn’t use it at work yet, but it’s coming along.

scoutt 7y ago

My personal opinion, is basically for 3 reasons: 1) There is no need to. C already has all we need to build our systems. The rest is seen as overhead/over-complication. Regarding Rust, I try to keep up to date about its progress. Unfortunately most of the diseases that Rust cures are not much of a trouble in embedded. My last UB, memory leak of loose pointer happened years ago. It will happen again and when it happens, I'll debug it. That's it. I'm not afraid of UB or dealing with pointers, even if there are 10K Rust users trying to FUD me. I know what I'm doing. Every embedded/kernel/driver developer know what they are doing. When shit happens, that's it, no big deal. You plug your debugger and solve the issue. It's not a nightmare that chases us in the middle of the day. FUD alone is not enough for switching. So, why should I start thinking that a variable cannot change, because it's a constant (wasn't it a variable?), unless it can mutate, so it's a constant variable that can change because now is mutable? Or constrain myself into borrow-checker torture for a thing I can do in a couple of instructions? WHY? 2) This is not about a language problem, is about solving a programmer problem with language. If C = math, then you cannot do math simpler/better because today's mathematicians are sloppier. Or because bosses pressures people to deliver crappy products. I'm not a genius. I'm far from it, and if any seasoned C programmer challenges me I'll probably run away. But embedded/kernel/driver development is harsh, so if a developer thinks that he/she cannot make it because language, then it's mostly about searching for an excuse. Time to change jobs. The key is to think that a lot of people did (and does) a lot with so much less, for 40 years now. It's not a language problem. People have to learn to deal with it. I was there too 20 years ago, when every C++ developer was afraid that they would lose their jobs because C#. It never happened. C++ is still one of the most used languages. 3) In my case, there are official libraries from manufacturers you have to use. Sometimes receiving customer support depends on if and how you use those libraries. All those libraries are in C. All the support is in C. All the examples are in C. Yes, I know there is that engineer that has a Github repo with a library that works fine with that STM32 for that specific language, that now is getting support for embedded so in 5 years we could maybe put something in production. But, not for now. Sorry for the length. Edited some typos.

dx87 7y ago
> Every embedded/kernel/driver developer know what they are doing. Yet we still see security issues in all of those. I'm not saying that everything should be re-written in a different language, but C developers saying "I'm a good developer, all those safety mechanisms would hold me back" doesn't hold water considering all the security vulnerabilities we see that would have been prevented if they had used a language with better safeguards.
- scoutt 7y ago
  > Yet we still see security issues in all of those That's the typical excuse. That's the FUD I mentioned about. Bugs will keep existing and so security issues, no matter the language you use.
  - pjmlp 7y ago
    We need regulation to make companies liable for CVEs, then this will stop being FUD, easy.
    - jcranmer 7y ago
      It says something of our profession that we have all of our products come with a legal document that effectively says it's not our fault if the product doesn't do what it's supposed to do.
      - perl4ever 7y ago
        We should just outlaw those damn statements (and binding arbitration for consumers) and see how the market naturally evolves. Don't force standards on programmers, don't regulate in some novel way, just get rid of the stupid disclaimers and let the old-fashioned legal framework return to primacy.
  - hurrrrrrrr 7y ago
    But if we get rid of a whole class of bugs and vulnerabilities, the number of bugs will go down, no?

pjmlp 7y ago

The issue is social, not technical. There are several alternatives to C, when a team is open minded.

baybal2 7y ago

Rust is not mature, and people don't like Mozilla now

michaelt 7y ago

C's strength is the ecosystem: * Your microprocessor has a C compiler and standard library, as does every processor you might ever switch to. All the hardware documentation that isn't tables in a PDF will be in C. * Your target's static analysis tools and interactive debuggers will all support C. * Every RTOS and embedded library/filesystem/whatever will support (and likely be written in) C. * All experienced embedded developers are fluent in C. * Nobody ever got fired for choosing C for an embedded project. The disadvantages of C are many and well known.

AnimalMuppet 7y ago
> The disadvantages of C are many and well known. Which, in a way, is an advantage. I know (much of) what to look out for. There are tools that can help me with some of those issues. There are techniques that avoid some of them, and there are people who are expert in many of them. But if I pick some other language, it won't have those problems. It will have other problems. (There is no language that does not have problems.) I won't know what to avoid doing. There may not be tooling to help with them. The techniques for avoiding them may not be widely known. I may not be able to find people who know how to handle them. To me, "well known problems" may be better than "not well known problems". More predictable, at least. The "not well known" problems have to be significantly better to be worth it. They probably have to be proven significantly better. That means either that someone else has to prove them better, or else I have to have a project that doesn't matter much that I can use as a testbed.