[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Coroutines and Go
- From: Stephen Kellett <lua@...>
- Date: Thu, 12 Nov 2009 12:24:39 +0000
Agreed. I have to stop and look at the code to read it rather than just
read it. Which for something which says it is C-like is very un-C-like.
And personally, I think the syntax is appallingly ugly:
They seem proud of not having enumerations. I'd have thought the
dreadful mistake of omitting them from Java (which has now added them
back into the language) had been learned by now. "iota" seems to be a
passing nod to the concept of monotonically increasing values (which is
how most enums, but not all, work). But integers are not a typesafe
substitute for enums. Perhaps I've missed something about Go and
enumerations (I was tired when reading about it) but I think that is
something that needs addressing. If I've got that wrong, someone please
There's a lot about it to like.
Yes. They seem to have taken quite a few concepts from dynamic languages
and type inference languages and added them.
Kind of like "finally", but for functions not exceptions. Very useful
for cleanup. Anyone that has seen C code with "goto cleanupAndExit" in
it will love defer. So much nicer (if it works like I think it should)
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).
And (on Windows) it will need to acquire 50GB (in 1MB contiguous chunks,
1MB per thread that needs its own stack) from somewhere for that. Ouch!
Good luck with that :-) I hope they've planned some sort of recover
mechanism for goroutines that can't be dumped to their own thread.
system calls at the same time, won't the runtime suddenly have to
allocate 50000 system threads?