Cobra Forums

Anyone had a look at (Google) Go ?

I played with it a couple days ago, but I didn't get to read all the docs yet. It looks like a good start for evolution in the systems programming niche. The syntax is fugly but I guess they were more concerned with quicker compilation times, consequently parsing.

What are your thoughts on Go-routines/channels versus the Actor model? It seems like there are more backers of the coroutine way these days.

I haven't studied both in detail enough to decide. Others should feel free to chime in.

I read all the docs and a lot of the library source code but havent downloaded played with it yet .. Havent got a working m/c it will run on

I was struck by a couple of things - theres a certain similarity to some cobra syntax concepts - var/local declarations name then type (without the leadin keywords ('as')
and a lot of good syntax simplicity/rationalisation wrt C.

Best of all its expressive and concise.

The channels idea looks interesting (developed from limbo) - turns the concurrency problem on its head - communicate shared state explicitly (migration of ownership)
rather than share state and limit access at particular time (locking).
Seems to aid expressiveness as well
I'm not really familiar or experienced with actors but it seems like the difference is focus on in-app process model vs in-app typed communication (piping).
I suspect communication is easier to grok than multiple message-passing lwp-like things

The lack of a traditional OOP model/constructs is interesting too - reading over it looked like the 'duck-interfacing' was an interesting ( and simplifying ) approach to take but it
looks like the addition of some of the syntax flattening with anonymous types in structs provides much of what you want for an OO design without the overhead/constraints ...
I havent internalised that yet - need to actually bang on it a bit
However the library code seems to reinforce this as a valid direction(gives equivalents of composition, mixins and extensions all with the same single concept)...

I quite like the use of typed multi var fn returns (allowing OOB error returns) and receiver syntax and simple visibility specification as well..

Still some directions to be determined wrt generics and exceptions and some experimental attitude wrt testing and integrity checking ( assertions etc) amongst other things
but overall it looks like a very creditable improvement on a C descendant systems programming Language

Skimming the forum postings it looks too like theres a strong perception here too that you cant have a language that doesnt have the supporting crutch of full IDE suport..
Also there too I get the impression that a lot of people-who-post have opinions about languages and features that are based purely on one mainstream language and an inability
to read docs and code

I dislike curly braces but even with them it's fair to say the syntax is very concise. I often wished for not having "as" and "of" in Cobra so the Go way resonates well. I think I'm starting to prefer the truly parallel way coroutine way by which they tackled parallelism; the first class citizen feel makes it slightly easier to think of parallelism for me.

The multi var return is definitely interesting. I can see why they are not sure about exceptions as this approach can fulfill most error handling needs.

Overall I can appreciate the simplicity they are trying to achieve and I think it can give both C, C++, and C++0x a good run for their money. With more optimizations and a good windows port looks like systems programming can be more fun. Especially since the the main cross platform issues can be worked out in the standard library and not have code littered with preprocessor directives.

I feel like coroutines are lacking in that they won't take advantage of multiple CPU cores due to being cooperative multitasking. I'm not opposed to their use for structuring a program, but now that everyone is on multi-core CPUs, I lean towards threads.

They are not coroutines but goroutines, Goroutines are multiplexed onto multiple OS threads.

Ah, thanks for the clarification. So is that something that could be mapped into a .NET or JVM language?

My guess is that for best performance we would need some native OS lightweight thread management, (i.e. fork() ), that may be one reason to why golang is lacking windows support nowadays.