Re: Coroutines and Go

[David Given <dg@...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

steve donovan wrote:
> http://golang.org/doc/go_lang_faq.html

I've been looking at Go. It's interesting, but a bit of a mess --- it
looks like the language grew organically rather than was designed. It
suffers badly from keyword hell, with names like 'iota', 'len', 'cap',
'new', 'make' all being reserved. It's missing stuff like exceptions.
There's a weird apologia for not having assert(). You can't use structs
as map keys (I don't know about pointers). It's got a rather muddled
mixture of pointer types and reference types. The word 'goroutine'
should be taken out and shot.

And personally, I think the syntax is appallingly ugly:

func (p *ByteSlice) Write(data []byte) (n int, err os.Error)

...defines a method on 'pointer to ByteSlice' (you can define methods on
pretty much any type, not just objects) with self called 'p', taking an
array of bytes called 'data' as parameter, returning a tuple of int and
os.Error.

There's a lot about it to like. The defer keyword is interesting (you
attach it to a statement and the statement is guaranteed to get executed
on function exit, after the return statement). Slices are basically
bounded pointers, and are used to pass around references to segments of
arrays. It's got multiple return values. Being able to define methods on
anything is nice, as in the above example. Interfaces work like in
OCaml, where any type implementing the interface is considered an
instance of the interface. And it's got goto!

And it compiles into real machine code, which is a huge plus; ix86,
amd64 and ARM, too. I don't know what the code is like, though.

But IMO there's nothing here that makes a compelling reason to switch to
Go from my current mix of C and Lua.

[...]
> We obviously don't need to be convinced about coroutines, but the idea
> of moving blocked ones to another thread is intriguing.

I'm a bit dubious about that concept.

Unless it's doing something clever with asynchronous I/O, it'll need to
allocate a new system thread for every blocked coroutine. So if you have
a system with 100000 coroutines, and 50% of them end up blocked on
system calls at the same time, won't the runtime suddenly have to
allocate 50000 system threads?

People may also find Issue #9 on their bug tracker amusing:
http://code.google.com/p/go/issues/detail?id=9

- --
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "There is nothing in the world so dangerous --- and I mean *nothing*
│ --- as a children's story that happens to be true." --- Master Li Kao,
│ _The Bridge of Birds_
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkr7+QEACgkQf9E0noFvlzinbACePBCi+1V5uKRYh4zvwYfiqcTd
8+4AnjuhKp2/FG8h3S9FCF8jfdRnEJvW
=Fvnx
-----END PGP SIGNATURE-----