[PinguTS]

If you want to talk about safety and reliability in automotive, then we talk about Autosar[1].

One of the concepts is to prevent the use of any dynamic behavior, which means you don't need any garbage collection at all. Because garbage collection is not predictable. It can be good and bad, but even a good one is not predictable.

Embedded design and development is completely different to classical IT. For IT that sounds archaic. But it always proved right at the end.

[1] https://en.wikipedia.org/wiki/AUTOSAR

[Matthias247]

True, AUTOSAR is the current standard for embedded automotive systems. Regarding safety I heard different things about it, some parties would only use it for up to ASIL A, others to C, others also to D. My personal opinion is that AUTOSAR (and even it's basics like C as a programming language and the OSEK OS) are not the best solutions that we should come up with for all the safety critical tasks in the autonomous driving world. Someone like Lattner would clearly have the potential to improve the current state of the art there a lot - but it's uncertain if Tesla would share any advantages with the remaining industry.

And regarding memory allocation in reliable automotive systems: Yes, the best practice would be not to allocate at all to get to some deterministic behavior. However I've seen lots of projects where "don't allocate" is implemented as "don't allocate with malloc", and you find dozens of custom memory allocators and pools throughout the code. Some of those designs are probably less reliable and safe than using a garbage collected language would be.

[therockhead]

I often wonder would Erlang be a good language for embedded automotive systems. It's seems to have the right traits - no GC pauses, built for reliability etc.

[Matthias247]

I think it would fit great from the semantic. Message based communication is exactly what a lot of automotive systems are about (CAN, FlexRay, ...). The downside of the actor model from an implementation point of view is that you need potentially unbounded memory for the incoming message queue of each actor. For each message that is sent to an actor you need to allocate a message, populate it and place in that that actors queue. If the actor can't process fast enough the queue will fill hap.

It might work out with a very careful system design, but determining statically how much queued messages and memory is needed seems like a very hard task.