Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)

[Marco]

An example C# and java with its garbage collector were a goldmine for some epic hacks since the garbage collector was not real time.

AFAICS breaking the sandbox with untrusted code mostly became a theoretical exercise after Java was banned from browsers, thus for C# too. At this point unless your code somehow allows an adversary to execute dynamic code, it's really unlikely that lifetime mismatches between native APIs and GC'd stuff is going to cause remote exploits.

[gf]

An example C# and java with its garbage collector were a goldmine for some epic hacks since the garbage collector was not real time.

Que? 

C isn't "real time" (to repeat your misuse of the term) either!

In C you still have the choice how you manage memory yourself. In Java, C#, Python, etc. you don't.

[tggzzz]

An example C# and java with its garbage collector were a goldmine for some epic hacks since the garbage collector was not real time.

AFAICS breaking the sandbox with untrusted code mostly became a theoretical exercise after Java was banned from browsers, thus for C# too. At this point unless your code somehow allows an adversary to execute dynamic code, it's really unlikely that lifetime mismatches between native APIs and GC'd stuff is going to cause remote exploits.

Java the language+libraries is safe. Implementations of the JVM can have bugs, but the JVM is upgradeable without changing the application or its bytecode.

C#, on the other hand, cannot be safe by design since it includes the unsafe keyword. Flaws in the C# compiler or libraries can require the application to be recompiled on each installed system. Without having bothered to investigate, my guess is that is a reason Windows updates take so much longer than Linux updates.

[tggzzz]

An example C# and java with its garbage collector were a goldmine for some epic hacks since the garbage collector was not real time.

Que? 

C isn't "real time" (to repeat your misuse of the term) either!

In C you still have the choice how you manage memory yourself. In Java, C#, Python, etc. you don't.

That's not the problem and therefore not the solution.

Even on 486s with their tiny caches, the peak-to-mean execution time for some simple sequences could be a factor of (IIRC) 8. It all depended on what was and was not in the caches when the sequence ran.

With modern processor which have enormous L1, L2, L3 caches, plus TLB caches and worse, when you exceed an invisible and unknowable limit the execution time drops increases dramatically. Then add superscalar execution engines, multiple cores, NUMA, non-optimal data alignment, and execution time becomes even more unpredictable.

Don't believe me?

• look at the processor data sheets, and try to determine how long it will take an instruction to execute. That used to be easy, decades ago
• look at simple array operation micro-benchmarks for processors, and see how the execution time changes as data structure size in increases. Note especially the cliffs

"Cache is the new DRAM, DRAM is the new disk".

[westfw]

So: "no processor that utilizes cache is realtime", and it has nothing to do with what language you pick?

[Kjelt]

An example C# and java with its garbage collector were a goldmine for some epic hacks since the garbage collector was not real time.

AFAICS breaking the sandbox with untrusted code mostly became a theoretical exercise after Java was banned from browsers, thus for C# too. At this point unless your code somehow allows an adversary to execute dynamic code, it's really unlikely that lifetime mismatches between native APIs and GC'd stuff is going to cause remote exploits.

It was part of a SANS hacking course on webapplications. 10 seconds after a user provided a password, the complete hash could still be found in the memory. Ofcourse a beteer practice would be as a programmer to wipe the arrays of memory with sensitive information.
That is the difference between a security minded programmer and just a webdeveloper.

But it goes so far that even on embedded security implementations for comparing for instance a hash of a password,  a security programmer will not use a standard memcmp function. Nice quiz question , any idea why he should not use a standard libc memcmp ?

[pcprogrammer]

So: "no processor that utilizes cache is realtime", and it has nothing to do with what language you pick?

Define "real time" I would say.

One can argue that even interrupt driven system are not real time. When the interrupt is handled depends also on several factors, like the priority system and how and when the CPU switches to processing the interrupt instructions.

[janoc]

So: "no processor that utilizes cache is realtime", and it has nothing to do with what language you pick?

Realtime has zero to do with programming language.

There are no "realtime programming languages".  You could write a hard real time system even in Python if you really really wanted to (and were sufficiently insane to undertake such project). Some languages merely make the job easier because they tend to be closer to the hardware.

The same thing about processors and caches. Caches are a fact of life and have nothing to do whether or not your system can guarantee real time performance or not. What does is your system and software design, not whether or not the CPU has a cache.

Yes, the caches (and other things) do make predicting the execution times harder. But the point is you don't design your system around carefully crafted cycle-counted routines that are neigh impossible to guarantee performance of on high end hw with varying data sizes and operating conditions. One uses things such as performance counters and hardware timers to ensure hard limits on task execution times instead.

Basically the old personal computer and microcontroller techniques (cycle counting, disabling interrupts, etc.) don't really translate to these systems anymore. That doesn't mean you shouldn't optimize your code - but you can't rely only on that if your goal is real time performance. And at that point whether you have a cache or not becomes irrelevant - or rather, you do want the cache because it makes the machine perform much better than some obscure old junk without.

[tggzzz]

So: "no processor that utilizes cache is realtime", and it has nothing to do with what language you pick?

My response must be interpreted in the context that you chose to snip, i.e. garbage collector => not realtime, but hand-coding C algorithms => (can be) realtime. That's false for many reasons I mentioned, not just caches. Don't ignore all the other problems!

Anything written in any language that is executing on top of something with "unpredictable" timing cannot magically have predictable timing. No surprises there.

Caches' principal function is to reduce the average execution time. They do not (positively) change worst case execution time.

For hard realtime systems where a missed deadline is fatal, average execution time is irrelevant - only worst case matters. In such cases the best option is to not have caches. That is true for caches implemented in hardware and software.

For soft realtime systems it will come down to the probability of missing a deadline and the penalty when that happens. The tighter those are, the more caches can ensare the unware.

But don't forget all the other issues that affect the predictability of timing, including but not limited to superscalar execution engines, multiple cores, NUMA, non-optimal data alignment.

What was valid when C was in its infancy 40 years ago is no longer true; modern computers aren't "fast PDP-11s"!.

Summary: a language is a tiny part of the overall behaviour of a system.

[tggzzz]

So: "no processor that utilizes cache is realtime", and it has nothing to do with what language you pick?

Realtime has zero to do with programming language.

Agreed.

There are no "realtime programming languages". 

Not quite. There is xC running on the xCORE multicore MCUs (up to 4000MIPS). The IDE tooling shows the exact number of clock cycles that a given instruction sequence will take to execute.

Notably that is the combination of hardware and software, not software alone.

You could write a hard real time system even in Python if you really really wanted to (and were sufficiently insane to undertake such project). Some languages merely make the job easier because they tend to be closer to the hardware.

The same thing about processors and caches. Caches are a fact of life and have nothing to do whether or not your system can guarantee real time performance or not. What does is your system and software design, not whether or not the CPU has a cache.

Yes, the caches (and other things) do make predicting the execution times harder. But the point is you don't design your system around carefully crafted cycle-counted routines that are neigh impossible to guarantee performance of on high end hw with varying data sizes and operating conditions. One uses things such as performance counters and hardware timers to ensure hard limits on task execution times instead.

Basically the old personal computer and microcontroller techniques (cycle counting, disabling interrupts, etc.) don't really translate to these systems anymore. That doesn't mean you shouldn't optimize your code - but you can't rely only on that if your goal is real time performance. And at that point whether you have a cache or not becomes irrelevant - or rather, you do want the cache because it makes the machine perform much better than some obscure old junk without.

It may also matter what happens when such a hardware+software system suddenly and inexplicably performs much more slowly - and that can happen with caches, NUMA, superscalar execution, etc.

Hardcoding a few data structures plus algorithms in a particular language isn't going to significantly affect that variability. Nor, in many useful circumstances, will having a modern garbage collector.

[janoc]

There are no "realtime programming languages". 

Not quite. There is xC running on the xCORE multicore MCUs (up to 4000MIPS). The IDE tooling shows the exact number of clock cycles that a given instruction sequence will take to execute.

Notably that is the combination of hardware and software, not software alone.

That's what I meant when I said that some make it easier than others, especially when the vendor has engineered their own vendor specific tooling for their proprietary hardware.

However there is not such thing as a "realtime language" as the "realtimeness" isn't some sort of an intrinsic language property where you could say "C is real time but no, Python is not!"

There is fundamentally nothing preventing you from rewriting the Python interpreter/compiler + add stuff to the tooling to enable something like this too. Would you want to? Probably not. But the point is that it is possible to do, even though the result would probably differ from the standard Python in many places. Which would be the same like many other vendor-specific language dialects (e.g. C has many, BASIC was infamous for them, etc.)

The programming languages are by design abstract tools to ultimately generate machine code. What you do with that code matters, not the tool you use to produce it.

Hardcoding a few data structures plus algorithms in a particular language isn't going to significantly affect that variability. Nor, in many useful circumstances, will having a modern garbage collector.

Exactly.  People have been harping on these things and specifically the garbage collectors ever since Lisp times - and it wasn't quite a valid argument even back then and is even less today. But it is a fairly good indicator that the person who pulls this out as an argument for or against use of some language or tool doesn't quite understand what they are talking about ...

[hans]

adding all kinds of bounds checks just to make the software robust [is annoying, in C]

So ... let me ask a question about "bounds checking."

When one talks about adding bounds checking to a C program, you usually end up with depressing code like:

Code: [Select]

int foo(a, b) {  bounds_check(a);  bounds_check(b);  int result = bar(a, b, 123);  bounds_check(result);  return result;}int bar(a, b, c) {  bounds_check(a);  bounds_check(b);  bounds_check(c);
  int result = baz(a, c, 567);  bounds_check(result);  return result;}
ie redundant bounds checking at every level of a call tree.  Even if you don't actually USE a parameter, but just pass it on.  Because, after all, you don't know if the function that called you, or the function that you're calling, will do its own bounds checking.

Do languages that inherently support bounds checking managed to optimize it so that a variable is only checked when it is about to be used?  (and preferably, only if it hasn't been checked already since the last time it was changed?)

I think a far greater problem is; what to do when a bounds check fails? Do you just return NULL? Do you try to best-effort execute some parts of the function call? Are there side effects that are persistent? What is the callee going to do with the failed result?
Personally I only run assertion checks inside functions to check whether arguments are sane. If they are insane, then I know there is a problem in the callee. In release I remove these runtime checks, as I don't deem them as useful for non-debug images. I write unit tests that exercises as wide operating conditions of the code as possible. If the code has a clear fail-path, then I do implement a fail-safe return method.

Modern programming languages fully embrace modern design patterns to deal with these kinds of issues, such as monads and pattern matching. You could implement a similar thing in C with structs and switch/case statements, but nobody is doing that because it's such as hassle to do. Typically C languages will push as pass/fail as return value, and output data via pointer/reference arguments.

I disagree that programming languages do not play a role.  Short hand notations do help here, otherwise I vote to go back to C89 and remove else and all loop statements, as these are all variants of the goto statement. I don't think it's about freedom: it's about putting the language to work for you. Some of the points listed by TopQuark are also available in modern C++, which is gaining plenty of traction under enthusiast embedded programmers for years. In particular it's capability for static_assert, constexpr, consteval, metaprogramming, etc. The more strict type system is also very welcome. You can still do crazy stuff in C++ if you really want to, but it will be surrounded by many reinterpret_cast and static_cast, which should warrant a programmer that he/she is dealing with something "unsafe" or potentially non-portable here.

It's been years since I've been programming Rust, and I haven't touched it a ton, but it does itch to try it out one day. I think the memory ownership/borrowship is a very interesting concept, but I'm sure it will take some adjustment to learn the new design patterns to become fluent in writing code and implementing anything you want.

[tggzzz]

Hardcoding a few data structures plus algorithms in a particular language isn't going to significantly affect that variability. Nor, in many useful circumstances, will having a modern garbage collector.

Exactly.  People have been harping on these things and specifically the garbage collectors ever since Lisp times - and it wasn't quite a valid argument even back then and is even less today. But it is a fairly good indicator that the person who pulls this out as an argument for or against use of some language or tool doesn't quite understand what they are talking about ...

Just so.

Often their experience is limited to a 30yo undergraduate course that, in passing, mentioned that some weird/niche languages use stop-the-world GCs that are either mark-collect or reference counting.

That wasn't true 30 years ago, let alone now.

[tggzzz]

It's been years since I've been programming Rust, and I haven't touched it a ton, but it does itch to try it out one day. I think the memory ownership/borrowship is a very interesting concept, but I'm sure it will take some adjustment to learn the new design patterns to become fluent in writing code and implementing anything you want.

I've not used Rust but it has been on my radar for years - because it is one of the few which directly addresses a modern challenge: multicore/processor applications. (Ditto Go, at a different level)

How successful the own/borrow concept will be is still being determined, but it is a useful advance over languages whose designers explicitly stated that threading is a library issue

My bet is that it will be useful, and programmers will have to use higher level infelicities to screw things up. (Compare and contrast with a structured procedural language vs assembler)

[Marco]

It was part of a SANS hacking course on webapplications. 10 seconds after a user provided a password, the complete hash could still be found in the memory.

In process memory, but without running untrusted code it's rather unlikely you can remotely get the Java/C# program to escape the sandbox, get at the process memory and send it back to you.

If you do want a sandbox for untrusted code you use JS/webassembly. Out of scope data hanging around in process memory? Who cares ... the sandbox evolved to the point that an escape is so valuable, it becomes almost unusable. Economically guaranteed security is the best security after mathematically guaranteed.

[janoc]

It's been years since I've been programming Rust, and I haven't touched it a ton, but it does itch to try it out one day. I think the memory ownership/borrowship is a very interesting concept, but I'm sure it will take some adjustment to learn the new design patterns to become fluent in writing code and implementing anything you want.

I've not used Rust but it has been on my radar for years - because it is one of the few which directly addresses a modern challenge: multicore/processor applications. (Ditto Go, at a different level)

How successful the own/borrow concept will be is still being determined, but it is a useful advance over languages whose designers explicitly stated that threading is a library issue

My bet is that it will be useful, and programmers will have to use higher level infelicities to screw things up. (Compare and contrast with a structured procedural language vs assembler)

I have started to tinker with it on some toy projects of mine.

Not sure about its specific usefulness on multicore/multiprocessor systems, there it doesn't really bring anything that others don't do or make anything significantly easier. The ownership/lifetime/borrowing doesn't really help you much if you have race conditions due to shared state between threads, etc. - you still need synchronization/mutexes/etc. in some form, the language doesn't handle this for you. The same for ease of parallelization/vectorization of algorithms -  Rust is about the same as C (i.e. there are threads and coroutines - and the rest is up to you) here.

However, what made me look at it in embedded context was the built-in support for the async/away style cooperative multitasking - that could make a lot of very common embedded problems simpler to deal with and without having to resort to an RTOS. Which is always a plus, especially in memory constrained situations.

I have managed to get some code working even on ATMega328 (good old Arduino Uno board) and then, of course, ARM is fairly well supported. Where there are rough edges is the very immature ecosystem where there simply aren't as many packages ("crates") available and what is available are often one-man projects with little support and frequently abandoned. Hardware support often means you get the CPU core supported, code compiles and runs on the chip - but any peripherals beyond the basics like GPIO are up to you to implement drivers for. 

To a lesser degree this is true even for desktop programming with Rust - e.g. I needed 0MQ implementation, there are about 3 out there, one is abandoned, the other is an alpha version that doesn't support what I needed and the third is a buggy mess. But at least there was something out there - if you need something more demanding or more niche, tough luck. Rust has interop with C and it is possible to make even C++ code work with it with some effort but it is far from seamless. And if you are jumping through the hoops to talk to C++ - then why bother with Rust?

So while there are plenty of "rustaceans" that will sing odes to the memory safety and similar things, the reality is that if your use case doesn't fit into the (fairly small) niche where there is good library support already, the language and ecosystem aren't going to be of much use to you. I don't see it replacing C or C++ any time soon, exactly for these reasons. Even the best programming language is of no use when you can't solve your problem with it.


Concerning the language itself, I am a bit on the fence with the syntax - I am a Python/C/C++/C# guy, so I am used to some pretty weird and "noisy" syntax. However, Rust feels a bit like the language syntax hasn't been designed but "grown" - "Oh, crap, we didn't think about this, let's make the programmer write an apostrophe here and there to indicate this!" And that despite that there is no formal standard out yet and the language is still pretty new (~10 years) and still in flux.

Worse, a lot of this "noise" comes from very low-level implementation detail boilerplate that "leaks" out and the user is forced to deal with it explicitly - like annotating the variable lifetimes. In some cases the compiler can infer it but in many it can't, which kinda sucks and leads to "line noise" statements like:

Code: [Select]

fn f<'a, 'b>(s: &'a str, t: &'b str) -> &'str {...}

(that's a function taking two string arguments by reference with different lifetimes annotated by those 'a and 'b annotations and returns a reference to another string)

It is certainly not the worst stuff I have seen and I get why it is necessary for the compiler to know this - ever shot yourself in the foot by operating on a pointer/reference to a temporary that has been destroyed in the meantime? This is what the lifetimes are trying to address in Rust. However, the way it is done is really ... meh.  A bit of wasted opportunity to design a language that isn't "write only" here, IMO.  Of course, C++ is much worse in this regard - but C++ is also  40 years old and carries a lot of historical baggage with it.

[coppice]

An example C# and java with its garbage collector were a goldmine for some epic hacks since the garbage collector was not real time.

Que? 

C isn't "real time" (to repeat your misuse of the term) either!

Start by considering the performance of, say, a cache implemented in C. Then consider the performance effects of all the hardware caches and superscalar operations in a modern processor.

C is as real time as any language specifically known as real time. It doesn't enforce any of the road blocks, like garbage collection, that make real time systems hard or impractical to implement.

[janoc]

C is as real time as any language specifically known as real time. It doesn't enforce any of the road blocks, like garbage collection, that make real time systems hard or impractical to implement.

That just means you are doing/thinking about the real time wrong, that's all.

Pretty much every garbage collected language has means to both disable/delay/control the garbage collector, so that it isn't running during the critical portions of your code and you can often also replace it with your completely custom one too. Or even disable it altogether if you want. Or even replace the entire runtime with your custom one - even for Java. Just like Google did with Android - there Java code doesn't run on JVM but their own custom runtime - first Dalvik, later ART. OK, that is obviously not a real time system but the point stands that one can do that.

Heck, there is even a real time specification for Java being developed, with several implementations already:
https://en.wikipedia.org/wiki/Real_time_Java

For example Erlang is both garbage collected and widely used for real time work, such as in telecom industry.

Whether or not something can be described as real time is really not a function of the programming language used.

[coppice]

C is as real time as any language specifically known as real time. It doesn't enforce any of the road blocks, like garbage collection, that make real time systems hard or impractical to implement.

That just means you are doing the real time wrong, that's all.

Pretty much every garbage collected language has means to both disable/delay/control the garbage collector, so that it isn't running during the critical portions of your code and you can often also replace it with your completely custom one too. Or even disable it altogether if you want. Or even replace the runtime with your custom one - even for Java. Just like Google did with Android - there Java code doesn't run on JVM but their own custom runtime - first Dalvik, later ART. OK, that is obviously not a real time system but the point stands that one can do that.

For example Erlang is both garbage collected and widely used for real time work, such as in telecom industry.

The vast majority of telecoms code is soft real time, and many things can work well for that. Hard real time with decent throughput is another matter. None of the "get out of the way" collectors I've seen are 100% lock free, and just don't get in the way when a real time input, requiring a short hard deadline response, occurs.

[tggzzz]

An example C# and java with its garbage collector were a goldmine for some epic hacks since the garbage collector was not real time.

Que? 

C isn't "real time" (to repeat your misuse of the term) either!

Start by considering the performance of, say, a cache implemented in C. Then consider the performance effects of all the hardware caches and superscalar operations in a modern processor.

C is as real time as any language specifically known as real time. It doesn't enforce any of the road blocks, like garbage collection, that make real time systems hard or impractical to implement.

Realtime language: xC on xCORE has a toolchain that guarantees code execution time to the clock cycle. That is hard realtime!

GC: I have successfully designed and implemented a commercial soft realtime application in Java. The performance amazed those that were used to the equivalent C application, to the extent that another company unexpectedly bought rights to the core part. Application domain: telecoms billing, where some of the customers started throwing chairs around if the calls weren't terminated the second the credit expired.

Reason for the Java application's performance: language primitives that allow for multithread/multicore operation, plus not having to be excessively defensive about ensuring next year's team members won't have used the language or a data structure improperly.

[tggzzz]

C is as real time as any language specifically known as real time. It doesn't enforce any of the road blocks, like garbage collection, that make real time systems hard or impractical to implement.

That just means you are doing the real time wrong, that's all.

Pretty much every garbage collected language has means to both disable/delay/control the garbage collector, so that it isn't running during the critical portions of your code and you can often also replace it with your completely custom one too. Or even disable it altogether if you want. Or even replace the runtime with your custom one - even for Java. Just like Google did with Android - there Java code doesn't run on JVM but their own custom runtime - first Dalvik, later ART. OK, that is obviously not a real time system but the point stands that one can do that.

For example Erlang is both garbage collected and widely used for real time work, such as in telecom industry.

The vast majority of telecoms code is soft real time, and many things can work well for that. Hard real time with decent throughput is another matter. None of the "get out of the way" collectors I've seen are 100% lock free, and just don't get in the way when a real time input, requiring a short hard deadline response, occurs.

Please state which language plus hardware guarantees hard realtime performance. N.B. measuring and hoping you bumbled across the worst case performance isn't a guarantee.

C applications running on (most) modern processors are also soft realtime, for the reasons I've given. Too many people are in denial or blissful ignorance about that.

[janoc]

The vast majority of telecoms code is soft real time, and many things can work well for that. Hard real time with decent throughput is another matter. None of the "get out of the way" collectors I've seen are 100% lock free, and just don't get in the way when a real time input, requiring a short hard deadline response, occurs.

Then write a lockfree garbage collector if that is a requirement? Or disable garbage collection for that critical part? Again, this has zero to do with the language used, that's a matter of the runtime/architecture/etc.

And re soft/hard real time - if one wants to have a meaningful discussion then one should say what are we talking about instead of making blanket statements that "X is not suitable because garbage collector/Y". Soft real time is still real time processing.

And yes, even hard real time can be done in a garbage collected environment. with a formal proof that it will achieve the timing requirements. It isn't common but it is certainly possible and work is being done on it, see e.g. these papers researching the subject:

https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=911647500f989fae31051993e9fe99769ff65b27

https://www.cs.purdue.edu/homes/hosking/papers/rtss09.pdf

[coppice]

C is as real time as any language specifically known as real time. It doesn't enforce any of the road blocks, like garbage collection, that make real time systems hard or impractical to implement.

That just means you are doing the real time wrong, that's all.

Pretty much every garbage collected language has means to both disable/delay/control the garbage collector, so that it isn't running during the critical portions of your code and you can often also replace it with your completely custom one too. Or even disable it altogether if you want. Or even replace the runtime with your custom one - even for Java. Just like Google did with Android - there Java code doesn't run on JVM but their own custom runtime - first Dalvik, later ART. OK, that is obviously not a real time system but the point stands that one can do that.

For example Erlang is both garbage collected and widely used for real time work, such as in telecom industry.

The vast majority of telecoms code is soft real time, and many things can work well for that. Hard real time with decent throughput is another matter. None of the "get out of the way" collectors I've seen are 100% lock free, and just don't get in the way when a real time input, requiring a short hard deadline response, occurs.

Please state which language plus hardware guarantees hard realtime performance. N.B. measuring and hoping you bumbled across the worst case performance isn't a guarantee.

C applications running on (most) modern processors are also soft realtime, for the reasons I've given. Too many people are in denial or blissful ignorance about that.

No modern combination of language and hardware will get you to hard real time performance on their own.

I've implemented DSP solutions where the core clock was PLLed to the incoming data clock; the core, like most DSP cores, was always cycle accurate; the code was crafted so every path through it was exactly the same length; and that length was tuned to be the exact interval between incoming data samples. Once synced up code didn't even have to spend time waiting for the next input sample to be ready. Being cycle accurate, it just took the next input sample on the right clock cycle. Few people want to implement solutions like that, but it was very hardware efficient at the time.

There isn't much around today that you can do something like that with. Even if you turn off the caches, almost everything is pipelined and pipelines are chaotic. However, without the cache in your way, the pipelines do have an absolute worse case. Its a while since I used one, but there are tools which will take your code and figure out true worst case cycles through any path in the code. You can still build hard real time solutions. The language and hardware issues are not whether the make for a hard real time solution. The issue is whether they get in your way or totally block you.

[coppice]

The vast majority of telecoms code is soft real time, and many things can work well for that. Hard real time with decent throughput is another matter. None of the "get out of the way" collectors I've seen are 100% lock free, and just don't get in the way when a real time input, requiring a short hard deadline response, occurs.

Then write a lockfree garbage collector if that is a requirement? Or disable garbage collection for that critical part? Again, this has zero to do with the language used, that's a matter of the runtime/architecture/etc.

And re soft/hard real time - if one wants to have a meaningful discussion then one should say what are we talking about instead of making blanket statements that "X is not suitable because garbage collector/Y". Soft real time is still real time processing.

And yes, even hard real time can be done in a garbage collected environment. with a formal proof that it will achieve the timing requirements. It isn't common but it is certainly possible and work is being done on it, see e.g. these papers researching the subject:

https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=911647500f989fae31051993e9fe99769ff65b27

https://www.cs.purdue.edu/homes/hosking/papers/rtss09.pdf

Those papers are quite old. I'd have to re-read them to remember all they said. However, I so remember them as are very hand wavy about aspects of the problem, only attempting a formal proof of a part of it.

[tggzzz]

C is as real time as any language specifically known as real time. It doesn't enforce any of the road blocks, like garbage collection, that make real time systems hard or impractical to implement.

That just means you are doing the real time wrong, that's all.

Pretty much every garbage collected language has means to both disable/delay/control the garbage collector, so that it isn't running during the critical portions of your code and you can often also replace it with your completely custom one too. Or even disable it altogether if you want. Or even replace the runtime with your custom one - even for Java. Just like Google did with Android - there Java code doesn't run on JVM but their own custom runtime - first Dalvik, later ART. OK, that is obviously not a real time system but the point stands that one can do that.

For example Erlang is both garbage collected and widely used for real time work, such as in telecom industry.

The vast majority of telecoms code is soft real time, and many things can work well for that. Hard real time with decent throughput is another matter. None of the "get out of the way" collectors I've seen are 100% lock free, and just don't get in the way when a real time input, requiring a short hard deadline response, occurs.

Please state which language plus hardware guarantees hard realtime performance. N.B. measuring and hoping you bumbled across the worst case performance isn't a guarantee.

C applications running on (most) modern processors are also soft realtime, for the reasons I've given. Too many people are in denial or blissful ignorance about that.

No modern combination of language and hardware will get you to hard real time performance on their own.

I've implemented DSP solutions where the core clock was PLLed to the incoming data clock; the core, like most DSP cores, was always cycle accurate; the code was crafted so every path through it was exactly the same length; and that length was tuned to be the exact interval between incoming data samples. Once synced up code didn't even have to spend time waiting for the next input sample to be ready. Being cycle accurate, it just took the next input sample on the right clock cycle. Few people want to implement solutions like that, but it was very hardware efficient at the time.

There isn't much around today that you can do something like that with. Even if you turn off the caches, almost everything is pipelined and pipelines are chaotic. However, without the cache in your way, the pipelines do have an absolute worse case. Its a while since I used one, but there are tools which will take your code and figure out true worst case cycles through any path in the code. You can still build hard real time solutions. The language and hardware issues are not whether the make for a hard real time solution. The issue is whether they get in your way or totally block you.

xC + xCORE gives you hard realtime guarantees. It helps (more than a little!) that there are no caches, no interrupts, no pipelines. Just 32 cores 4000MIPS. IDE+tools examines the object code to show execution clock cycles of all paths between here and there, including for optimised code.

But apart from that, I agree.

GC and caches/NUMA/multicore/etc all screw up hard realtime guarantees. Hence - back to my point(!) - there's little validity to this contention: .....

An example C# and java with its garbage collector were a goldmine for some epic hacks since the garbage collector was not real time.

Que? 

C isn't "real time" (to repeat your misuse of the term) either!

In C you still have the choice how you manage memory yourself. In Java, C#, Python, etc. you don't.