[eatonphil]

You can't even call a non-Go library without switching to cgo, which contradictorily basically everyone says not to use.

Leaving aside the GC, until Go has a real FFI it's hard to to imagine it being a really great fit for systems programming when the systems are all not written in Go.

[User23]

Go is not a traditional systems programming language and calling it one is misleading at best and maybe even borderline dishonest. Two big problems are the lack of control of memory layout and the lack of some form that compiles down to a computed goto. It’s just not possible to write performant systems code without those.

I’m not bashing Go though. I appreciate the focus on readability among other things. It’s a fine language for the use cases it was actually designed for, like pushing petabytes of ad data to serving clusters all around the world with acceptable latency and reliability.

[pjmlp]

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

I guess the Genera, Xerox PARC, ETHZ, Microsoft folks are borderline dishonest.

[User23]

I would say that they evidently felt the need to write a new compiler and runtime, which appears to be a species of agreement with my thesis.

[pjmlp]

Apparently writing compilers isn't systems programming....

[User23]

In my prior comments above and in all the following I use "language" in the typical way, which is to say referring to not just the syntax but the semantics of the standard toolchain and runtime as well. I wanted to clarify that since perhaps there is some confusion there. So when I talk about Go I'm talking about what I get here[1] as is everyone else who isn't explicitly specifying some other implementation.

Writing compilers is not systems programming in the sense that it requires a systems programming language, no. One could easily write a C compiler in Ruby, but we don't consider Ruby to be a systems programming language.

Thus, obviously, Go, despite not being a systems programming language, could be used to write the compiler for a systems programming language. I guess that is what Tamago is? I'm not going to read through the source to find out and the web page you linked is boring marketing copy.

[1] https://go.dev/dl/

[pjmlp]

Go compiler toolchain is written in Go.

TamaGo is a bare metal runtime for unikernels, whose main use is a commercial product for secure USB keys, sold by F-Secure.

Back on my youth, writing compilers was considered systems programming, in parity with kernel drivers, how things change.

I guess writing userspace drivers in hybrid kernels is also not considered systems programming.

[eatonphil]

Yes I agree it's a nice language. But the FFI situation is mildly infuriating.

[pjmlp]

You can use the same FFI as K&R C, write a couple of Assembly helpers.

[eatonphil]

Any links to help me understand what you mean about the K&R C FFI? (Not easy to google for)

Possibly related, building against foreign objects and manually setting up the FFI call: https://words.filippo.io/rustgo/.

[pjmlp]

Easy, K&R C was rather limited, inline Assembly wasn't yet a common extension, rather you would use the external assembler, and link both object files together.

What was good for C while it was gaining adoption, surely is good enough for Go.

[eatonphil]

Gotcha, that is along the same lines as the link I shared.

[pjmlp]

For example,

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

https://github.com/trcwm/smallc_v1