Re: [9fans] Go
Russ Cox
<joseph....@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
<mirtc...@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 <quan...@quanstro.net> wrote:
> On Tue Nov 10 20:02:34 EST 2009, mirtc...@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 <ro...@shaposhnik.org> wrote:
> P.S. Russ, are you working for Google now?
Yes.
On Tue, Nov 10, 2009 at 5:27 PM, andrey mirtchovski
<mirtc...@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 <23h...@googlemail.com> wrote:
> have you also seen this vid?
> http://www.youtube.com/watch?v=rKnDgT73v8s
Yes.
Russ
Anant Narayanan
On Tue, Nov 10, 2009 at 5:27 PM, andrey mirtchovski
<mirtc...@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.
Skip Tavakkolian
> issue is what to name the package, since you can't start a
> package name with a digit.
arabic numeral 9 is very close: ۹
Roman Shaposhnik
> On Tue, Nov 10, 2009 at 5:04 PM, erik quanstrom <quan...@quanstro.net> wrote:
>> On Tue Nov 10 20:02:34 EST 2009, mirtc...@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" ;-)
Eris Discordia
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
John Waters
Russ Cox
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
roger peppe
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.
Nick LaForge
> 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
andrey mirtchovski
> 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()
Russ Cox
<mirtc...@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
Roman Shaposhnik
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.
Jeff Sickel
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
Russ Cox
>
> GOMAXPROCS=`hoc -e '2^32'` sieve
I'll worry about that when someone puts
a 2147483648-core system on my desk.
Russ
Devon H. O'Dell
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.
>
>
Michaelian Ennis
<Insert witty remark regarding desk fortitude here.>
erik quanstrom
> > 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
Devon H. O'Dell
>> > 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
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
> > 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.
erik quanstrom
> 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
LiteStar numnums
Also, wrt pointers, the original Primos was written in Fortran IV, although it was later moved to the PL/I dialect PL/P.
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
Tharaneedharan Vilwanathan
and other critical sections. (was this a problem with alef?)
Roman Shaposhnik
>> > 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.
Nick LaForge
> 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.☺