The Joel on Software Discussion Group

Google creating a new programming language -

http://www.theregister.co.uk/2009/11/11/google_go/

Thoughts?

They say speed comparable to C. Seems to allow for system programming features like pointers and bit operators. This means it might win where D is not getting traction due to lack of development resources. This is all good.

Would have been nice to have a little more brace language compatibility, like parens on if statements, even if more verbose. This is minor.

Compiles on unix based platforms only. That's probably big for many people.

Has a bunch of multithreading features which is good and is perhaps their main impetus, a C performing language with sane multithreading and string support.

In studying a couple hours, I wasn't sure if it is C object file compatible (and hence linkable), a critical feature, or if it has hashes and regexp.

To me, a D category language needs at a minimum strings, hashes, regexp and C object linking compatability.

Oh, the article says Ken Thompson and Rob Pike are the developers.

Well it's going to kick ass then.

Whereas Apple is adding GCD, OpenCL and closures to C*, Google take the founder of C and make Go.

My thought is that Go will be the new C++ to Apple's new Objective-C, but neither will be anywhere near as big as the real C and C++.

Diverting a bit, but there was already another language called Go!:

http://code.google.com/p/go/issues/detail?id=9

So, yet again we get a language that has the open-curlies on the END of the line, not the BEGINNING of the next line.  Then we have to suffer for three years until half the people get fed-up trying to figure out where the blocks open and put open-curlies on the beginning of the next line -- assuming that's even ALLOWED with these new "fixed formatting" languages.

And yet another cryptic and awkward syntax for passing and returning parameters -- it took years before the ANSI-C committee fixed the original K&R formatting.

I reviewed it quickly, and it doesn't look promising, that's all I'm saying.  But I've been wrong before.

Thats the last thing we need, another language with its own nuances. Yeah! as a developer I'm excited too, But in real life I learn new languages only when my work pushes me to migrate, or maybe I'm getting old.

Think about it, have we stopped using English because its old and switched to 'buzwahli'? We improve on what we have and move on, there's a limit. But then we have google and Rob and Ken behind it, maybe they could pull it off.

"there was already another language called Go!"

Yeah, the developer of that one even wrote a book about his language. He has filed a complaint with Google and they are just ignoring him, while their sock puppets suggest that he should change his name since they are bigger.

"Thats the last thing we need"

I could really use a next generation C that fixes certain issues, mostly the ones I mentioned. D was supposed to be that but just doesn't have the resources to get where it needs to be. Google's backing is a whole different game.

Now I don't know if Go is that language, but it would be cool if it was. Like I said, it needs to link with my current codebases in order to gradually convert.

The FAQ on the design motivations of the language is pretty compelling.

http://golang.org/doc/go_lang_faq.html

They say they are developing a concurrency safe garbage collector that will be a feature of the language and "latency will not be an issue." Sounds like that means garbage collection will be passed off to its own processor and will be written using lock free techniques that allow allocation to continue freely from other processors while one of them compacts the heap.

Another interesting thing is to allow all this to happen, although there are pointers, pointer arithmetic is gone and it is presumed that the compiler is sophisticated enough that there is no advantage to pointer operations over array indexing.

It's got REAL object orientation, not that bullshit pseudo-OO that C++ has.

If type A has a subset of any other type B's methods, then they are compatible.

I think "latency not an issue" simply means there is less for a GC to do when you have immutable strings, pass by reference and no pointer arithmatic.
So a continually running GC rather than a grind to halt for an unknown time every 10 minutes type GC, wouldn't need it's own processor.

The fundemental problems Go is solving is already here: proof is that Apple are trying to address them too, although in a different approach.

They don't nearly talk about channels and concurrency enough.  That's the compelling appealing thing in the whole effort, to my thinking.  We can of course solve the scaling-sideways problem using frameworks built on normal C/C++/Java/whatever but they always require the programmer to use some custom 'safe' subset of the fuller language and it's always been messy and buggy because of that.

A language where there are no threads, and the only way between these goroutines is message passing and perhaps platform-provided shared data structures (that can map to big distributed backends such as memcache/voldemort/redis/GFS2/mapreduce/etc) would be so robust.  I'm trying to spot - from the docs - if goroutines share state via global variables and closures and other nasties that'll make it a pain to actually really scale sideways safely.

Of all their decisions, the only one that pains me is lack of exceptions.  I worked on a massive codebase of an operating system without exceptions and careful error checking and reporting, and nobody ever got it watertight right.  My experience is that exceptions and automatic unwinding is far more robust, far less lightly to send the code up the ***

@Architecture Astronaut

How does changing from return error code to exception code make a big difference? Other than the invisible goto's with exceptions and the tendency for a module to catch the base exception class how would it of solved the problem you've listed?

I have no idea what operating system you where working on, though it seems to me that there was more going on than just returning error codes. Seems to me you could of had accidental complexity or essential complexity on the scope and size of the project.

Exceptions aren't perfect.  My experience (as an unexceptional programmer) is that error codes are much less perfect, however.

The Go site talks about the lack of exceptions and said investment in explicit error handling early in development will lead to better code.  That's possibly true, these people are pretty clever :)

But is the normal programmer clever enough to heed this advice?

Grab any code that uses, say, the normal posix library and see how carefully and correctly it handles error return values.  And how carefully it 'unrolls' if it does actually have an error.  The smart money is that it doesn't.  (Unless its some code you've personally written, where you spent more time on the error handling than the meat of the success case; and even then you'll secretly know you've cut corners with error handling more often than not.)

Sure unrolling in a GC language is not as tedious as, say, C.  But there are plenty of resources that do need unrolling still.

Exceptions and destructors and RAII just make all that part of the pain go away 99.9% of the time.

http://golang.org/doc/go_mem.html seems to answer a lot of my questions about concurrency and inter-goroutine communication.

And lists 'gotchas' and stuff.  Ouch.  Shame that variables aren't explicitly shared etc

AllanL5, I sympathise about the asymmetrical bracing - I hate that too. But the good news is that you don't have to do it. You're free to write Go in any style you like. I write C++ and Java professionally and always use symmetrical bracing. (And I don't pester my comments with asterisks at the start of every line either - and Doxygen and JavaDoc are still perfectly happy.)

At a  previous consultancy gig (Joost, since you ask) I asked a colleague why he preferred the asymmetrical style, and whether he could give any good reasons for preferring its lack of clarity. He ummed and aahed for for a while then said that, well, using my style made me look 'kind of old'. It's just a fashion, then. Like other unattractive fashions - flared trousers, reversed baseball caps - it will die.

Did anyone else think of MIT's language Cilk when they saw this?