Thanks, good .. er .. pointers. :)
-- Owen
On Jul 23, 2010, at 9:16 PM, Roger Critchlow wrote:
Oh, I see Pike gave two other talks at OSCON, no video but pdfs of the
slides:
Go http://www.oscon.com/oscon2010/public/schedule/detail/15464
Another Go at Language Design
I thought they were good references.
;-] ;-]
--Doug
On Sat, Jul 24, 2010 at 10:59 AM, Owen Densmore o...@backspaces.net wrote:
Thanks, good .. er .. pointers. :)
-- Owen
On Jul 23, 2010, at 9:16 PM, Roger Critchlow wrote:
Oh, I see Pike gave two other talks at OSCON, no video but
It's interesting to see that go already is in the language shootout:
http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php#table
That means its pretty serious .. lota work to get the benchmark programs
written.
But they have a long way to go: above them are c/c++,
Pike actually says in a few places that there could be pointers when his
examples use arrays. Declaring an array argument doesn't automatically get
you a pointer to the contents of the array, but you can get one if it's
needed. So pointers and references.
I found it even more apparent on this
Roger Critchlow wrote:
I found it even more apparent on this pass through that the language
is very well built for the kind of parallel programming that I've
become comfortable with in erlang. That is, go makes it very easy to
spin off a new thread/process/goroutine and establish
On Sat, Jul 24, 2010 at 12:46 PM, Marcus Daniels mar...@snoutfarm.comwrote:
Roger Critchlow wrote:
I found it even more apparent on this pass through that the language is
very well built for the kind of parallel programming that I've become
comfortable with in erlang. That is, go makes it
Roger Critchlow wrote:
I can see that goroutines and channels are appealing programming
abstractions, but have a hard time believing they could scale.
Seems like the more goroutines you have the more CPU cycles that
will be absorbed in switching amongst them.I could see how
