Re: [9fans] Go

Re: [9fans] Go

[erik quanstrom]

> > Speaking of VMs (and Limbo) -- I'm wondering if Go is eventually going
> > to have it anyway. Any reason not to?
>
> It can be perceived as a competitor to C if it has a runtime, but not
> if it has a VM. So I don't think it would grow one.

why do you think the goal is to be
perceived as a competitor to c?

i don't see that here:
http://golang.org/doc/go_faq.html#What_is_the_purpose_of_the_project

one thing that's not clear to me from
the faq (perhaps it's clarified in robs talk?)
and i haven't worked out for myself yet, is if
one could write operating system code in
go.  and if so, what would the language
restrictions be.

- erik

Re: [9fans] Go

[Devon H. O'Dell]

2009/11/12 erik quanstrom <quanstro@quanstro.net>:
>> > Speaking of VMs (and Limbo) -- I'm wondering if Go is eventually going
>> > to have it anyway. Any reason not to?
>>
>> It can be perceived as a competitor to C if it has a runtime, but not
>> if it has a VM. So I don't think it would grow one.
>
> why do you think the goal is to be
> perceived as a competitor to c?
>
> i don't see that here:
> http://golang.org/doc/go_faq.html#What_is_the_purpose_of_the_project

Because it is constantly compared with C, C++, Java, and scripting
languages. Its packages are sold as better than C header files, which
is demonstrated in Russ' compile time video. It is a compiled language.
Its syntax is not horribly divergent from C.

I'm not saying that C is its main competition, but it clearly does compete
in the field of general purpose languages, of which C is a large player.
In this regard, it also aims to compete with C++, Java, Python, Ruby,
and Perl.

It is billed as a good general purpose language for modern systems. It
is just that, and therefore, I drew that conclusion.

> one thing that's not clear to me from
> the faq (perhaps it's clarified in robs talk?)
> and i haven't worked out for myself yet, is if
> one could write operating system code in
> go.  and if so, what would the language
> restrictions be.

It has support for pointers, so I guess so. I'd guess it's somewhat
easier than C++, where you have to have an implementation for new
before you can do much of anything else very C++-like. That said,
it does have a language runtime like C++, so I suspect it does need
some setup before some features (such as threads) can be used.

> - erik

--dho

Re: [9fans] Go

[Roman Shaposhnik]

On Thu, Nov 12, 2009 at 8:37 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> > Speaking of VMs (and Limbo) -- I'm wondering if Go is eventually going
>> > to have it anyway. Any reason not to?
>>
>> It can be perceived as a competitor to C if it has a runtime, but not
>> if it has a VM. So I don't think it would grow one.
>
> why do you think the goal is to be
> perceived as a competitor to c?

Good question. In fact, I'd say any language that has a non-trivial
runtime library is not actually competing with C. C is a portable assembler
and that's why I, personally, like it so much -- its runtime is pure hardware
(both physical and virtual).

To some extent -- that's the reason I'm asking my VM question. I think any
non-trivial runtime is VM envy. Besides with JIT like capabilities you can
actually run faster in a VM setting.

> one thing that's not clear to me from
> the faq (perhaps it's clarified in robs talk?)
> and i haven't worked out for myself yet, is if
> one could write operating system code in
> go.  and if so, what would the language
> restrictions be.

If what you mean is "writing a kernel" then my take so far
is -- garbage collection and concurrency support might get
in the way. However, as always, I'd be very curious to find out
Russ' take on it.

Thanks,
Roman.

Re: [9fans] Go

[erik quanstrom]

> Because it is constantly compared with C, C++, Java, and scripting
> languages. Its packages are sold as better than C header files, which
> is demonstrated in Russ' compile time video. It is a compiled language.
> Its syntax is not horribly divergent from C.

none of this line of reasoning bears on go's designer's
intentions.  and i would be surprised (shocked actually)
if a vm were omitted for language positioning reasons,
rather than technical ones.

> It has support for pointers, so I guess so. I'd guess it's somewhat
> easier than C++, where you have to have an implementation for new
> before you can do much of anything else very C++-like. That said,
> it does have a language runtime like C++, so I suspect it does need
> some setup before some features (such as threads) can be used.

support for pointers isn't a requirement (cf: oberon).

also there are many things that a language can subtily make
writing a kernel in that language very difficult or impossible.

given that go has a runtime, it's reasonable to ask if the
runtime can be prevented from bothering interrupt routines
and other critical sections.  (was this a problem with alef?)

- erik

Re: [9fans] Go

[LiteStar numnums]

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

Oberon had POINTER TO, and acted in what you might expect from a
TurboPascal.

Also, wrt pointers, the original Primos was written in Fortran IV, although
it was later moved to the PL/I dialect PL/P.

On Thu, Nov 12, 2009 at 12:13 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> > Because it is constantly compared with C, C++, Java, and scripting
> > languages. Its packages are sold as better than C header files, which
> > is demonstrated in Russ' compile time video. It is a compiled language.
> > Its syntax is not horribly divergent from C.
>
> none of this line of reasoning bears on go's designer's
> intentions.  and i would be surprised (shocked actually)
> if a vm were omitted for language positioning reasons,
> rather than technical ones.
>
> > It has support for pointers, so I guess so. I'd guess it's somewhat
> > easier than C++, where you have to have an implementation for new
> > before you can do much of anything else very C++-like. That said,
> > it does have a language runtime like C++, so I suspect it does need
> > some setup before some features (such as threads) can be used.
>
> support for pointers isn't a requirement (cf: oberon).
>
> also there are many things that a language can subtily make
> writing a kernel in that language very difficult or impossible.
>
> given that go has a runtime, it's reasonable to ask if the
> runtime can be prevented from bothering interrupt routines
> and other critical sections.  (was this a problem with alef?)
>
> - erik
>
>


--
And in the "Only Prolog programmers will find this funny" department:

Q: How many Prolog programmers does it take to change a lightbulb?

A: No.
 -- Ovid

   "By cosmic rule, as day yields night, so winter summer, war peace, plenty
famine. All things change. Air penetrates the lump of myrrh, until the
joining bodies die and rise again in smoke called incense."

   "Men do not know how that which is drawn in different directions
harmonises with itself. The harmonious structure of the world depends upon
opposite tension like that of the bow and the lyre."

   "This universe, which is the same for all, has not been made by any god
or man, but it always has been, is, and will be an ever-living fire,
kindling itself by regular measures and going out by regular measures"
-- Heraclitus

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

Re: [9fans] Go

[Tharaneedharan Vilwanathan]

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

>
> and other critical sections.  (was this a problem with alef?)

as far as i know, not many alef programs were written. the few that were
written (like acme) got converted to C. and i dont think alef was used for
writing kernel code.

someone please correct me if i am wrong.

thanks
dharani

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

[9fans] Go

[Nick LaForge]

On Wed, Sep 2, 2009 at 7:20 AM, Roman V Shaposhnik <rvs@sun.com> wrote:

> Personally I think you'd be better off exploring a connection that a
> language called Lua has to C. In the immortal words of Casablanca it
> just could be "the begging of a beautiful friendship".

Well, it was nice while it lasted.

Nick

Re: [9fans] Go

[Roman Shaposhnik]

On Wed, Nov 11, 2009 at 8:31 PM, Nick LaForge <nicklaforge@gmail.com> wrote:
> On Wed, Sep 2, 2009 at 7:20 AM, Roman V Shaposhnik <rvs@sun.com> wrote:
>
>> Personally I think you'd be better off exploring a connection that a
>> language called Lua has to C. In the immortal words of Casablanca it
>> just could be "the begging of a beautiful friendship".
>
> Well, it was nice while it lasted.

Huh? I'll agree with you when Go grows a VM. And even then things like
... and multi-values (which, of course, are only possible in a dynamically
typed language) will keep me interested.

Speaking of VMs (and Limbo) -- I'm wondering if Go is eventually going
to have it anyway. Any reason not to?

Thanks,
Roman.

Re: [9fans] Go

[Devon H. O'Dell]

2009/11/12 Roman Shaposhnik <roman@shaposhnik.org>:
> On Wed, Nov 11, 2009 at 8:31 PM, Nick LaForge <nicklaforge@gmail.com> wrote:
>> On Wed, Sep 2, 2009 at 7:20 AM, Roman V Shaposhnik <rvs@sun.com> wrote:
>>
>>> Personally I think you'd be better off exploring a connection that a
>>> language called Lua has to C. In the immortal words of Casablanca it
>>> just could be "the begging of a beautiful friendship".
>>
>> Well, it was nice while it lasted.
>
> Huh? I'll agree with you when Go grows a VM. And even then things like
> ... and multi-values (which, of course, are only possible in a dynamically
> typed language) will keep me interested.
>
> Speaking of VMs (and Limbo) -- I'm wondering if Go is eventually going
> to have it anyway. Any reason not to?

It can be perceived as a competitor to C if it has a runtime, but not
if it has a VM. So I don't think it would grow one.

--dho

> Thanks,
> Roman.
>
>

Re: [9fans] Go

[Nick LaForge]

> To some extent -- that's the reason I'm asking my VM question. I think any
> non-trivial runtime is VM envy.

I take this as a desire to make use of simpler high level constructs
at the level of bytecodes.

Please do pardon me for the gratuitous presumptions of the author's
intentions in what follows.

It seems plain to me that they are confident that a traditional
machine, orthogonal to processors on the market, is and will be the
definitive interface to the hardware in the greatest number of cases,
and that MANY simplifications reaped from a consistent use of high
level constructs can be had ex-post, i.e., from the compiler.

(Interestingly enough, the future could hold for us a situation where
the definitive interface to the hardware is reconfigurable logic,
which, with present tools, pose complex enough a problem that it could
make sense to simply implement some arbitrary machine.  When that day
comes or draws near, I guess that brucee would like to hear from you.)

> Besides with JIT like capabilities you can
> actually run faster in a VM setting.

To effect, the same phenomenon has been observed, in, for example,
[http://pdos.csail.mit.edu/papers/vx32:usenix08-abs.html].

Nick

P.S.:  Perhaps some 9fans of the SF Bay Area would like to hash out in
person some of the details this fuzzy message sorely lacks, regarding
perhaps the implications for Plan9 at large in light of recent
developments?  I understand that many of us are still reeling, and it
is best to shut up and calculate, but in the somewhat near future it
could be good to coordinate to avoid duplicated efforts.  For now it
suffices to point out as an example, that the first one to write an
acme in Go could see their code eventually reach more people than one
potentially realizes.  I dare not attempt such a task myself, lest I
propagate my crap code.☺

Re: [9fans] Go

[Russ Cox]

On Tue, Nov 10, 2009 at 4:54 PM, Joseph Stewart
<joseph.stewart@gmail.com> wrote:
> Hmmm... is this Limbo/Newsqueak/Alef inspired?  http://golang.org

Sure.

On Tue, Nov 10, 2009 at 5:00 PM, andrey mirtchovski
<mirtchovski@gmail.com> wrote:
> but will it run on Plan 9?

Not yet.  It shouldn't be much effort to port if someone is
interested, but it isn't a matter of just typing mk either.
The main hurdle for the 386 tools is that Go assumes it can
set up a local segment descriptor for a kind of thread-local
storage.  The Plan 9-friendly approach is probably to use a
fixed high stack address for the local storage instead.
Then you'd have to write the OS stuff too.  I need to write a
how-to about porting to a new system.

On Tue, Nov 10, 2009 at 5:04 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Tue Nov 10 20:02:34 EST 2009, mirtchovski@gmail.com wrote:
>> but will it run on Plan 9?
>
> would the authors care to contrast go with limbo?

The common concepts—channels, slices, and cheap processes—
have their differences: channels can be typed as one direction or
another, slices have a cap, the processes can be muxed onto
multiple OS threads instead of limited to a single OS thread.
The new concepts are new and shouldn't be ignored: interface types,
the approach to constants, the package system, initialization,
methods on almost any type, the very simple approach to name
visibility (case-sensitive instead of public/private tags), and
other things I am forgetting all combine to make Go feel like
a very different language than Limbo, or for that matter Alef or
Newsqueak.  Don't fall into the trap of thinking it's just like one
of those.

Another contrast with Limbo is that the language compiles to
machine code instead of byte codes.

On Tue, Nov 10, 2009 at 5:15 PM, Roman Shaposhnik <roman@shaposhnik.org> wrote:
> P.S. Russ, are you working for Google now?

Yes.

On Tue, Nov 10, 2009 at 5:27 PM, andrey mirtchovski
<mirtchovski@gmail.com> wrote:
> serious question: can i have a link to the 9p implementation, pretty
> please? it doesn't appear in the module list on their website.

There's no 9p implementation.  I thought about writing one
a couple times, and I'd love to do that (I want to write acme
extensions in Go), but it hasn't been a priority.  Another thorny
issue is what to name the package, since you can't start a
package name with a digit.

On Tue, Nov 10, 2009 at 7:56 PM, hiro <23hiro@googlemail.com> wrote:
> have you also seen this vid?
> http://www.youtube.com/watch?v=rKnDgT73v8s

Yes.

Russ

Re: [9fans] Go

[Anant Narayanan]

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

On Wed, Nov 11, 2009 at 7:00 AM, Russ Cox <rsc@swtch.com> wrote:

> On Tue, Nov 10, 2009 at 5:27 PM, andrey mirtchovski
> <mirtchovski@gmail.com> wrote:
> > serious question: can i have a link to the 9p implementation, pretty
> > please? it doesn't appear in the module list on their website.
>
> There's no 9p implementation.  I thought about writing one
> a couple times, and I'd love to do that (I want to write acme
> extensions in Go), but it hasn't been a priority.  Another thorny
> issue is what to name the package, since you can't start a
> package name with a digit.
>

I was wondering about that too and when I found out there was no 9P package
for Go yet I created this project page: http://code.google.com/p/go9/. I
thought go9 was a reasonable compromise for the package name given we can't
start with digits, though we can change that if anyone has a better idea.

There's no code in there yet because I just found out about Go a few hours
ago and am still wrapping my head around it. I probably won't get something
working for atleast a few weeks, so in the interim if someone wants to get
started please pitch in and let's not duplicate work :-)

Regards,
Anant

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

Re: [9fans] Go

[Skip Tavakkolian]

> Another thorny
> issue is what to name the package, since you can't start a
> package name with a digit.

arabic numeral 9 is very close: ۹

Re: [9fans] Go

[Eris Discordia]

> arabic numeral 9 is very close: ۹

Puny pedantry: that's a(n) Hindi/Indic numeral. 9 is already an "Arabic 
numeral."

If playing on numerals is allowed why shouldn't they call it IXgo or even 
Kyuugo?


--On Tuesday, November 10, 2009 22:47 -0800 Skip Tavakkolian 
<9nut@9netics.com> wrote:

>> Another thorny
>> issue is what to name the package, since you can't start a
>> package name with a digit.
>
> arabic numeral 9 is very close: ۹
>
>

Re: [9fans] Go

[John Waters]

or "tissah-go" for that matter :)

On Wed, Nov 11, 2009 at 6:27 AM, Eris Discordia
<eris.discordia@gmail.com> wrote:
>> arabic numeral 9 is very close: ۹
>
> Puny pedantry: that's a(n) Hindi/Indic numeral. 9 is already an "Arabic
> numeral."
>
> If playing on numerals is allowed why shouldn't they call it IXgo or even
> Kyuugo?
>
>
> --On Tuesday, November 10, 2009 22:47 -0800 Skip Tavakkolian
> <9nut@9netics.com> wrote:
>
>>> Another thorny
>>> issue is what to name the package, since you can't start a
>>> package name with a digit.
>>
>> arabic numeral 9 is very close: ۹
>>
>>
>
>
>
>
>
>

Re: [9fans] Go

[roger peppe]

the thing i think i'd miss most moving from limbo
is discriminated unions. what would a go-friendly
way of describing, say, a 9p message look like?

i suppose you could just type-switch, but then
you still lose the nice statically declared aspect of an
algebraic type.

Re: [9fans] Go

[Roman Shaposhnik]

On Tue, Nov 10, 2009 at 10:00 PM, Russ Cox <rsc@swtch.com> wrote:
> On Tue, Nov 10, 2009 at 5:04 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> On Tue Nov 10 20:02:34 EST 2009, mirtchovski@gmail.com wrote:
>>> but will it run on Plan 9?
>>
>> would the authors care to contrast go with limbo?
>
> The common concepts—channels, slices, and cheap processes—
> have their differences: channels can be typed as one direction or
> another, slices have a cap, the processes can be muxed onto
> multiple OS threads instead of limited to a single OS thread.
> The new concepts are new and shouldn't be ignored: interface types,
> the approach to constants, the package system, initialization,
> methods on almost any type, the very simple approach to name
> visibility (case-sensitive instead of public/private tags), and
> other things I am forgetting all combine to make Go feel like
> a very different language than Limbo, or for that matter Alef or
> Newsqueak.  Don't fall into the trap of thinking it's just like one
> of those.

First of all -- as usual -- thanks a million for chiming in. Two question:
    1. what would be the best way to quickly wrap one's head around Go?
    2. Is there an alias dedicated to "Go for Plan9/Inferno/Limbo old geezers"?
        I'm pretty sure such a perspective could be a little odd for most of
        of the folks on go-nuts, but at the same time this is a perspective I'm
        personally coming from (and it looks like I'm not alone).

Thanks,
Roman.

P.S. Its just not fair to have "Go for C++ programmers" ;-)

Re: [9fans] Go

[Russ Cox]

>    1. what would be the best way to quickly wrap one's head around Go?

The quick way to at get a feel for it is to read the tutorial
and Effective Go, both linked on the left bar at http://golang.org/.

>    2. Is there an alias dedicated to "Go for Plan9/Inferno/Limbo old geezers"?
>        I'm pretty sure such a perspective could be a little odd for most of
>        of the folks on go-nuts, but at the same time this is a perspective I'm
>        personally coming from (and it looks like I'm not alone).

Pick one - 9fans or Go Nuts - I'm not sure either has high enough
SNR right now that you'd be in the way.

Russ

Re: [9fans] Go

[andrey mirtchovski]

> Pick one - 9fans or Go Nuts - I'm not sure either has high enough
> SNR right now that you'd be in the way.

okay, here goes:

$ export GOMAXPROCS=4000000000
$ 6g sieve.go ; 6l -o sieve sieve.6
$ ./sieve
throw: all goroutines are asleep - deadlock!

panic PC=0x7fff5fbff5a8
throw+0x3e /Users/andrey/go/src/pkg/runtime/runtime.c:74
	throw(0x2d91e, 0x0)
nextgandunlock+0x15a /Users/andrey/go/src/pkg/runtime/proc.c:339
	nextgandunlock()
scheduler+0xe0 /Users/andrey/go/src/pkg/runtime/proc.c:497
	scheduler()
mstart+0x2d /Users/andrey/go/src/pkg/runtime/proc.c:391
	mstart()
_rt0_amd64+0x76 /Users/andrey/go/src/pkg/runtime/amd64/asm.s:47
	_rt0_amd64()

Re: [9fans] Go

[Russ Cox]

On Wed, Nov 11, 2009 at 9:08 PM, andrey mirtchovski
<mirtchovski@gmail.com> wrote:
>> Pick one - 9fans or Go Nuts - I'm not sure either has high enough
>> SNR right now that you'd be in the way.
>
> okay, here goes:

I meant for discussion of Go on Plan 9.  Your message
seems to have nothing to do with Plan 9.

> $ export GOMAXPROCS=4000000000
> $ 6g sieve.go ; 6l -o sieve sieve.6
> $ ./sieve
> throw: all goroutines are asleep - deadlock!

That's not fair!  The minimal version of this is:

GOMAXPROCS=2147483648 sieve

You can guess what's going on.

Russ

Re: [9fans] Go

[Jeff Sickel]

now now...

On Nov 11, 2009, at 11:25 PM, Russ Cox wrote:

> On Wed, Nov 11, 2009 at 9:08 PM, andrey mirtchovski
> <mirtchovski@gmail.com> wrote:
> 
>> $ export GOMAXPROCS=4000000000
>> $ 6g sieve.go ; 6l -o sieve sieve.6
>> $ ./sieve
>> throw: all goroutines are asleep - deadlock!
> 
> That's not fair!  The minimal version of this is:
> 
> GOMAXPROCS=2147483648 sieve
> 
> You can guess what's going on.

In this day and age of so much 64bit goodness and so many multi-cored systems available, shouldn't it be something more like:

GOMAXPROCS=`hoc -e '2^32'` sieve

let alone `hoc -e '2^64'

Then again, if my hoc were arbitrarily clean enough, it should return a valid result for:

% hoc -e '2^2^2^2^2'
hoc: exponentiation result out of range in -e near line 2

(the Plan 9 error code is 'hoc: exponentiation result out of range near line 2')

I want my BigEnough numbers for those times when enough just isn't enough.  Hrm... maybe it's time for a hoc.go or an apc.go implementation.

-jas

Re: [9fans] Go

[Russ Cox]

> In this day and age of so much 64bit goodness and so many multi-cored systems available, shouldn't it be something more like:
>
> GOMAXPROCS=`hoc -e '2^32'` sieve

I'll worry about that when someone puts
a 2147483648-core system on my desk.

Russ

Re: [9fans] Go

[Michaelian Ennis]

On Thu, Nov 12, 2009 at 1:39 AM, Russ Cox <rsc@swtch.com> wrote:
>> In this day and age of so much 64bit goodness and so many multi-cored systems available, shouldn't it be something more like:
>>
>> GOMAXPROCS=`hoc -e '2^32'` sieve
>
> I'll worry about that when someone puts
> a 2147483648-core system on my desk.

<Insert witty remark regarding desk fortitude here.>

Re: [9fans] Go

[AngryDude]

> > There's no 9p implementation.  I thought about writing one
> > a couple times, and I'd love to do that (I want to write acme
> > extensions in Go), but it hasn't been a priority.  Another thorny
> > issue is what to name the package, since you can't start a
> > package name with a digit.

shouldn't you be writing a plan9 server to talk to go-pee. ken has 20
years to distill and improve 9p, imagine what it will look like.