That's not really what I meant. The example is showing the problem, the transition to manual memory management just makes it a bit easier to write a program without memory operations in critical sections.

What I'm talking about is a hypothetical language that makes memory operations in critical sections forbidden and considered a compilation error.

A discussion about GC and memory management can be found here https://github.com/edubart/nelua-lang/discussions/70

Maybe it can answer to some parts of your reasoning? :/

> What I'm talking about is a hypothetical language that makes memory operations in critical sections forbidden and considered a compilation error.

This is easy to do in C, and you'll see it in embedded code. A simple preprocessor macro that redefined malloc to something that causes an error.

To enable malloc in some chunk of code (embedded defaults to "malloc is bad"), you can define it accordingly in the .c files that need it.

This is possible in Nim using the "soft real-time" GC with "GC_step Mode" see https://nim-lang.org/docs/gc.html. You can even tell the GC how much time it can pause.

But Nim also has a new deterministic GC, that has been available since 2020 and will be the default in a future version, see: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...

In fact, I see many similarities between Nelua and Nim.

> In fact, I see many similarities between Nelua and Nim.

I am the Nelua author, and I've used Nim for a reasonable amount of time before creating Nelua, thus Nim served as one of the inspirations for the project and they share similarities. But while Nim resembles Python, Nelua resembles Lua. Also when comparing both, Nelua tries to be more minimal and generate more readable and compact C code.

Nice! It looked like there were a lot of similarities. Fun language looking language you made.

D has the @nogc attribute. Using it to make memory allocation forbidden in parts of the codebase.