Comparing Go vs. C in embedded applications – Stack Overflow Blog

One of my favourite Go posts from awhile ago was a Go v Java/C where both beat Go handily in speed. The author then went on to declare the winner Go b/c Go used less mem than Java and had mem management while C didn't.

This led me to Randy's Law of Benchmarking: Unless an author publishes what result they want beforehand, any benchmark the author produces is invalid.

Corollary: Even the ideation of a benchmark has bias embedded in it.

This is not an article about running go applications on mcus (kb of memory) but rather cpus (mb / gb of memory) as the author mentions Linux and hardware like the raspberry pi series. Not to knock it but there’s quite a range for what people call “embedded software”. I was hoping for some insights into running go with constant time garbage collection or not having to link the standard library.

> Impossibly tight deadlines, unrealistic schedules, and constant pressure to develop and release applications on time, while at the same time achieving excellent quality. Sound familiar?

I can understand that this article, being an Ad for this company called "Mender", they try to generate "urgency" focusing on software. I didn't feel that any of the points touched in the article were for embedded applications; just high-level stuff that runs on an embedded platform with a fully working OS/kernel; Applications at that level can be written in Go, Java, Xamaring, Python, etc.

I was never rushed to finish a final product (in my 20 years of embedded firmware/BSP development). And I've never see it happen to my colleagues. Perhaps to some high level, Android/Java/Xamarin application developer (but I don't consider these to be fully "embedded applications").

Or we might have been rushed to finish a "hacked-together" demo, but hey, it's a demo and may be broken by design.

Also some areas of embedded are dangerous and can cause real harm to people and property, so there is no rushing there as there may be in other software areas/industries.

Many, if not most, embedded applications go through some kind of certification. This can take a while. And there are other internal tests we do, like climatic chamber, burn-in, mechanical, etc. Embedded doesn't limit to software, and it's rarely a one-man-team.

Latency, Latency, Latency!

Go would never be able to outcompete C in real-time OS applications.

Because of frequent requirements of sub-microsecond response are often found in design of embedded targets, Go is often the first casualty of a language selection during hardware design. Although there might be some TinyGo looming on the horizon, just to deal with that ornery requirement type.

Unless you’re designing a Tamagotchi toy or something.

https://tamagotchi.com/

TIL in Go: "if you want to switch on or off garbage collection (GOGC=off)"

I was expecting to see something about TinyGo