3 ms·

It almost goes both ways. Yes, being on an embedded device with no Internet access reduces your external attack surface. But it also limits your ability to use

It almost goes both ways. Yes, being on an embedded device with no Internet access reduces your external attack surface. But it also limits your ability to use lots of newer language features designed to improve safety, because those features often cost CPU cycles or memory. My (completely uninformed) guess is that most of any net benefit from being on an embedded system comes from the simple fact that "embedded" implies "constrained", which implies "less code," which, in turn, implies "fewer opportunities to create bugs in the first place."

Nursie 6y ago
It certainly plays into it - fewer moving parts means less opportunity for things going wrong.
MarcusE1W 6y ago
I don’t think that you are limited regarding newer language features when you develop for embedded devices or limited in the use of more safety focused languages. E.g. Ada, despite being in the older age for computer languages was specifically designed with embedded programming and safety features in mind and does this quite good. It also supports OOP if you want that sort of thing and more crucially has pretty good concurrency support build into the language while still being reasonably safe. With SPARK/Ada you even get a language variant that can be formally proven. To name some more modern use cases.
- mumblemumble 6y ago
  But this wasn't talking about using other languages with more of a safety focus. It was talking about using newer features of C++ that are meant to support safer programming. Most of these come in the form of abstractions with non-zero cost.
  - AnimalMuppet 6y ago
    OK, but... I see three options. 1) Use the non-zero-cost abstraction to do X safely. 2) Write the equivalent abstraction to do X safely, which will cost you the time to write and will probably be buggier than C++'s version. 3) Don't do X. The fourth option - do X but in an unsafe way - should not be on the table for a professional developer. Now, C++'s philosophy is that you can't write your own thing to do X more efficiently than C++'s builtin version. They may not perfectly achieve that in all cases, but they come fairly close. That plus bugs means that I won't reach for option 2 unless I have really good reason to think I can do better. That leaves using the builtins to do X safely, or not doing X. At least that's how it looks to me...

Nursie 6y ago

It certainly plays into it - fewer moving parts means less opportunity for things going wrong.

MarcusE1W 6y ago

I don’t think that you are limited regarding newer language features when you develop for embedded devices or limited in the use of more safety focused languages. E.g. Ada, despite being in the older age for computer languages was specifically designed with embedded programming and safety features in mind and does this quite good. It also supports OOP if you want that sort of thing and more crucially has pretty good concurrency support build into the language while still being reasonably safe. With SPARK/Ada you even get a language variant that can be formally proven. To name some more modern use cases.

mumblemumble 6y ago
But this wasn't talking about using other languages with more of a safety focus. It was talking about using newer features of C++ that are meant to support safer programming. Most of these come in the form of abstractions with non-zero cost.
- AnimalMuppet 6y ago
  OK, but... I see three options. 1) Use the non-zero-cost abstraction to do X safely. 2) Write the equivalent abstraction to do X safely, which will cost you the time to write and will probably be buggier than C++'s version. 3) Don't do X. The fourth option - do X but in an unsafe way - should not be on the table for a professional developer. Now, C++'s philosophy is that you can't write your own thing to do X more efficiently than C++'s builtin version. They may not perfectly achieve that in all cases, but they come fairly close. That plus bugs means that I won't reach for option 2 unless I have really good reason to think I can do better. That leaves using the builtins to do X safely, or not doing X. At least that's how it looks to me...