From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <86mxmfuiep.fsf_-_@cmarib.ramside> References: <86ipx4s36p.fsf@cmarib.ramside> <86ei7ry76s.fsf@cmarib.ramside> <86zkqf46vz.fsf@cmarib.ramside> <86mxmfuiep.fsf_-_@cmarib.ramside> Date: Wed, 2 Feb 2011 09:44:34 -0800 Message-ID: From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001636ef0ceabf8aff049b5033ad Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a81b2f42-ead6-11e9-9d60-3106f5b1d025 --001636ef0ceabf8aff049b5033ad Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 1, 2011 at 9:14 PM, wrote: > 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? > 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| > +---------------------------------------------------------------+ > > --001636ef0ceabf8aff049b5033ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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<= br> > propose. At least in my opinion it's a really ugly idea.

You might be surprised to hear that I agree. =A0:) It's far from an ide= al
solution. =A0I am certainly open to alternatives!

> You could make a lasting contribution by bringing a good modern
> language to Plan 9.

Maybe. =A0My first criterion for such a language would be that it compile to native machine code. =A0Although requiring such may be presumptive, it seems appropriate that the core OS applications (file servers, command
line utilities, etc.) be in native machine code. =A0On 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. =A0What are all your thoughts' = on
this "compiled vs interpreted" design decision?
<= div>
=A0

The Go language (from Google? sigh. Evil, evil.) appears to compile to
native machine code. =A0The Go web site (http://golang.org), however,
claims that Go requires a "small" runtime... which causes me to w= onder
just how fully "compiled" it is. =A0Anyone know the scoop on what= this
"runtime" is all about?

Even = C has a runtime. =A0Perhaps you should look more into how programming langu= ages are implemented :-). =A0C++ has one too, especially in the wake of exc= eptions and such.
=A0

Go is also a garbage-collected language. =A0I'm also a bit leery of usi= ng
a GC language for coding core OS applications. =A0I've generally though= t
of GC as being for lazy programmers (/me runs and hides under his desk,
peeks out...) and incurring somewhat of a performance hit. =A0I'm not s= ure
if that would be appropriate for core applications. =A0Then again, it
seems to be what's done on Inferno. =A0Thoughts on this?

GC can incur performance hits in some families of app= lications where timing guarantees are needed and make writing code for hard= realtime applications basically impossible, unless you can get some guaran= tees from the GC that it won't interrupt your processing that must comp= lete by a particular deadline. =A0
=A0

Wikipedia says that Go doesn't support safe concurrency. =A0However, th= e
Go web site claims that "goroutines" (which are kinda like thread= s)
coordinate through explicit synchronization. =A0Isn't that how the Plan= 9
threading library works, too? =A0I'm not sure why the Wikipedia article=
would make a claim like that. =A0Thoughts on the relative merits of
concurrency in Go vs Plan 9 C would also be welcome.
<= br>
The memory model is very clear on how changes become visible = across goroutines. =A0One must either synchronize with channels or synchron= ize via some locking mechanism to guarantee that updates to shared data are= visible. =A0Go encourages a CSP style of concurrency that promotes using c= hannels for both synchronization and update of shared data.=A0

This is something you could learn by reading more about= it yourself, or trying it out. =A0There's even an in-browser sandbox y= ou can use.
=A0

On an implementation note, it sounds like Go can be bootstrapped from C, with a little bit of assembly. =A0It 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. =A0You could verify these &quo= t;sounds like" factoids yourself though by checking it out and trying = it.
=A0

> 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. =A0I
wonder how much of that difficulty would still apply today. =A0Although
the kernel could concievably be translated to a modern compiled
language, I doubt it could be written in Go. =A0If Go were used, then,
there would still have to be two languages/compilers/development
environments on the system.

Where did y= our C compiler come from? =A0Someone probably compiled it with a C compiler= . =A0Bootstrapping is a fact of life as a new compiler can't just be cu= lled from /dev/random or willed into existence otherwise. =A0It takes a pla= n 9 system to build plan 9 right? =A0(This was not always true for infinite= ly recursive reasons)
=A0

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com =A0 =A0 =A0 =A0 =A0 =A0 PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA =A03489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+


--001636ef0ceabf8aff049b5033ad--