Slashdot Mirror
Go, Google's New Open Source Programming Language
Many readers are sending in the news about Go, the new programming language Google has released as open source under a BSD license. The official Go site characterizes the language as simple, fast, safe, concurrent, and fun. A video illustrates just how fast compilation is: the entire language, 120K lines, compiles in under 10 sec. on a laptop. Ars Technica's writeup lays the stress on how C-like Go is in its roots, though it has plenty of modern ideas mixed in:
"For example, there is a shorthand syntax for variable assignment that supports simple type inference. It also has anonymous function syntax that lets you use real closures. There are some Python-like features too, including array slices and a map type with constructor syntax that looks like Python's dictionary concept. ... One of the distinguishing characteristics of Go is its unusual type system. It eschews some typical object-oriented programming concepts such as inheritance. You can define struct types and then create methods for operating on them. You can also define interfaces, much like you can in Java. In Go, however, you don't manually specify which interface a class implements. ... Parallelism is emphasized in Go's design. The language introduces the concept of 'goroutines' which are executed concurrently. ... The language provides a 'channel' mechanism that can be used to safely pass data in and out of goroutines."
Go Go Google Language!
It's a small complaint, I'm sure.. but couldn't they have given it a name that you could, you know, Google?
Vowels aren't nearly as expensive as they used to be back in the day.
It'd be a nice touch if they'd add vowel support in package names.
Go has garbage collection and lacks pointer arithmetic. So... it won't replace C++, then?
Why was that so easy and quick to say? I really don't understand the repeated banging-head-against-wall that language inventors are doing. There's a good reason why C++ is still in wide and very popular use: precisely because it does have explicit memory management and pointer arithmetic. C++ is a static, explicit language. Go is not. It will not replace C++, and no language will until that is understood.
The problems C++ need fixing are elsewhere. The syntax needs cleaning up. The ABI needs rationalizing between architectures. Multiple inheritance needs some taming (ditch 'virtual' multiple inheritance - it's insane), but not removing. Interface-only classes need promoting to a full type rather than inferred from being 100% pure virtual (and even then there's usually a non-pure-virtual destructor for stupid foot-bullet-avoiding reasons). There needs to be saner syntactic sugar for repeated operations (like python's 'with' keyword). Templates syntax needs to be less verbose and more automatic (already being worked on for C++0x but at this rate will be C++1x, keyword 'auto').
Stop trying to replace C++ with a language that does not fulfill every aspect C++ covers. If you ARE a language inventor and reading my comment, answer this: can you write a cache/MMU interface or an interrupt handler in your language? If the answer is no, go back to the drawing board.
Loves Unix? Ken Thompson invented Unix. Along with Dennis Ritchie. In 1969.
So yeah. It would be kind of silly if he created something Windows-only...
I think the niche it's aiming at is the, "Look! We made a programming language, too!" niche.
This fellow has been working on his own programming language, also called "Go", for a decade. Even released a book about it. He filed an issue in the tracker for the Google language: http://code.google.com/p/go/issues/detail?id=9
'Every story, if continued long enough, ends in death.' --Ernest Hemingway
If this language becomes as popular as Perl, then 120,000 lines will soon become 1,200,000 lines. That is exactly what happened to the Perl interpreter and compiler.
Also, just like Java, the new Go language (due to the immense respect for Google's scientific prowess) will likely receive accolades: "it is the best, final language that we will ever need". The same was said for Java. It was sold as the ultimate final language built on 50 years of accumulated knowledge of language design and computer architecture. Upon the introduction of Java, company after company blindly adopted it.
Was Java the final language satisfying humankind's computing needs? No. Was adopting it worth the cost? Maybe.
Now, we have Go. Is it a massive improvement over C and Java, thus justifying spending milions of dollars to train programmers? Only the future will tell.
I've noticed a lot lately, especially here on Slashdot, that the most vocal opposition to degrees, education, certifications etc. come from people (not you in this case but it's relevant to this thread) who do not have this type of formal education in the first place.
I wonder if this says more about the US (since Slashdot is US centric) education system, the people being educated or the people not being educated. No offense, but if you've never met a competent CS graduate, you're either working in some very strange bottom-of-the-barrel outfits or with some very strange people. The CS graduates I've worked with have universally been careful, methodical and not dickish in the slightest.
Just about the only downside I've noticed is with fresh graduates who can be a little naive about business practices and real-world scenarios but they catch up far quicker than the "loner geek rebel" types whose best code at best qualify as clever but unstable and unscaleable hacks.
I'm sensing a bit of projection from the uneducated crowd, tbh.
From Golanf.org : "With Go we take an unusual approach and let the machine take care of most formatting issues. A program, gofmt, reads a Go program and emits the source in a standard style of indentation and vertical alignment, retaining and if necessary reformatting comments. [...] We use tabs for indentation and gofmt emits them by default. Use spaces only if you must."
Of course you realize ... this means war.
If all else fails, immortality can always be assured by spectacular error.
I find that if you shorten long words arbitrarily, it actually increases the writing time.
I could write ConnectionManager pretty quickly just due to typing experience in English. The words just flow from my brain onto the keys without even thinking about the individual letters. But if you shortened to CnnctnMgr then you have to think about it every time you type it out, what letters have I taken out again?
It gets more difficult when you're working off someone else's code. If you shorten long words but not short words then later on when you're looking at new code it takes much longer to get used to variable names. If you stick to a convention and don't shorten any words, you sometimes don't even need to see the variable being used to know what it's called, and can use them without thought.
ArrayIndexOutOfBoundsException is clearly a poor joke, however. I always hated that one.
being vague is almost as cool as doing that other thing...
I still have to write destructors that clean up all the pointers to an object, and all garbage collection does is force me to call the destructor as a function, rather than a more clear 'delete' statement.
Um, no. The whole point of a GC is that you don't have to explicitely deallocate something. RAII is a problems with GCs, but you didn't mention that. As for the cache hit thing, it sounds quite suspicious to me, more details please. Also, to get that last bit of performance, you have to go low-level, that is true. Note however that explicit memory management is unnecessary in 90% of a typical application's code.
Now, since the ownership problem is passed over to the GC, things become possible that were previously hard to do. Try real closures for instance: C++0x is struggling with this, since they may extend the lifespan of a variable, which is bad if said variable was lying on the stack. Such problems simply go away with a GC. Note that C++0x rvalue references are in fact a solution to a problem caused by the explicit memory management in C++.
There is a reason many people want an opt-in GC in C++0x..
This sig does not contain any SCO code.
I think they just chose the name so they can use their page numbering convention for future versions:
version 2: Goo
version 3: Gooo
etc.
I will probably mature around the time Goooooo comes out - can't wait to use it!
sic transit gloria mundi
Go seems to suffer from the problem of not being done. Case in point: exceptions.
Google's C++ style guide forbids exceptions. This is because of historical reasons - Google's codebase is not exception-tolerant.
Because Go doesn't have exceptions, programmers won't write exception-safe code. Since Go is garbage-collected, this is less of an issue compared with C++, but there are still cases where things like file handles or external resources need to be cleaned up.
Two, three, or four years down the road, it's going to be hard to use exceptions in Go, because the existing code that's out there won't inter-operate properly with code that throws exceptions.
In my opinion, exceptions are absolutely, positively critical in a modern imparative programming language. Exceptional conditions happen. Parsers get data in the wrong format. Network requests time out. Hardware fails.
There are some exceptional conditions that should never happen, and if they do they should kill the system and print something that lets you track down the problem. Exceptions provide this behavior for free; simply don't catch them and you get at least a stack trace when they occur.
The alternative is to write a bunch of error handling code to print out debugging information and exit. Then you call it from everywhere that one of these critical errors occurs.
Except, what if you want to handle one of these critical errors? What if you're calling code that exits if it fails, but you want to report errors in a different way? What if the exceptional case is supposed to happen, like if you're writing unit tests?
The other type of error isn't critical. Maybe it's a network timeout or a parsing error, neither of which should probably crash the system (in most cases). Here, you want to handle the error and take some action, like re-sending the data or asking for input from the user again.
Error codes work here, except that they're cumbersome. Want to include information on exactly what kind of a parser error occurred? Now you're going to have to return both an error code and an error string. Maybe you'll even return an error object.
What if the error occurs in a private method (lowercase first letter in Go) that's called by the public method (uppercase first letter in Go)? With exceptions, you just throw in the private method. With error codes, you need to check for an error code in the public method when you call the private method, then pass the error along.