> It's not a proper assembler, only a way to generate the startup object files necessary to get the binary running, and is neither clean, complete, nor documented.
> None of that is excusable, only true.
Plan 9 C compilers, incidentally, are going away too as soon as they port the rest of Go into Go.
It's clear to me there was path-dependency--some folks who mostly worked on Plan 9 started a little skunkworks-y language project, and rather than deciding to learn the LLVM world and slot themselves into that à la Rust or similar, they brought along the toolchain they'd been working with since forever.
To me, that's more like any other case of sticking with legacy code than NIH--it's "I'm using these tools I've worked a lot with because that's a lot cheaper for me than switching" not "I'm going to build tools from scratch right now because [I think I can do better|it's fun|rabid badgers made me do it]."
I wouldn't mind using LLVM or some such to handle the lower levels at all; I hear it's great elsewhere and I specifically hear Go's ARM codegen is pretty wonky. But it's also expensive to do and a lot less important to most of us than the things the team's working on, like lowering GC pause times.
Finally, in case anyone read it as serious, "Instructions, registers, and assembler directives are always in UPPER CASE to remind you that assembly programming is a fraught endeavor" is a joke. This is the same language that has 'notwithstanding' as an (ignored) keyword; not everything deadpan is serious.
Also, later in that thread:
> It's not a proper assembler, only a way to generate the startup object files necessary to get the binary running, and is neither clean, complete, nor documented.
> None of that is excusable, only true.
Plan 9 C compilers, incidentally, are going away too as soon as they port the rest of Go into Go.
It's clear to me there was path-dependency--some folks who mostly worked on Plan 9 started a little skunkworks-y language project, and rather than deciding to learn the LLVM world and slot themselves into that à la Rust or similar, they brought along the toolchain they'd been working with since forever.
To me, that's more like any other case of sticking with legacy code than NIH--it's "I'm using these tools I've worked a lot with because that's a lot cheaper for me than switching" not "I'm going to build tools from scratch right now because [I think I can do better|it's fun|rabid badgers made me do it]."
I wouldn't mind using LLVM or some such to handle the lower levels at all; I hear it's great elsewhere and I specifically hear Go's ARM codegen is pretty wonky. But it's also expensive to do and a lot less important to most of us than the things the team's working on, like lowering GC pause times.
Finally, in case anyone read it as serious, "Instructions, registers, and assembler directives are always in UPPER CASE to remind you that assembly programming is a fraught endeavor" is a joke. This is the same language that has 'notwithstanding' as an (ignored) keyword; not everything deadpan is serious.