Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[David Leimbach <leimy2k@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5412 bytes --]

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|
> +---------------------------------------------------------------+
>
>

[-- Attachment #2: Type: text/html, Size: 7144 bytes --]