On Tue, Feb 1, 2011 at 9:14 PM,
<smiley@zenzebra.mv.com> wrote:
ron minnich <rminnich@gmail.com> 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?
You can already write Limbo programs for Plan 9. The line between the "OS" of Inferno and the VM of Inferno is small. You should be able to access your plan 9 resources from Inferno just fine. Just like you can access most of what you'd want from an operating system from Java or Erlang. It's not very different, except that Inferno has shells and editors and a GUI that run in it's VM.
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?
Even C has a runtime. Perhaps you should look more into how programming languages are implemented :-). C++ has one too, especially in the wake of exceptions and such.
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?
GC can incur performance hits in some families of applications where timing guarantees are needed and make writing code for hard realtime applications basically impossible, unless you can get some guarantees from the GC that it won't interrupt your processing that must complete by a particular deadline.
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.
The memory model is very clear on how changes become visible across goroutines. One must either synchronize with channels or synchronize via some locking mechanism to guarantee that updates to shared data are visible. Go encourages a CSP style of concurrency that promotes using channels for both synchronization and update of shared data.
This is something you could learn by reading more about it yourself, or trying it out. There's even an in-browser sandbox you can use.
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.
People already have a Go cross compiler to Plan 9. You could verify these "sounds like" factoids yourself though by checking it out and trying it.
> 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++?
C pre-processor probably.
> 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.
Where did your C compiler come from? Someone probably compiled it with a C compiler. Bootstrapping is a fact of life as a new compiler can't just be culled from /dev/random or willed into existence otherwise. It takes a plan 9 system to build plan 9 right? (This was not always true for infinitely recursive reasons)
--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+