[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Coroutines and Go
- From: David Given <dg@...>
- Date: Thu, 12 Nov 2009 12:01:09 +0000
-----BEGIN PGP SIGNED MESSAGE-----
steve donovan wrote:
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
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://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
-----END PGP SIGNATURE-----
- Re: Coroutines and Go, Roberto Ierusalimschy
- Re: Coroutines and Go, steve donovan
- Re: Coroutines and Go, Stephen Kellett
- Re: Coroutines and Go, Benjamin Tolputt
- Re: Coroutines and Go, Cheng, Long
- Re: Coroutines and Go, Enrico Colombini
- Re: Coroutines and Go, Duncan Cross
- Re: Coroutines and Go, Bulat Ziganshin
- Re: Coroutines and Go, Ralph Hempel
- Re: Coroutines and Go, Mark Hamburg