On Mon Dec 2 19:16:55 EST 2013, al...@pbrane.org wrote: > Steve Simon <st...@quintile.net> once said: > > Whne I looked at Go - maybe 2 years ago, I could not see why > > plan9 would not adopt go's 8c/8l and libbio. > > > > obviously others disagree as they have not been back-ported, > > but why not? - I'am not trolling, genuine question. > > We couldn't adopt the Go ?[acl] toolchain wholesale > because of incompatible Go-specific changes; e.g., > disallowing variadic C functions without a #pragma > annotation, a different symtab/pclntab format, etc. > > It would take a fair bit of work to make everything > (including libmach) backwards-compatible.
i think one could avoid the backwards-compatibity. simple change the formats and recompile the system. the other problems in principle are superficial. the real question that needs adressing is what is plan 9, and what makes it useful. for me, i think having a self-contained system that takes over as early as it can in the boot process with all the source in /sys and all the source part of the system, and not subject to forces outside plan 9, is valuable. the code is amazingly stable, and it's not too hard for one person to have a pretty good grasp of the system. this is super powerful. instead of putting mental energy in boxing up hard-to-understand and perhaps not essential bits of the system so one doesn't have to think about how they work, one can know how those bits work and put their quirks to good use. or even change them. instead of building another layer on top (to avoid knowing about lower layers), relatively speaking, plan 9 makes it trivial to get in and do what needs to be done. it may be that replacing the compilers with something externally controlled is not that much of a set back and all told one gains more than one loses. even if that is the case, i'm not sure i'd be okay with the ensuing churn. - erik
