5 ms·

> Overall, pretty weird stuff. I am not sure why the Go team went down this route. Maybe it simplifies the compiler by having this bespoke assembly format? Rob

> Overall, pretty weird stuff. I am not sure why the Go team went down this route. Maybe it simplifies the compiler by having this bespoke assembly format? Rob Pike spoke on the design of Go's assembler at a talk in 2016 [1][2]. I think it basically came down to the observation that most assembly language is roughly the same, so why not build a common assembly language that "lets you talk to the machine at the lowest level and yet not have to learn a new syntax." It also enables them to automatically generate a working assembler given an instruction manual PDF for a new architecture as input. [1]: https://www.youtube.com/watch?v=KINIAgRpkDA https://www.youtube.com/watch?v=KINIAgRpkDA [2]: https://go.dev/talks/2016/asm.slide#1 https://go.dev/talks/2016/asm.slide#1

alphazard 2y ago
And it worked. Go established cross-compilation as table-stakes for new programming languages, at a time when very few were doing it well, if at all.
- p_l 2y ago
  Go essentially copied the design from Plan9 compilers, which it was originally based on. It's one of the many things it inherited from Plan9 environment.
  - kjksf 2y ago
    It's more "reused" because Plan9 compilers were designed / co-implemented by Pike / Thomson, 2 out of 3 original designers of Go. For those interested, here's Thomson's paper about Plan9 C compilers: https://9p.io/sys/doc/compiler.html https://9p.io/sys/doc/compiler.html and https://doc.cat-v.org/bell_labs/new_c_compilers/ https://doc.cat-v.org/bell_labs/new_c_compilers/
    - derefr 2y ago
      I would love to see a deep dive on what features / architectural paradigms the Golang runtime shares with Plan9. Has anything like that been written? One that always sticks out to me personally is the use in Go of the term "dial" instead of "connect" for network connection establishment. This is, AFAICT, another Pike+Thompson-ism, as it can be seen previously in the form of the Plan9 dial(3) syscall — https://9fans.github.io/plan9port/man/man3/dial.html https://9fans.github.io/plan9port/man/man3/dial.html . --- A tangent: I have wondered before whether Pike and Thompson drafted the design for the language that would become Golang long before working at Google, initially to replace C specifically in the context of being the lingua-franca for systems programming on Plan 9. And that, therefore — at least in the designer's minds — Golang would have always had Plan9 as its secret "flagship target" that it should have a 1:1 zero-impedance abstraction mapping onto. Even if they never bothered to actually make a Plan9 Golang runtime. You could test this hypothesis by implementing an actual Golang runtime for Plan9†, and then comparing it to the Golang runtimes for other OSes — if Plan9 were the "intended home" for Golang programs, then you'd expect the Golang runtime to be very "thin" on Plan9. (To put that another way: imagine the Golang runtime as something like WINE — a virtualization layer that implements things that could be syscalls / OS library code, in the form of client-side runtime shim code. A "WINE implementation for Windows" would be an extremely thin shim, as every shim call would just point to a 1:1-API-matched piece of OS-provided code. My hypothesis here is that "Golang for Plan9" is the same kind of thing as "WINE for Windows.") † I was saying this as a thought experiment, not thinking there would actually be a Plan9 implementation of the Golang runtime... but there is! (https://go.dev/wiki/Plan9 https://go.dev/wiki/Plan9) So someone can actually check this :)
      - mbivert 2y ago
        > I would love to see a deep dive on what features / architectural paradigms the Golang runtime shares with Plan9. Has anything like that been written? If it has, then it's most likely available on https://cat-v.org/ https://cat-v.org/. Even if it hasn't, cat-v.org is a great starting point. Besides, close to your line of thought, and assuming you didn't knew about this already, Pike & al previously worked on Limbo[0], a "predecessor" of Go, used to wrote Inferno[1], a Plan9-like OS, which could be hosted on arbitrary OSes via a bespoke virtual machine called "Dis". So there were indeed a few previous "drafts" for Go. I'd doubt that Go has been designed "for" Plan9 though. [0]: https://en.wikipedia.org/wiki/Limbo_(programming_language) https://en.wikipedia.org/wiki/Limbo_(programming_language) [1]: https://en.wikipedia.org/wiki/Inferno_(operating_system) https://en.wikipedia.org/wiki/Inferno_(operating_system)
        exitb 2y ago
        There’s also libthread[1] which implements concurrency model similar to goroutines (at least earlier, as they appear to be no longer just cooperatively scheduled?). That manual also mentions Alef and Newsqueak as influential predecessors. [1] http://man.9front.org/2/thread http://man.9front.org/2/thread
      - gavindean90 2y ago
        It sort of was and Rob blogged about it. It is based really on Newsqueak and plan9 C which is very different from Unix C
      - pram 2y ago
        I'd guess dial is probably a Bell Labs-ism
- cloudfudge 2y ago
  Yes, this is a great leap forward in my opinion. I had to do a project at a previous job where I wrote an agent that ran on x86, MIPS and ARM, and doing it in Go was a no-brainer. The other teams who had a bunch of C code that was a nightmare to cross-compile were so jealous they eventually moved a lot of things to Go. I've been doing this for 35 years and cross compiling anything nontrivial was always a toolchain nightmare. Discovering a world where all I had to do was set GOARCH=mips64 (and possibly GOOS=darwin if I wanted mac binaries) before invoking the compiler is so magical I was extremely skeptical when I first read about it.
  - bombela 2y ago
    As long as you don't have C libraries to cross compile / link against of course ;)
    - akira2501 2y ago
      sqlite is the only thing that makes me sad I have CGO_ENABLED=0.
      - thombles 2y ago
        This non-cgo port might help - I started using it recently and it's fine but I'm not exactly a demanding user https://pkg.go.dev/modernc.org/sqlite https://pkg.go.dev/modernc.org/sqlite
        KyleSanderson 2y ago
        It's still pretty slow, but overall correct. There's tricks, like reader connections and a single writer connection to reduce contention. There was a blog post on here detailing some speedups in general.
      - anacrolix 2y ago
        Use the new sqlite wasm wrapper that works on any platform
  - 2y ago
- pjmlp 2y ago
  The idea isn't new, for example Amsterdam Compiler Kit from 1980's.
  - mech422 2y ago
    Ohh...thats a name I haven't heard in a while... along with the purdue compiler construction kit funny how CLang basically blew right by them in terms of option as a 'base' to build languages on.
    - pjmlp 2y ago
      It was basically dead by the time LLVM became a thing, in this industry we tend to reinvent a lot, pretending it is something utterly new. Latest example, application servers in WebAssembly.
    - arcticbull 2y ago
      LLVM -- clang is the C language family front-end to LLVM.
- sweeter 2y ago
  This is by far one of the best parts of Go. Its all around simple and painless to use. anyone designing a language should study what Go did well and what they didn't.
- lifthrasiir 2y ago
  While good cross-compilation is one of Go's strengths... I don't really think a unified assembly language contributed to that? Any assembly code can't be shared across multiple architectures in general, so the only potential benefit would be the easiness of parser development, which doesn't sound like a big thing. Rob Pike himself even noted that it can be offputting to outsiders but considered it's a worthy trade-off nevertheless [1], the conclusion I don't really think justified. [1] https://go.dev/talks/2016/asm.slide#32 https://go.dev/talks/2016/asm.slide#32
  - deleted 2y ago
    [deleted]
deleted 2y ago
[deleted]
Yoric 2y ago
FWIW, that's also more or less what SpiderMonkey has been doing for ~25 years (and I presume other JavaScript VMs).
deleted 2y ago
[deleted]

alphazard 2y ago

And it worked. Go established cross-compilation as table-stakes for new programming languages, at a time when very few were doing it well, if at all.

p_l 2y ago
Go essentially copied the design from Plan9 compilers, which it was originally based on. It's one of the many things it inherited from Plan9 environment.
- kjksf 2y ago
  It's more "reused" because Plan9 compilers were designed / co-implemented by Pike / Thomson, 2 out of 3 original designers of Go. For those interested, here's Thomson's paper about Plan9 C compilers: https://9p.io/sys/doc/compiler.html https://9p.io/sys/doc/compiler.html and https://doc.cat-v.org/bell_labs/new_c_compilers/ https://doc.cat-v.org/bell_labs/new_c_compilers/
  - derefr 2y ago
    I would love to see a deep dive on what features / architectural paradigms the Golang runtime shares with Plan9. Has anything like that been written? One that always sticks out to me personally is the use in Go of the term "dial" instead of "connect" for network connection establishment. This is, AFAICT, another Pike+Thompson-ism, as it can be seen previously in the form of the Plan9 dial(3) syscall — https://9fans.github.io/plan9port/man/man3/dial.html https://9fans.github.io/plan9port/man/man3/dial.html . --- A tangent: I have wondered before whether Pike and Thompson drafted the design for the language that would become Golang long before working at Google, initially to replace C specifically in the context of being the lingua-franca for systems programming on Plan 9. And that, therefore — at least in the designer's minds — Golang would have always had Plan9 as its secret "flagship target" that it should have a 1:1 zero-impedance abstraction mapping onto. Even if they never bothered to actually make a Plan9 Golang runtime. You could test this hypothesis by implementing an actual Golang runtime for Plan9†, and then comparing it to the Golang runtimes for other OSes — if Plan9 were the "intended home" for Golang programs, then you'd expect the Golang runtime to be very "thin" on Plan9. (To put that another way: imagine the Golang runtime as something like WINE — a virtualization layer that implements things that could be syscalls / OS library code, in the form of client-side runtime shim code. A "WINE implementation for Windows" would be an extremely thin shim, as every shim call would just point to a 1:1-API-matched piece of OS-provided code. My hypothesis here is that "Golang for Plan9" is the same kind of thing as "WINE for Windows.") † I was saying this as a thought experiment, not thinking there would actually be a Plan9 implementation of the Golang runtime... but there is! (https://go.dev/wiki/Plan9 https://go.dev/wiki/Plan9) So someone can actually check this :)
    - mbivert 2y ago
      > I would love to see a deep dive on what features / architectural paradigms the Golang runtime shares with Plan9. Has anything like that been written? If it has, then it's most likely available on https://cat-v.org/ https://cat-v.org/. Even if it hasn't, cat-v.org is a great starting point. Besides, close to your line of thought, and assuming you didn't knew about this already, Pike & al previously worked on Limbo[0], a "predecessor" of Go, used to wrote Inferno[1], a Plan9-like OS, which could be hosted on arbitrary OSes via a bespoke virtual machine called "Dis". So there were indeed a few previous "drafts" for Go. I'd doubt that Go has been designed "for" Plan9 though. [0]: https://en.wikipedia.org/wiki/Limbo_(programming_language) https://en.wikipedia.org/wiki/Limbo_(programming_language) [1]: https://en.wikipedia.org/wiki/Inferno_(operating_system) https://en.wikipedia.org/wiki/Inferno_(operating_system)
      - exitb 2y ago
        There’s also libthread[1] which implements concurrency model similar to goroutines (at least earlier, as they appear to be no longer just cooperatively scheduled?). That manual also mentions Alef and Newsqueak as influential predecessors. [1] http://man.9front.org/2/thread http://man.9front.org/2/thread
    - gavindean90 2y ago
      It sort of was and Rob blogged about it. It is based really on Newsqueak and plan9 C which is very different from Unix C
    - pram 2y ago
      I'd guess dial is probably a Bell Labs-ism
cloudfudge 2y ago
Yes, this is a great leap forward in my opinion. I had to do a project at a previous job where I wrote an agent that ran on x86, MIPS and ARM, and doing it in Go was a no-brainer. The other teams who had a bunch of C code that was a nightmare to cross-compile were so jealous they eventually moved a lot of things to Go. I've been doing this for 35 years and cross compiling anything nontrivial was always a toolchain nightmare. Discovering a world where all I had to do was set GOARCH=mips64 (and possibly GOOS=darwin if I wanted mac binaries) before invoking the compiler is so magical I was extremely skeptical when I first read about it.
- bombela 2y ago
  As long as you don't have C libraries to cross compile / link against of course ;)
  - akira2501 2y ago
    sqlite is the only thing that makes me sad I have CGO_ENABLED=0.
    - thombles 2y ago
      This non-cgo port might help - I started using it recently and it's fine but I'm not exactly a demanding user https://pkg.go.dev/modernc.org/sqlite https://pkg.go.dev/modernc.org/sqlite
      - KyleSanderson 2y ago
        It's still pretty slow, but overall correct. There's tricks, like reader connections and a single writer connection to reduce contention. There was a blog post on here detailing some speedups in general.
    - anacrolix 2y ago
      Use the new sqlite wasm wrapper that works on any platform
- 2y ago
pjmlp 2y ago
The idea isn't new, for example Amsterdam Compiler Kit from 1980's.
- mech422 2y ago
  Ohh...thats a name I haven't heard in a while... along with the purdue compiler construction kit funny how CLang basically blew right by them in terms of option as a 'base' to build languages on.
  - pjmlp 2y ago
    It was basically dead by the time LLVM became a thing, in this industry we tend to reinvent a lot, pretending it is something utterly new. Latest example, application servers in WebAssembly.
  - arcticbull 2y ago
    LLVM -- clang is the C language family front-end to LLVM.
sweeter 2y ago
This is by far one of the best parts of Go. Its all around simple and painless to use. anyone designing a language should study what Go did well and what they didn't.
lifthrasiir 2y ago
While good cross-compilation is one of Go's strengths... I don't really think a unified assembly language contributed to that? Any assembly code can't be shared across multiple architectures in general, so the only potential benefit would be the easiness of parser development, which doesn't sound like a big thing. Rob Pike himself even noted that it can be offputting to outsiders but considered it's a worthy trade-off nevertheless [1], the conclusion I don't really think justified. [1] https://go.dev/talks/2016/asm.slide#32 https://go.dev/talks/2016/asm.slide#32
- deleted 2y ago
  [deleted]

deleted 2y ago

[deleted]

Yoric 2y ago

FWIW, that's also more or less what SpiderMonkey has been doing for ~25 years (and I presume other JavaScript VMs).

deleted 2y ago

[deleted]