Hacker News Reader

Comment by bmitc | Hacker News Reader

I even think on embedded it's overblown in terms of not being able to use a GC language. C#, F#, OCaml, Java (and I suppose all JVM languages), Erlang, Elixir, etc. can run on embedded devices, including some microcontrollers. In my opinion, the software industry has dug its head in the sand thinking that only "hard-core" languages can be run on embedded systems. Even LabVIEW could be a choice if the limited SoM hardware selection is okay. It's just as performant (if not more so for multicore systems) and infinitely safer than C/C++.

View on HN

There are embedded Java systems. I hope you never have to work with any.

In general, embedded systems suffer from severe lack of tool developer attention. People standardize on the very few things that reliably work like C, C++, and printf debugging because they don't have the bandwidth for anything more. Anything outside the beaten track has a high chance of running into showstopping bugs halfway through a project and embedded teams are already struggling to find developer time in the typical situation of 1-10 people maintaining 1M+ LOC codebases.

Rust is the first real alternative to C and C++ in decades because it's actually trying to address the ecosystem issues.

Not even "printf" is included in any standard, I'm afraid. Arm's Keil MDK toolchain has an typical implemetation of baremetal C/C++ environment called microlib, but unfortunately it doesn't support RTOS because of the missing of re-entrancy, so you have to provide or use a third-party alternative.

I think the thing is, if you don't use C or C++, then you don't need a million lines of code.

I'm not stopping you from trying to put your theories to the test and I'm not saying the current reality is good. However, I think you'd be surprised how complex some of these systems are. An automotive system like the article is describing is a distributed realtime system of anywhere from dozens to hundreds of networked processors built without traditional operating system support. It's frankly a miracle they work at all.

While I don't work in the automotive field, I've worked on adjacent-esque distributed systems with some of the shared protocols (e.g., CANopen). Part of my lament here is that almost no effort has been put into anything other than running C and C++ on embedded systems. While hard real-time systems are a thing, other pieces have often still been implemented in C and C++, which is a shame. And it's also a shame that more effort hasn't been put into realtime garbage collectors, especially in this age of multicore embedded CPUs.

I fully agree that it's a miracle any of the existing stuff works at all. I honestly have no idea how C and C++ developers make it work. Despite being the oldest and most used languages, the tooling is atrocious.

Reply on news.ycombinator.com