Garbage collection and goroutines. You could probably strip back the implementations a bit but you can't get rid of gc - there is no explicit way of freeing memory. Possibly you could ban the go keyword and run on a single thread, although you'd have to deal with parts of the stdlib that use it.
https://github.com/ziutek/emgo/blob/master/README.md
https://github.com/ziutek/emgo/issues/14#issuecomment-398670...
https://ziutek.github.io/2018/03/30/go_on_very_small_hardwar...
Do you think the specification is "correct" for a compiled language suitable for embedding?
The word "garbage" is in the specification a single time, in the introduction which says "garbage-collected". I can't see any constrained implementation details thereafter - see for yourself at where I might have missed it:
The gouroutine section (under the Go keyword) is three paragraphs: "A "go" statement starts the execution of a function call as an independent concurrent thread of control, or goroutine, within the same address space." and "The function value and parameters are evaluated as usual in the calling goroutine, but unlike with a regular call, program execution does not wait for the invoked function to complete. Instead, the function begins executing independently in a new goroutine. When the function terminates, its goroutine also terminates. If the function has any return values, they are discarded when the function completes. "
This does not seem to require the typical accoutrements of the Go compiler. If this is the complete verbiage specifying the behavior of a Goroutine, I could imagine a compliant implementation being lighter-weight than the official Go compiler.
Returning to the idea of GC: the word "memory" appears in the standard 4 times: once mentioning initialization of variables; once on the section on slices ("The built-in functions append and copy assist in common slice operations. For both functions, the result is independent of whether the memory referenced by the arguments overlaps. "); and twice in the last section on system considerations, including light MAY language in "Computer architectures may require memory addresses to be aligned; that is, for addresses of a variable to be a multiple of a factor, the variable's type's alignment. The function Alignof takes an expression denoting a variable of any type and returns the alignment of the (type of the) variable in bytes." and finally under Size and Alignment guarantees, which makes no reference to GC.
If this document is the complete specification, then it seems that the implementer has very wide leeway for how to implement the details of memory management via garbage collection. There doesn't seem to be much language limited behavior.
What do you think?
(In this comment I consider "Go" the language as anything that complies with the Go specification.)