[okanat]

Not just garbage collection but also the way hardware work is done with languages that allow you to write one-to-one memory representations in order to be able to drive raw interfaces of hardware. A GC language almost always comes with a reference based type system that hides the very interfaces you'd like to access (fast) and adds deserialization overhead which has visible performance and battery life effects.

The other reason is C interoperation. All of the common systems rely on C. C is not just a programming language. Since 80s everybody designs systems on top of C. We ended up with OSes written in C that ship their tightly integrated C compiler that outputs binaries optimized for C's memory layout and primitives that the very same OS runs on silicon that's optimized to run C fast. C unfortunately became the meta-language of the low level APIs.

Go's interoperability with C is out of hell. Its green-thread scheduler doesn't play well with C. The foreign function interface is defined in the comments (!) of a source file and making CGo work on custom cross toolchains is full of hard to solve compiler errors.

Rust can operate at the same level as C easily and it has all the low level primitives. C interoperability is a core language function that's part of the syntax and standard library. It solves many gotchas of C without compromising speed.

[pjmlp]

> Since 80s everybody designs systems on top of C.

More like since the 1990's, as outside UNIX during the 1980's no one cared about C, and mostly thanks to the GNU Manifesto and FOSS uptake that took the steam out of C++ adoption being pushed by Apple, IBM and Microsoft.

There is firmware in production written in Go,

https://www.withsecure.com/en/solutions/innovative-security-...

[defrost]

I did a lot of cross platform development work from 1982 onwards and 1987 was very much the year of C for Intel | DOS machines - they were cheap (comparitively), widely available and Borlands Turbo C was a fully integrated IDE that was affordable (and|or pirated) with some outstanding manuals.

Between that and their ASM for low level work, C took off in a big way and Pascal sharply dwindled in popularity (although it still hung on for a long time, even up to the present).

https://en.wikipedia.org/wiki/Borland_Turbo_C

There were better more expensive tools, but that was the product that planted a flag for widespread C development.

[pjmlp]

In Europe, in a MS-DOS world without cross-platform considerations, it took until Windows 3.x release, and Watcom C++ with its DOS extender for folks to really care about C and C++.

In fact, we used Turbo C 2.0 to prepare our code samples to deploy them into a single Xenix computer shared across the whole school, and that was it, nothing else.

[defrost]

Watcom was a much much better compiler and was welcomed with open arms to be sure - I still have a copy of the last release and use it on occassions.

If we're waxing historic here, my first C compiler (of my own and not a university VAX | PDP version) was the Cain | Hendrix Small C compiler (released 1980) which I handcopied in 1982 and extended over the next year or three as I read the Dragon books and other works .. bit of a side exercise while doing an engineering degree and working on a sheep shearing robot.

Thank-you Dr. Dobb's Journal of Computer Calisthenics & Orthodontia

https://en.wikipedia.org/wiki/Small-C

[hactually]

I disagree - working with CGo is really easy and predictable in behaviour.

Cross compilation for Go is no more difficult than cross compiling Rust + .so / .a files