6 ms·

> The real toolchains everyone else uses were not invented at Lucent nor Google Plan 9 is not a product of Lucent. It is a product of Bell-Labs. Lucent killed

> The real toolchains everyone else uses were not invented at Lucent nor Google Plan 9 is not a product of Lucent. It is a product of Bell-Labs. Lucent killed Bell-Labs. Calling it a Lucent product is akin to the worst insult to us you could come up with, unless you said it was GNU-like. Plan9 C is a product of Thompson, Pike & Ritchie, you can't get more C than that, whatever your standards committee thinks. > Without the benefit of decades of lessons learned running Unix in production I'm not sure what the author of the rant thinks the people who invented Unix were doing all those years.

dap 12y ago
> 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.
- f2f 12y ago
  "I used to be with it, but then they changed what it was. Now what I'm with isn't it, and what's it seems weird and scary to me..." -- Grandpa Simpson
  - SixSigma 12y ago
    hey f2f. This is maht. It's Go Backlash-Day on HN. The pedestal they've been putting it on must have got high enough.
    - f2f 12y ago
      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 :)
      - 4ad 12y ago
        > 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.
        ori_b 12y ago
        > The Solaris port was definitely slowed down by the fact that on other Unix systems, Go encodes the system call table. Is there any reason that you can't just encode the system call table on Solaris too?
- SixSigma 12y ago
  Ask Chuck Moore what he thinks about ANSII Forth. I'll save you the trouble : "The ANSII Forth standard does not describe Forth, but a language with the same name."
  - q2 12y ago
    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.
coldtea 12y ago
>I'm not sure what the author of the rant thinks the people who invented Unix were doing all those years. I'm not sure what you think they're doing, but they were not running Unix in production. I've read an interview with Ken Thompson taken around the nineties, and he mentioned they were using Windows desktop machines. And true to the words he had Windows on the monitor on his desk. And of course they were doing academic and researchy stuff. Not running Unix in production.
- davecheney 12y ago
  What horse pucky. The first Unix systems were used by Bell Labs' patent department to process patent applications. It was this first customer of the Unix group that sponsored the development of Unix for many of its formative years.
  - coldtea 12y ago
    >The first Unix systems were used by Bell Labs' patent department to process patent applications. It was this first customer of the Unix group that sponsored the development of Unix for many of its formative years. That's the seventies. Or at best early eighties. We're talking about the last 30 years. Not to mention that whatever customers Bell Labs had, doesn't translate that Richie, Pike and co were running Unix in production or cared about those systems and those customers themselves... They had moved on to other researchy stuff...
    - SixSigma 12y ago
      POP was written in 1999 The last Unix release with people from the the Lab was UnixWare 7.1 (1999), the last from AT&T in 2001. Anything else is not Unix. We know Rob wrote Utah 2000 in that year. That's 15 years ago.
- justin66 12y ago
  That's vague enough that it might very well have happened before desktop plan9 was practical for everyday use.

dap 12y ago

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

f2f 12y ago
"I used to be with it, but then they changed what it was. Now what I'm with isn't it, and what's it seems weird and scary to me..." -- Grandpa Simpson
- SixSigma 12y ago
  hey f2f. This is maht. It's Go Backlash-Day on HN. The pedestal they've been putting it on must have got high enough.
  - f2f 12y ago
    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 :)
    - 4ad 12y ago
      > 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.
      - ori_b 12y ago
        > The Solaris port was definitely slowed down by the fact that on other Unix systems, Go encodes the system call table. Is there any reason that you can't just encode the system call table on Solaris too?
SixSigma 12y ago
Ask Chuck Moore what he thinks about ANSII Forth. I'll save you the trouble : "The ANSII Forth standard does not describe Forth, but a language with the same name."
- q2 12y ago
  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.

coldtea 12y ago

>I'm not sure what the author of the rant thinks the people who invented Unix were doing all those years. I'm not sure what you think they're doing, but they were not running Unix in production. I've read an interview with Ken Thompson taken around the nineties, and he mentioned they were using Windows desktop machines. And true to the words he had Windows on the monitor on his desk. And of course they were doing academic and researchy stuff. Not running Unix in production.

davecheney 12y ago
What horse pucky. The first Unix systems were used by Bell Labs' patent department to process patent applications. It was this first customer of the Unix group that sponsored the development of Unix for many of its formative years.
- coldtea 12y ago
  >The first Unix systems were used by Bell Labs' patent department to process patent applications. It was this first customer of the Unix group that sponsored the development of Unix for many of its formative years. That's the seventies. Or at best early eighties. We're talking about the last 30 years. Not to mention that whatever customers Bell Labs had, doesn't translate that Richie, Pike and co were running Unix in production or cared about those systems and those customers themselves... They had moved on to other researchy stuff...
  - SixSigma 12y ago
    POP was written in 1999 The last Unix release with people from the the Lab was UnixWare 7.1 (1999), the last from AT&T in 2001. Anything else is not Unix. We know Rob wrote Utah 2000 in that year. That's 15 years ago.
justin66 12y ago
That's vague enough that it might very well have happened before desktop plan9 was practical for everyday use.