> Low-resource embedded systems are a no-go.

Only if talking about microcontrolers with few hundred KB, where even C is a challenge.

There are Java and Oberon implementations for single digit MB, like Cortex-M4.

> There are Java and Oberon implementations for single digit MB, like Cortex-M4.

So? Just because you can use a language on a given system doesn't mean that you should use it in any serious context.

A GC typically makes memory usage and execution latency non-deterministic, or at the least very hard to analyze. If your washing machine software OOMs whenever the GC didn't run between two button pushes, you'll have a great Heisenbug.

Well, I happen to consider factory control management, weapon targeting and missile tracking systems, some big serious context.

Here is just one of them.

http://www.militaryaerospace.com/articles/2006/10/lockheed-m...

"PERC Ultra offered Lockheed Martin the responsiveness it needed to meet its most demanding timing requirements. In addition to real-time threading and deterministic garbage collection, PERC Ultra provided the instrumentation and VM management tools necessary to support the mission-critical real-time requirements of the Aegis Weapon System."

"The Lockheed Martin-developed Aegis Weapon System is the sea-based element of the U.S. Ballistic Missile Defense System. The Aegis Weapon System is a radar and missile system integrated with its own command and control system, capable of simultaneous operation defending against advanced air, surface, and subsurface threats."

Is that serious enough for you?

Is this where we bring in the anecdote about the missile flight control system which never freed any memory, because the minumum time to OOM was less than the maximum flight time of the missile?

Ask and ye shall receive[0].

[0] https://news.ycombinator.com/item?id=14233542

> A GC typically makes memory usage and execution latency non-deterministic, or at the least very hard to analyze.

You could say same about malloc and free. Not deterministic at all either. Memory fragmentation is a huge issue as well, and can bring down the whole system.

Typical GC (not all flavors) has a huge advantage on microcontrollers: you gain ability to compact heap. No more fragmentation.

That said, mostly I try not to dynamically allocate anything in firmware or kernel drivers. Whenever possible. Sometimes I write my own specialized allocators. For example a simple wait free allocator fast and rugged enough to call from an interrupt service routine.

> Only if talking about microcontrolers with few hundred KB, where even C is a challenge.

C is the default and not a challenge on 8-bitters.

So which compiler does offer 100% ANSI C compliance on something like a Z80 or PIC?

SDCC is standard compliant (even up to C11) and has support for Z80: http://sdcc.sourceforge.net/

Thanks for pointing it out, I wasn't aware of it and it does look good, but they clearly state the uses cases which it isn't fully ANSI C compliant on page 24 of the documentation.

I think you're nitpicking.

That's close enough in my book. Those MCUs are tricky targets and I can certainly live for example with not being able to pass structs as return values. Or without re-entrancy. Perfectly understandable once you take into account limited IRAM space, 128 or 256 bytes, where stack, register banks and most of your temporaries and globals need to reside.

Which validates my point of using C on 8 bit CPUs being a challenge.

"Less than absolutely total standard compliance" != "a significant challenge compared to absolutely total standard compliance", especially if the differences are clearly documented.

The challenge is not being able to write idiomatic ANSI C, rather trying to tame the compiler to produce code comparable to hand tuned Assembly to fit into those processors, the majority of time using compiler specific extensions.

You're sounding like a propagandist - like you want to just argue your talking points, rather than actually have a conversation where you listen to what the other side is actually saying. It makes you a real pain to talk to.

Just in case you're actually trying to engage in good faith, though, I'll try this one more time. If I have a compiler that is less-than-100% standards compliant, I may not be able to use a few features of the standard. That means there may be a few ANSI C idioms that I can't use. Of those, the number that I would choose to use on that size of processor is very, very few. So in practice, there is no "challenge".

Why would I use very few of these features? Because on a processor that size, you're not writing a huge app. You don't use all the functions in the standard library, you don't use all the keywords, you usually don't push the language very far at all. At worst, you might have to develop one or two idioms of your own. It's... mildly annoying, rather than the big deal you're trying to make it.

It is not a challenge, it is by far the most common way to program them.

Yeah not being able to write idiomatic ANSI C, rather trying to convince the compiler to produce code comparable to hand tuned Assembly to fit into those processors, the majority of time using compiler specific extensions.

SDCC is also full of bugs and the compiled code is not well optimized. For a low level CPU like that, you have to write assembly at some point.

I wrote smaller programs with it for a Z80 home computer which originally didn't have C support. I didn't encounter bugs, but it's true that the code generation is less than optimal for Z80 when compared to manually written assembly (understandable because of the small register set), but the compiler supports mixing assembly and C very well, so no complains here :)

Literally the whole industry doesn't care two bits about "100% ANSI C compliance", which I'd guess isn't even possible on a pure Harvard architecture like AVR or PIC.

Even the ESP8266, where ram & flash are measured in kilobytes can run a minimal version of python. This whole "low resource can't run heavy languages" trope needs to die.

Comparison of a sensor fusion algorithm the likes of which are used in quadcopters:

| impl | c | py3 | mpy | pypy3 | cy3 |

|------|-------|--------|---------|-------|-------|

| [ns] | 0.176 | 11.462 | 37.633 | 0.818 | 0.590 |

| .c | 1.000 | 65.126 | 213.824 | 4.648 | 3.352 |

mpy - MicroPython

cy3 - Cython

So, ... low resource can't run heavy languages fast (yet?). Good thing is by using MicroPython and writing the time critical stuff in C you can get the best of both worlds while paying the least.

edit: sigh, markdown table

If you add two spaces in front of each line, it formats as monospace. Like this:

  | impl | c     | py3    | mpy     | pypy3 | cy3   |
  |------|-------|--------|---------|-------|-------|
  | [ns] | 0.176 | 11.462 |  37.633 | 0.818 | 0.590 |
  | .c   | 1.000 | 65.126 | 213.824 | 4.648 | 3.352 |

Also, I'm taking a guess here and assuming that the values in the second line mean "execution time as multiples of the execution time for C".

Yes, it was `*c`, but the star screwed up formatting even more ;)

Why does GC make it harder to call libraries in other languages?

When you're working in a GCed language you assume your language's GC is responsible for freeing memory. When you interoperate with a language where owners are responsible for freeing memory, you have to have a way to "disown" structures you've created but passed into the ownership language (e.g. a callback you've passed to a library function) so that your GC doesn't free them, and a way to "own" structures you've received from the ownership language (e.g. values returned from library functions) so that your GC does free them, and neither of these things will be easy/natural in your language.

When you interoperate with another GCed language it's even harder, virtually impossible, because both languages' GCs assume they own everything and so anything that's visible in both languages will be freed twice.

Well, declaring untraced references in Modula-3 or Active Oberon, or doing native heap allocations in Nim, D, Java and C# is relatively simple.

Using GC languages doesn't mean doing 100% memory allocation via GC.

I've done it in Java; it's not officially supported in the language standard (or has only recently been added if so - certainly they were talking about it for years), and the wider language does not generally have the support or idioms you would want (e.g. try-with-resources was only introduced a couple of versions ago), libraries aren't oriented towards that style.... It's certainly doable but I'd stand by it not being easy or natural.

Although I mentioned Java, due to ByteBuffers and Unsafe, it is clearly not the best one of the set of languages that I mentioned.

Others on that list have specific language features for GC free allocation.

Languages interfacing through an ABI implicitly need to agree on their memory models, calling conventions, exception unwinding, etc.

There's lots of detail in the D language garbage collection docs:

https://dlang.org/spec/garbage.html

The whole thing might be instructive, but 28.3.3 has a bunch of particular expectations of the D GC.

Because you have to add support for GCing of foreign structures from these libraries, or keep the interface low-level and force the user of the GCed language to manually manage these foreign objects. Adding support for GC can be difficult if not impossible, because GCs often arrange memory in special ways (different pools, etc.) whereas the foreign library probably just uses malloc.

What I meant was: If language X needs a GC, then writing a library in X makes it difficult and very inconvenient to use that library from another language.

The comments of jonathanstrange and humanrebar are also spot-on.