4 ms·

I'm curious what you think the primary feature is that makes a Go runtime have to be necessarily large? (If writing a new Go runtime against the specification.

I'm curious what you think the primary feature is that makes a Go runtime have to be necessarily large? (If writing a new Go runtime against the specification.) You mention the need for a runtime, but I don't see that this makes it necessarily huge. For comparison, I'd like to think about using a TinyC compiler[1], called TCC, as a complete runtime to compare against since: " * TinyCC (aka TCC) is a small but hyper fast C compiler. Unlike other C compilers, it is meant to be self-relying: you do not need an external assembler or linker because TCC does that for you. * TCC compiles so fast that even for big projects Makefiles may not be necessary. * TCC not only supports ANSI C, but also most of the new ISO C99 standard and many GNUC extensions including inline assembly. " Now it turns out that the above fits in 100 KB and implements "ANSI C", which for the C89 version is 552 pages or so[2]. The Go specification is 73 pages or so in the same font. (So 13% of the size.) I also think that due to its design the Go language specification and syntax has fewer corner cases. So clearly there is some "huge" feature that is really holding things back from running on a resource-constrained microcontroller in a stripped-down runtime. What is it? To see where 100 KB fits (by analogy with TCC above), I looked up some microcontrollers. I first found a popular microcontroller for hobbyists, the ATmega2560 which runs the Arduino Mega. That microcontroller has 56KB ISP flash memory, 8KB SRAM. That RAM is not enough if we take the TinyC executable of around 100 KB as how much is needed. This microcontroller also only costs $6.5 in quantity 1 (unless I misread.) Moving up a bit in price so we can get at least 128 KB of RAM, a popular choice is something like the AT32UC3A3256[3] which costs $31.25 in an evaluation kit (that gives you an additional 8 MB of RAM), and as far as shipping just the MCU (with its 128KB of RAM only), costs $12 in quantity one. That is a 32-bit device unlike the cheaper Atmega2560 I first mentioned (which is an 8-bit device) so should be easier for people to implement the standard against. The specifications are: 84 MHz, 256 kB program size, 128 kB RAM size. Why can TCC be 100 KB executable size but independently implementing the Go specification can't? As for why someone would want to, sure, you're going to be quite constrained, but if someone already knows Go, which had the design goal of being a general-purpose language, why can't they use its syntax for their microcontroller projects? So what essential feature in the Go specification makes this an absolute non-starter? it's a super small standard. (As for your second response, about "You rarely see native desktop applications in anything other than C++ ", I read what you wrote but I don't see why the Go ecosystem isn't slowly catching up anyway. It's a great language syntax.) --- [1] https://bellard.org/tcc/ https://bellard.org/tcc/ and https://bellard.org/tcc/tcc-doc.html https://bellard.org/tcc/tcc-doc.html [2] found a draft here - http://www.open-std.org/JTC1/sc22/wg14/www/docs/n1256.pdf http://www.open-std.org/JTC1/sc22/wg14/www/docs/n1256.pdf [3] I found this recommendation here: https://electronics.stackexchange.com/questions/192583/is-there-a-microcontroller-with-16mb-of-ram https://electronics.stackexchange.com/questions/192583/is-th...

CamouflagedKiwi 8y ago
> So clearly there is some "huge" feature that is really holding things back from running on a resource-constrained microcontroller in a stripped-down runtime. What is it? 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.
- logicallee 8y ago
  >Garbage collection and goroutines 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: https://golang.org/ref/spec https://golang.org/ref/spec 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.)

CamouflagedKiwi 8y ago

> So clearly there is some "huge" feature that is really holding things back from running on a resource-constrained microcontroller in a stripped-down runtime. What is it? 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.

logicallee 8y ago
>Garbage collection and goroutines 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: https://golang.org/ref/spec https://golang.org/ref/spec 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.)