4 ms·

Hacker news folks seem to be pretty negative about this. I'd definitely like to try it out. Maybe it's time to have some more options besides C on embedded devi

Hacker news folks seem to be pretty negative about this. I'd definitely like to try it out. Maybe it's time to have some more options besides C on embedded devices.

deleted 8y ago
[deleted]
jerrysievert 8y ago
I build a lot on embedded devices, including the esp8266 and esp32, and write a lot of stuff in javascript. I'm negative about this because it's hugely resource intensive when it doesn't have to be. there are much nicer ways to run javascript on a board that small (or smaller).
AlotOfReading 8y ago
There already are more options than C on embedded devices. You can run C++, Lua, Python, Ada, Lisp, Java, Forth, Rust, and dozens of others. The reason C dominates is that it's by far the most flexible, portable, and economical of these, despite its safety issues.
- 01100011 8y ago
  I think C dominates because it's a language many embedded guys, who often are EE's not CS graduates, can get their head around. Also C compilers were some of the most common for embedded platforms going back a few decades. Up until IoT became a buzzword, the embedded world was sort of insular and you had a lot of guys who got their start in the 80s or before. Sure, there's Forth, but that pretty much died out decades ago. C is also deterministic, unlike, say, Python, where you don't have a compiler to catch type errors and things can blow up unexpectedly at run time.
  - Sytten 8y ago
    Totally agree and thats what they still teach us at school in EE and CE (believe it or not). I worked a bit on embedded devices during internships and the only thing I saw is C sometimes with an API to abstract the registers (I was in the world of PIC). I talked with guys that still only coded in assembly and C was a "new" thing for them. People just don't realize that if you can save a KB of RAM and cycles of processor, you save on cost of pieces (you can use cheaper ones) and if you are to produce million of pieces thats a lot of money...
    - berti 8y ago
      I never understood the attraction of PIC in the face of ARM. The ecosystem seemed so much weaker in terms of compilers, libraries, and sheer variety of parts available.
      - 01100011 8y ago
        IIRC, PIC appealed to those embedded/EE guys because it was simple. It was also really cheap. You could add a tiny bit of smarts to your design for a little bit of money and effort. Those guys became well-versed in the PIC weirdness and stuck with it even though other, more traditional(i.e. 8051 based) micros came out with good features at nice price points. I don't remember a lot of cheap, easy to use options based on ARM around the time that the first PICs came out. Honestly I'm not sure though. I skipped the PIC entirely. I dealt with Z8's and 68HC12s at the time(and TMS320s, but that's another story).
  - berti 8y ago
    > I think C dominates because it's a language many embedded guys, who often are EE's not CS graduates, can get their head around. I think that's a pretty unfair characterization. > C is also deterministic, unlike, say, Python, where you don't have a compiler to catch type errors and things can blow up unexpectedly at run time. I've been doing a little prototyping at work recently with micropython (not my decision), and this is one of things that frustrated me. There's also lack of good tooling compared to (embedded)C/C++, and the lack of libraries. Regular pure-Python libraries either don't run, or perform very poorly because they don't stick to the subset of the standard library that's "acceptable" in micropython. It's basically a whole different ecosystem to Python, negating a lot of the advantages of Python.
    - 01100011 8y ago
      Well, that's my experience since working in embedded since '97. Remember there weren't a lot of options back then. It was the days before flash memory and you had to either use UV erasable EEPROMs or make a custom masked part. The C++ compilers were all horrible and inefficient. The debuggers barely worked. C was often your only option for a high level language, if you even had one. Some of the parts I used back then were ASM only, and if you managed to have a compiler it was so inefficient that you couldn't use it. The embedded world as I knew it was ruled by EEs. These people were barely programmers. I knew guys who would rather cut and paste code instead of make functions. Regarding embedded Python, you have my condolences. I took a job where they use it to implement most of the system level code for a safety critical device. I was excited to do more Python until I realized what a poor choice it was for embedded. Hell, I'd rather use Java because at least you have a compiler to catch a whole class of bugs. I'm old fashioned. If someone's life depends on it, write it in C, avoid dynamic allocation, and make heavy use of state machines. My friend works on satellite code and that's basically how it is. They don't even use an OS.
      - berti 8y ago
        I guess the CS component of EE has grown quite a lot since back then. You learn at least a solid programming base early on, and get much deeper into CS if you go down the embedded systems path. I totally agree with everything in your last two paragraphs!
- monocasa 8y ago
  And C lacks a GC. Practically GCs don't fulfill the constraints of a lot of embedded projects. Even the real time GCs come at a heavy perf cost. C++ has had a remarkable amount of uptake over the past few years. TI has been pushing it hard for using C++ with their DSPs.
  - pjmlp 8y ago
    Hopefully as it allows for more secure coding, but it is a struggle against the established mentality, as it has become a common theme on C++ conferences.
tluyben2 8y ago
It is also because of the word embedded. You can call anything embedded but in our community, generally, 2MB is a rediculous amount of memory and cpu cycles are costly. C(++)/asm are very normal and people are used to that. For prototyping products we use a Forth, but I guess JS could work for that if efficient enough to try it out. Also, this would not pass audits (yet) in some industries. But that's not a reason to be negative; I think the footprint and calling that embedded is not very realistic atm.
MrQuincle 8y ago
It's just a different world. You need cross-compiler support. Developers are spending much more time on compilers where the target is the same as the host architecture. Logically so! Compare GCC arm cross compiler to clang for example. The system should be expressive enough to allow you to write function pointers to specific addresses in memory. For example if you have a binary radio stack, this might be a requirement (imho callbacks are better, but yeah). With the linker this is easy as is constraining heap, stack, etc. Where do you begin with the Python VM to do the same? It's just harder. Support from the chipset manufacturer. If there is a HAL, it's in C. Good luck with a Rust crate pulled from somewhere random and keeping it all up to date. Debuggers. GDB is pretty awesome in case you really need to know what's happening. You can't debug by just writing logs if you're working on the UART implementation for example. Setting breakpoints and analysing the stack is essential. Design patterns are just different. I had a recent discussion about leaving out the destructors of a series of objects on a large mode switch (in a setup procedure) in exchange for writing the mode to FLASH, a device reset, and a few lines of startup code. The latter - the reset design paradigm - would come with a smaller binary. No management needed of all objects. A bit like rerendering the entire screen instead of only a part of it. Hence, it's not just because people are "negative". It's really a best tool for the job kind of thing. The C (eventually C++) ecosystem is that tool.

Hacker news folks seem to be pretty negative about this. I'd definitely like to try it out. Maybe it's time to have some more options besides C on embedded devices.

deleted 8y ago

[deleted]

jerrysievert 8y ago

I build a lot on embedded devices, including the esp8266 and esp32, and write a lot of stuff in javascript. I'm negative about this because it's hugely resource intensive when it doesn't have to be. there are much nicer ways to run javascript on a board that small (or smaller).

AlotOfReading 8y ago

There already are more options than C on embedded devices. You can run C++, Lua, Python, Ada, Lisp, Java, Forth, Rust, and dozens of others. The reason C dominates is that it's by far the most flexible, portable, and economical of these, despite its safety issues.

01100011 8y ago
I think C dominates because it's a language many embedded guys, who often are EE's not CS graduates, can get their head around. Also C compilers were some of the most common for embedded platforms going back a few decades. Up until IoT became a buzzword, the embedded world was sort of insular and you had a lot of guys who got their start in the 80s or before. Sure, there's Forth, but that pretty much died out decades ago. C is also deterministic, unlike, say, Python, where you don't have a compiler to catch type errors and things can blow up unexpectedly at run time.
- Sytten 8y ago
  Totally agree and thats what they still teach us at school in EE and CE (believe it or not). I worked a bit on embedded devices during internships and the only thing I saw is C sometimes with an API to abstract the registers (I was in the world of PIC). I talked with guys that still only coded in assembly and C was a "new" thing for them. People just don't realize that if you can save a KB of RAM and cycles of processor, you save on cost of pieces (you can use cheaper ones) and if you are to produce million of pieces thats a lot of money...
  - berti 8y ago
    I never understood the attraction of PIC in the face of ARM. The ecosystem seemed so much weaker in terms of compilers, libraries, and sheer variety of parts available.
    - 01100011 8y ago
      IIRC, PIC appealed to those embedded/EE guys because it was simple. It was also really cheap. You could add a tiny bit of smarts to your design for a little bit of money and effort. Those guys became well-versed in the PIC weirdness and stuck with it even though other, more traditional(i.e. 8051 based) micros came out with good features at nice price points. I don't remember a lot of cheap, easy to use options based on ARM around the time that the first PICs came out. Honestly I'm not sure though. I skipped the PIC entirely. I dealt with Z8's and 68HC12s at the time(and TMS320s, but that's another story).
- berti 8y ago
  > I think C dominates because it's a language many embedded guys, who often are EE's not CS graduates, can get their head around. I think that's a pretty unfair characterization. > C is also deterministic, unlike, say, Python, where you don't have a compiler to catch type errors and things can blow up unexpectedly at run time. I've been doing a little prototyping at work recently with micropython (not my decision), and this is one of things that frustrated me. There's also lack of good tooling compared to (embedded)C/C++, and the lack of libraries. Regular pure-Python libraries either don't run, or perform very poorly because they don't stick to the subset of the standard library that's "acceptable" in micropython. It's basically a whole different ecosystem to Python, negating a lot of the advantages of Python.
  - 01100011 8y ago
    Well, that's my experience since working in embedded since '97. Remember there weren't a lot of options back then. It was the days before flash memory and you had to either use UV erasable EEPROMs or make a custom masked part. The C++ compilers were all horrible and inefficient. The debuggers barely worked. C was often your only option for a high level language, if you even had one. Some of the parts I used back then were ASM only, and if you managed to have a compiler it was so inefficient that you couldn't use it. The embedded world as I knew it was ruled by EEs. These people were barely programmers. I knew guys who would rather cut and paste code instead of make functions. Regarding embedded Python, you have my condolences. I took a job where they use it to implement most of the system level code for a safety critical device. I was excited to do more Python until I realized what a poor choice it was for embedded. Hell, I'd rather use Java because at least you have a compiler to catch a whole class of bugs. I'm old fashioned. If someone's life depends on it, write it in C, avoid dynamic allocation, and make heavy use of state machines. My friend works on satellite code and that's basically how it is. They don't even use an OS.
    - berti 8y ago
      I guess the CS component of EE has grown quite a lot since back then. You learn at least a solid programming base early on, and get much deeper into CS if you go down the embedded systems path. I totally agree with everything in your last two paragraphs!
monocasa 8y ago
And C lacks a GC. Practically GCs don't fulfill the constraints of a lot of embedded projects. Even the real time GCs come at a heavy perf cost. C++ has had a remarkable amount of uptake over the past few years. TI has been pushing it hard for using C++ with their DSPs.
- pjmlp 8y ago
  Hopefully as it allows for more secure coding, but it is a struggle against the established mentality, as it has become a common theme on C++ conferences.

tluyben2 8y ago

It is also because of the word embedded. You can call anything embedded but in our community, generally, 2MB is a rediculous amount of memory and cpu cycles are costly. C(++)/asm are very normal and people are used to that. For prototyping products we use a Forth, but I guess JS could work for that if efficient enough to try it out. Also, this would not pass audits (yet) in some industries. But that's not a reason to be negative; I think the footprint and calling that embedded is not very realistic atm.

MrQuincle 8y ago

It's just a different world. You need cross-compiler support. Developers are spending much more time on compilers where the target is the same as the host architecture. Logically so! Compare GCC arm cross compiler to clang for example. The system should be expressive enough to allow you to write function pointers to specific addresses in memory. For example if you have a binary radio stack, this might be a requirement (imho callbacks are better, but yeah). With the linker this is easy as is constraining heap, stack, etc. Where do you begin with the Python VM to do the same? It's just harder. Support from the chipset manufacturer. If there is a HAL, it's in C. Good luck with a Rust crate pulled from somewhere random and keeping it all up to date. Debuggers. GDB is pretty awesome in case you really need to know what's happening. You can't debug by just writing logs if you're working on the UART implementation for example. Setting breakpoints and analysing the stack is essential. Design patterns are just different. I had a recent discussion about leaving out the destructors of a series of objects on a large mode switch (in a setup procedure) in exchange for writing the mode to FLASH, a device reset, and a few lines of startup code. The latter - the reset design paradigm - would come with a smaller binary. No management needed of all objects. A bit like rerendering the entire screen instead of only a part of it. Hence, it's not just because people are "negative". It's really a best tool for the job kind of thing. The C (eventually C++) ecosystem is that tool.