Hacker News new | comments | show | ask | jobs | submit login

The mainstream OS choices are: Wind River VxWorks, Green Hills Integrity, BlackBerry QNX, Linux, Android, and (god forbid) some variant of Windows.

A great deal of embedded software is still done in C/C++. (Embedded is not a good environment for dynamic languages.)




Can I ask why you dislike dynamic languages in an embedded environment? Or why you think they are 'not good'?


Dynamic languages have unpredictable usage of memory. This is okay when you have many gigabytes of memory. This is not okay when you have a handful of megabytes (or a single gigabyte) of memory.

Being able to accurately profile how much memory will ever be in use is very valuable. Being able to prevent unexpected usage or stop-the-world collection issues means your device is that much safer.

Also, static languages are usually faster and more predictable, to a certain degree. This is advantageous in an industry that would rather spend years developing something than have a small chance of killing someone. Bugs are unacceptable.

If you're willing to pack an Intel Atom or something into your device, fine. But if you can get by with a tiny ARM chip, why shouldn't you?


But if you can get by with a tiny ARM chip, why shouldn't you?

Features, complexity, cost/availability of humans that can comprehend it, availability of existing software components, simplicity of software development process, etc.


ARM chips have feature parity with Atom chips except for their x86 architecture and power. ARM chips and their implementations are less complex, not more. Software components can be a bother, but ARM runs Linux perfectly well. If Linux doesn't suit your fancy, there are plenty of RTOS waiting for you.

And I kind of touched on the simplicity of software development. Yes, it's possible to quickly shove in a really tiny x86 computer and be done with it, but it ends up being cost prohibitive and energy hungry. Embedded environments are a place where you can get by with a tiny ARM chip; they're power efficient and cost effective. If you're in the embedded field, dev isn't as simple as a REPL, you have to put it directly on your device or otherwise emulate your device in some way. This forces you to come up with robust solutions.

Dev in this environment is already hard. It has to be robust anyway. Maybe we should pick the right tool for the job while we're at it.

And I am happy using a robust solution that I know won't fail me. If you're in a situation where failing to write bug-free code can kill, you would be too. Medical devices are one such field.

(But to each his own, of course! You can do awesome things with any tool.)


Complexity refers to overall cognitive load, hassle and lead time for developers and the business as a whole (hardware sourcing, cross-compiling, testing, etc.) and not just chip features.

Hard limits to processing power, memory, energy availability, etc. do exist in some applications, but the OP doesn't seem to have these issues.


Depends on how embedded. For something really mission critical you don't want any dynamic malloc at all even in C code. Allocate a set amount up front and manage that directly. For an android phone on the other hand, no problem.


I really like working with Ruby. But then I think about the way I use it. Web applications under constant flux. When a new version is released, I'm looking to start using it ASAP.

But when I think of embedded devices, I'm looking across my desk at a Cisco router with an eight year old firmware, and an HP LaserJet I recall updating at least 12 years ago. I shudder at the idea of writing Ruby and having it run in production for 12 years.

This doesn't criticise "dynamic" languages directly - but I can only possibly think of C, and similar languages, which wouldn't suffer this issue. Hopefully Rust can improve this situation.

That said, I'm on the fence about Erlang in this situation.




Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: