> Plan9 C is a product of Thompson, Pike & Ritchie, you can't get more C than that, whatever your standards committee thinks.
Really?
That looks like an obvious contradiction. Call me a language descriptivist. If everyone else means something else by C, then the thing in question isn't C.
heya, maht! nothing you read below will be news to you, but for the record here's what i think:
as far as the technical arguments against the Plan 9-descendent tools are concerned, yes, they're outdated. but the lack of cruft accumulating over the last 20 years in that toolchain is also the reason why they went with it as bootstrap for Go -- it was simple enough then. this is changing, that's why most of the Go runtime isn't written in C anymore.
the author made the argument that Go's toolchain is hard to port. this is contrary to previous experience with Plan 9's toolchain. i'm hoping 4ad (who did the port to solaris/illumos) can weigh in with his experience, but from what i saw in the commits the process did not take altogether long or appeared arduous. cgo is a separate matter, as we clearly see :)
as far as the author's personal dislike for all things pike that's a different issue altogether. and quite amusing :)
> i'm hoping 4ad (who did the port to solaris/illumos) can weigh in with his experience
What can I say :). I love the Plan 9 assembly. It's the same on every operating system (even though the calling conventions are different on different systems!). It has some higher level constructs that make the assembly more consistent between different hardware architectures. It's verifiable, to some degree, by go vet.
It's not great, there's nothing great to it; in many respects it's old fashioned and anachronistic (static register, really? In Go?), but it works just fine. Other assemblers work fine too. I never felt the need to complain about assemblers. They are such a tiny, trivial, implementation detail I am amazed to see them mentioned at all.
As for the Plan 9 C dialect, the Go toolchain recently removed the C compiles, so I don't see the point of discussing Plan 9 C at all, although I like Plan 9 C quite a lot too.
The linkers work the way they work because they originally supported only static binaries. I don't like the linkers at all, although I like what they do. Cross-compilation is a marvellous thing. The code sucks though, I hate it. But there are new linkers in the work. While I can rant away for days about the linkers (I hate the fucking code), I can't complain about the features. I love the features and how they work. I can just complain about the (inappropriate) code.
The Solaris port was definitely slowed down by the fact that on other Unix systems, Go encodes the system call table. I had to add ELF support for linking with shared libraries, in order to not encode the system call table on Solaris. But I only had to do that once. Say, if I port Go to Haiku (God forbid), the code will now exist, and it will work. If Go supported linking with shared libraries from the beginning, someone would have still written that code. ELF shared library support takes time to write and it's irrelevant (from my perspective) whether I had to do it or someone else. Someone has to write it at some point, the total engineering time spent is the same.
As for the portability of the toolchain, it's pretty portable, though porting to a new operating system is a too minor of a job for that too matter. Time is dominated by other effects. But you can see it if you port it to a new architecture. I am doing the arm64 port, and the Go compiler was very easy to port, much easier than say, gcc.
Yes, unlike Linux, the system call table is not guaranteed to be stable. Also, libc does a lot of things, like set up TLS. It's also critical in the signalling path.
On Solaris you don't ship statically linked binaries. All Go binaries are linked with libc.so. In fact, amd64 Solaris doesn't even support statically linked binaries at all. It won't exec them.
The situation is exactly the same as on Windows. Windows Go binaries are dynamically linked agains Windows standard libraries, and Go binaries use the shared libraries instead of doing system calls themselves.
I agree but I want to add that this is a phenomenon across many entities in human life, over a period of time.
Cities changes with time and people who stayed in that city decades ago, when they visit recently, will get the similar impression. Any one who saw a phone in late 70's and saw it now, will get the similar impression. Even jobs also change where designation/title may remain same but underlying technologies,tools,working hours,team composition, challenges,expectations on delivery ...etc all may change.
In conclusion, this is natural phenomenon w.r.t time, where top remains same and change happens below.
Really?
That looks like an obvious contradiction. Call me a language descriptivist. If everyone else means something else by C, then the thing in question isn't C.