Hacker News Reader

Hacker News

Comment by izacus | Hacker News Reader

Parent Full thread

izacus

No, Go isn't appropriate for these things. Use the best tool for the job

View on HN

Can you please explain why Go isn't appropriate here?

Go is garage collected

Binary size, for one. The blog mentions a binary file grew from 220kb (C) to over 400kb (Rust).

I also doubt a garbage-collected language work very well for drivers that require precise timing (MMIO) and/or control over memory allocation.

It worked rather well for Xerox PARC, TI, Genera and others, had they not mismanaged their products, or fighting against workstations being built with a free beer OS.

The blog immediately put that statement into context, stating that the binary file actually ended up replacing most of their stack. At the end of the day, they ended up with about the same size binary size. Also, they were not even really trying to optimize for size.

The non-JVM code used in mentioned context will run in environments where yet another GC fighting the JVM GC isn't desired or have to be a shared library talking to existing JVM code. While you can use Go to build libraries with C calling convention, it's not the most supported use case and it shows in ergonomics. This also includes standard Go types and standard library which don't fit nicely into a model where code needs to talk a lot with JVM world.

It's possible... But it feels like screwing screws with a knife. It's doable, but noone from the language designers, stl designers and library developers are really thinking about that use case.

Rust on the other hand fits very well into the model where it needs to be just a piece of a bigger whole - it's been built that way ("system" programming language) and it doesn't come with GC that will fight with JVM or Binder lifetimes, compatible type system and plenty of libraries that help develop libraries on an embedded platform. When building the language, Rust designers consider this as one of the main use cases of the language and it shows with how much less hassle it is to work with.

The fact that it easily fits into existing C/C++ codebases helps too.

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.

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

> 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-...

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.

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.

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

Reply on news.ycombinator.com