6 ms·

I'm more interested to hear `from C++ to Go` stories :)

by zura 12y ago

4ad 12y ago
This presentation is about using an automated program to convert the existing Plan 9-based Go compiler suite from C to Go, it's not a "rewriting infrastructure in Go" story.
- logicchains 12y ago
  Part of me dreams that they'd be able to convert the whole Plan 9 OS into Go one day, but that's probably hoping for too much.
  - 4ad 12y ago
    What would be the point? (serious question). I assume you are talking about the user-space utilities. Having them in Go on Plan 9 would not be the best idea at the moment, Go binaries are big, and while on Unix this is a non-issue, in Plan 9, where every binary has to travel over the network this is not the greatest idea. Perhaps Go binaries will become smaller in the future, but Go only exists on 386/amd64/arm at the moment, and on Plan 9 only the 386 port works. Plan 9 also works on MIPS and POWER, and it worked on SPARC and ALPHA and many others too, and you can still compile all the binaries for those architectures, in case you decide to write a new POWER8 or SPARC64 kernel. Plus there's an impedance mismatch between how Go does things and how Plan 9 does things, for example in the area of networking. I'm very happy with Go's networking on Unix, it's so easy to use and makes things so much nicer. It's very different than the Plan 9 model though, and on Plan 9 Go network programs don't fit right. Having plan9port utilities in Go would also not be the best thing. I run plan9port on Irix. I ported Go to Solaris because I had plan9port working on Solaris. If plan9port depended on Go, I probably wouldn't have started the port. All my arguments so far ignored the fact that the few people interested in Plan 9 are already very familiar with the C sources, and many of them don't even care about Go that much. I really wish Go would fit better in Plan 9. I really miss Go when I have to write C.
    - logicchains 12y ago
      For me, the point would be having an OS that was really easy to study, extend and modify, due to how easy to read Go is. No more ifdefs, no preprocessor macros, just clean code.
      - 4ad 12y ago
        Plan 9 has no #ifdefs ano no preprocessor macros.
  - coldtea 12y ago
    Seems like a rather pointless dream. What would be the benefit? A slower OS with GC pauses?
    - jesstaa 12y ago
      Plan9 was already largely rewritten in a precursor to Go called Limbo. It's garbage collected and runs on a virtual machine. http://en.wikipedia.org/wiki/Inferno_(operating_system) http://en.wikipedia.org/wiki/Inferno_(operating_system)
      - 4ad 12y ago
        Plan 9 and Inferno are very related, but I wouldn't say Inferno is "Plan 9 rewritten in Limbo", nor is Limbo equivalent enough to Go for the comparison to make sense. First, the Inferno kernel is written in C, not Limbo, and is somewhat similar to the Plan 9 kernel to the point that is moderately feasible to port drivers from Plan 9 to Inferno. Second, you could say acme was rewritten from alef (not C) to Limbo, and maybe you can say cat, tail, mk and yacc were "rewritten in Limbo", but soon after the list ends. Most utilities are genuinely new utilities that make use of the different abstractions provided by the operating system. Of course there are lots of high-level similarities, but they are quite different programs. This brings me to my next point, the abstractions provided by Plan 9 and Inferno are very different. Different enough that a new set of tools makes sense. For comparison, rewriting C code to Go uses the same underlying abstractions, so it doesn't make as much sense. Another point I want to make is that compiled Limbo programs are extremely small, and Limbo is dynamically loaded, unlike Go. Yet another point is that Limbo programs use reference counting plus a real-time garbage collector for cycles, which is made easier by Limbo and Inferno constraints. Go uses neither and the language is different enough to prevent a real time garbage collector.
    - hahainternet 12y ago
      If we've learned anything in the last two decades it's that speed matters more than memory safety. Right guys?
      - 12y ago

I'm more interested to hear `from C++ to Go` stories :)

by zura 12y ago

I'm more interested to hear `from C++ to Go` stories :)

4ad 12y ago

This presentation is about using an automated program to convert the existing Plan 9-based Go compiler suite from C to Go, it's not a "rewriting infrastructure in Go" story.

logicchains 12y ago
Part of me dreams that they'd be able to convert the whole Plan 9 OS into Go one day, but that's probably hoping for too much.
- 4ad 12y ago
  What would be the point? (serious question). I assume you are talking about the user-space utilities. Having them in Go on Plan 9 would not be the best idea at the moment, Go binaries are big, and while on Unix this is a non-issue, in Plan 9, where every binary has to travel over the network this is not the greatest idea. Perhaps Go binaries will become smaller in the future, but Go only exists on 386/amd64/arm at the moment, and on Plan 9 only the 386 port works. Plan 9 also works on MIPS and POWER, and it worked on SPARC and ALPHA and many others too, and you can still compile all the binaries for those architectures, in case you decide to write a new POWER8 or SPARC64 kernel. Plus there's an impedance mismatch between how Go does things and how Plan 9 does things, for example in the area of networking. I'm very happy with Go's networking on Unix, it's so easy to use and makes things so much nicer. It's very different than the Plan 9 model though, and on Plan 9 Go network programs don't fit right. Having plan9port utilities in Go would also not be the best thing. I run plan9port on Irix. I ported Go to Solaris because I had plan9port working on Solaris. If plan9port depended on Go, I probably wouldn't have started the port. All my arguments so far ignored the fact that the few people interested in Plan 9 are already very familiar with the C sources, and many of them don't even care about Go that much. I really wish Go would fit better in Plan 9. I really miss Go when I have to write C.
  - logicchains 12y ago
    For me, the point would be having an OS that was really easy to study, extend and modify, due to how easy to read Go is. No more ifdefs, no preprocessor macros, just clean code.
    - 4ad 12y ago
      Plan 9 has no #ifdefs ano no preprocessor macros.
- coldtea 12y ago
  Seems like a rather pointless dream. What would be the benefit? A slower OS with GC pauses?
  - jesstaa 12y ago
    Plan9 was already largely rewritten in a precursor to Go called Limbo. It's garbage collected and runs on a virtual machine. http://en.wikipedia.org/wiki/Inferno_(operating_system) http://en.wikipedia.org/wiki/Inferno_(operating_system)
    - 4ad 12y ago
      Plan 9 and Inferno are very related, but I wouldn't say Inferno is "Plan 9 rewritten in Limbo", nor is Limbo equivalent enough to Go for the comparison to make sense. First, the Inferno kernel is written in C, not Limbo, and is somewhat similar to the Plan 9 kernel to the point that is moderately feasible to port drivers from Plan 9 to Inferno. Second, you could say acme was rewritten from alef (not C) to Limbo, and maybe you can say cat, tail, mk and yacc were "rewritten in Limbo", but soon after the list ends. Most utilities are genuinely new utilities that make use of the different abstractions provided by the operating system. Of course there are lots of high-level similarities, but they are quite different programs. This brings me to my next point, the abstractions provided by Plan 9 and Inferno are very different. Different enough that a new set of tools makes sense. For comparison, rewriting C code to Go uses the same underlying abstractions, so it doesn't make as much sense. Another point I want to make is that compiled Limbo programs are extremely small, and Limbo is dynamically loaded, unlike Go. Yet another point is that Limbo programs use reference counting plus a real-time garbage collector for cycles, which is made easier by Limbo and Inferno constraints. Go uses neither and the language is different enough to prevent a real time garbage collector.
  - hahainternet 12y ago
    If we've learned anything in the last two decades it's that speed matters more than memory safety. Right guys?
    - 12y ago