Comments by "Anony Mousse" (@anon_y_mousse) on "an 8-bit microcontroller but it has a garbage collector" video.

I'm sure you've already figured it out by now, but the lower power draw is because the Go program isn't spending that much time freeing memory. It's kind of a lazy evaluation technique for free(). I would be interested in long term averaging of the power consumption, as I'd bet it would even out. Though, I'd rather use C++'s technique of automatically calling destructors when objects fall out of scope. Then you'd have more memory readily available when you need it for repeated allocations. Using a GC may lead to hitting that boundary too often and having to wait on it to run the collection thread. Slowdowns like that should probably be avoided in an embedded context.
29
@grafspee9463 Sounds like I triggered another bad programmer. When a good programmer writes their code, they simply pair things. There's no huge investment of time in doing that. At the end everything works because you wrote it correctly and there are no leaks. The hitch of a GC might seem small on a desktop, but on an embedded device it's a killer. It can cause the device to freeze up permanently as things are being waited on and don't occur in a timely manner.
6
Not so much based on bad language design, though Go is bad, but on bad programmers being too prevalent. GC isn't necessary if you're a good programmer and is generally a negative in every way.
4
@mgord9518 Nice attempt at a troll. Of course you're forgetting those systems which come with a standard library built in and thus it adds no overhead. For instance, the PS1 had a good portion of the C standard library built into the BIOS.
3
@mgord9518 A standard library embedded into the BIOS is most definitely going to be written in hand optimized assembly. And while there is overhead with calling functions, that overhead is consistent and predictable as well as capable of working in a single threaded environment. I know you think you're making a valid point, but at a certain point you have to balance productivity with functionality. With a GC, there is no such balance as it needs its own thread, which isn't always possible on embedded platforms, and it has an unpredictable runtime performance.
3
@mgord9518 I don't know if you're serious or still trolling. The BIOS is no slower for having a standard library embedded with it than without. Code that you don't execute doesn't take processing cycles, and a standard library in the BIOS will be faster than one you write yourself as long as they optimize it, which they very likely did.
2
@baxiry. From the TinyGo website they claim GC is supported on all platforms. Are you saying that's a lie or just inanely pointing out that you can turn off GC if you make the effort?
1