From mboxrd@z Thu Jan 1 00:00:00 1970 From: smiley@zenzebra.mv.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> References: <86ipx4s36p.fsf@cmarib.ramside> <86ei7ry76s.fsf@cmarib.ramside> <86zkqf46vz.fsf@cmarib.ramside> Date: Wed, 2 Feb 2011 05:14:54 +0000 In-Reply-To: (ron minnich's message of "Tue, 1 Feb 2011 16:47:12 -0800") Message-ID: <86mxmfuiep.fsf_-_@cmarib.ramside> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a73e7aac-ead6-11e9-9d60-3106f5b1d025 ron minnich writes: > I think you should set your sights higher than the macro approach you > propose. At least in my opinion it's a really ugly idea. You might be surprised to hear that I agree. :) It's far from an ideal solution. I am certainly open to alternatives! > You could make a lasting contribution by bringing a good modern > language to Plan 9. Maybe. My first criterion for such a language would be that it compile to native machine code. Although requiring such may be presumptive, it seems appropriate that the core OS applications (file servers, command line utilities, etc.) be in native machine code. On the other hand, on Inferno, Limbo compiles to architecture-independent bytecode, eliminating the need for the /$objtype directories on Plan 9, while enabling easier sharing of object code. What are all your thoughts' on this "compiled vs interpreted" design decision? The Go language (from Google? sigh. Evil, evil.) appears to compile to native machine code. The Go web site (http://golang.org), however, claims that Go requires a "small" runtime... which causes me to wonder just how fully "compiled" it is. Anyone know the scoop on what this "runtime" is all about? Go is also a garbage-collected language. I'm also a bit leery of using a GC language for coding core OS applications. I've generally thought of GC as being for lazy programmers (/me runs and hides under his desk, peeks out...) and incurring somewhat of a performance hit. I'm not sure if that would be appropriate for core applications. Then again, it seems to be what's done on Inferno. Thoughts on this? Wikipedia says that Go doesn't support safe concurrency. However, the Go web site claims that "goroutines" (which are kinda like threads) coordinate through explicit synchronization. Isn't that how the Plan 9 threading library works, too? I'm not sure why the Wikipedia article would make a claim like that. Thoughts on the relative merits of concurrency in Go vs Plan 9 C would also be welcome. On an implementation note, it sounds like Go can be bootstrapped from C, with a little bit of assembly. It might not be so monumental a task to port Go to Plan 9, though I would hesitate to use ANY code written by Google without a thorough audit. > I'll say it again, I don't think a cpp-based approach will be well Did you mean what you wrote, "cpp" or did you mean C++? > Or even native Limbo, that one is frequently requested. Can Libmo be compiled to native machine code? There was some mention that, during the history of Plan 9, developers had difficulty maintaining two different languages on the system. I wonder how much of that difficulty would still apply today. Although the kernel could concievably be translated to a modern compiled language, I doubt it could be written in Go. If Go were used, then, there would still have to be two languages/compilers/development environments on the system. -- +---------------------------------------------------------------+ |E-Mail: smiley@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---------------------------------------------------------------+