Go, Google's New Open Source Programming Language 831
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."
Re:Build-in function library (Score:4, Interesting)
They also have a "spacewar" directory, currently empty...
Whenever Google announces something, you have to make the decision... jump on it immediately and get ahead of the curve, but risk wasting all that time if it doesn't take off? Or wait?
Not actually safe (Score:3, Interesting)
Re:Google search "Go" (Score:2, Interesting)
It's a small complaint, I'm sure.. but couldn't they have given it a name that you could, you know, Google?
Yeah, why couldn't they use unambiguous names like all other programming languages, like C, Java, Python and Ruby?
Sarcasm aside, I agree that the naming is unfortunate (although I love the Go Ogle debugger pun [golang.org]). The parent was probably referring to the common verb, but this will also make it much harder for Go players like myself to find books and stuff for the board game. This guy [google.com] isn't happy either.
"Systems" language? (Score:5, Interesting)
They're billing Go as a "systems language." If by "system" they mean "application server in a Google data center" then I suppose that's correct. Previously the term "systems language" referred to languages suitable for operation system implementation, including device drivers, virtual memory management and other persnickety low-level software. Lack of pointer arithmetic and explicit memory management probably precludes any attempt to use Go as a "systems" language by that definition (although there are exceptions [microsoft.com] to that thinking.)
There is too much competition from other fresh and well regarded "new" languages for yet another new entrant to gain much headway without something really novel to attract attention. Not that trying is bad; by all means keep at it. Can't afford the mental bandwidth to jump on more new bandwagons, however.
Who programs on Windows, anyway? (Score:1, Interesting)
Re:"Systems" language? (Score:3, Interesting)
Lack of pointer arithmetic and explicit memory management probably precludes any attempt to use Go as a "systems" language by that definition (although there are exceptions [microsoft.com] to that thinking.)
inferno is another exception to your definition of systems language. much of it is written in limbo, a direct ancestor of go. it too has automatic memory management and no pointer arithmatic and it works just fine
http://en.wikipedia.org/wiki/Inferno_(operating_system) [wikipedia.org]
http://en.wikipedia.org/wiki/Limbo_(programming_language) [wikipedia.org]
Maybe C really is "it" for now... (Score:3, Interesting)
Despite the large amount of enthusiasm for language design, modern mainstream programming languages don't fall far from the C tree.
Perhaps, like Qwerty, our C-based languages have evolved to be "good enough" for programming needs for the foreseeable future. Make objects, make functions, operate between the two.. sure DVORAK might provide 20% faster typing if you work at it for 3 years, but that's not really enough to warrant the switch. We're unlikely to see a jump again of the size from C to C++ before we hit a major structural change. I had thought the web might be that structural change, but that was well absorbed by extending existing ideas.
Personally, I just want to see programming languages that are more programmer fault-tolerant. I can type "pizza" into my phone and have Chuck-E-Cheese offer to bake one while I drive over, but if I accidentally type "plaeyrArray" instead of "playerArray," the whole world is clearly on fire and everyone is going to die. Why can't compilers be more intelligent about the types of errors they encounter in routine usage? For that matter, why are we still defining code chunks via brackets instead of the indentation that's already there?
Re:Build-in function library (Score:5, Interesting)
I have to agree with a couple of your points, however. It's an unfortunate truth, but a heck of a lot of programmers do qualify as dicks. I've worked with my fair share of them over the years, and I have to say I've never met a truly gifted coder with a CS degree. I'm not saying they don't exist, but I'll be damned if I've found one yet. Oddly, out of the "real asshole" crowd, many of them had a CS degree in addition to sucking at their jobs. The best coders I've worked with never even went to college, didn't finish, or graduated with a degree completely unrelated to computer science or IT.
Re:Build-in function library (Score:4, Interesting)
I view this as a defect, not a feature. Without competition, bad ideas and poorly implemented libraries (see large parts of Java's IO library with its 1 billion inheritances and its slow migration from old windowing toolkits) get used because its standard, where with competition they would die and better ones would quickly be written. I prefer the C/Perl system- preferably with a site like CPAN or boost that aggregates the good ones.
Holy Shitbags Binaries Are Static And *Huge* (Score:5, Interesting)
package main
import "fmt"
func main() {
fmt.Printf("hello, world\n")
}
Size of resulting binary: 581054 bytes on x86 Linux.
Re:Build-in function library (Score:4, Interesting)
They also have a "spacewar" directory, currently empty...
the documentation directory is empty, but the original pdp1 code is there as well as a pdp1 emulator to run it on: http://golang.org/src/pkg/exp/spacewar/ [golang.org]
Re:I suppose this is Windows-only once again... (Score:5, Interesting)
Re:"Go" name already taken for programming languag (Score:1, Interesting)
With google stealing "chrome" and now "go" from others, and their retarded "closure" library, and other example, I have to wonder if google engineers have zero creativity themselves, or if they are just assholes.
Re:"Go" name already taken for programming languag (Score:3, Interesting)
And C++ was screwed...
And JavaScript couldn't be called JavaScript because Java existed.
Re:Fixes problems misguided people think C++ has. (Score:3, Interesting)
Have you considered the D Programming language?
From http://www.digitalmars.com/d/ [digitalmars.com] "D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability.
The D language is statically typed and compiles directly to machine code. It's multiparadigm, supporting many programming styles: imperative, object oriented, and metaprogramming. It's a member of the C syntax family, and its appearance is very similar to that of C++. "
Not Invented Here (Score:3, Interesting)
Google is developing a real, 'Not Invented Here' complex. Rather than get behind Firefox, they produce their own browser. Rather than integrate tightly with OpenOffice, they produce Google Apps. Now they've written their own programming language. Go figure. And of course there's always those rumours of the Google OS...
How does it compare to D? (Score:1, Interesting)
Can some expert compare Go with the D programming language? [digitalmars.com]. Looks like D already took what's good in C and C++ and now it's a stable and damn fast language.
Re:Fixes problems misguided people think C++ has. (Score:4, Interesting)
The garbage collection haters and garbage collection lovers will never see eye to eye. Your parent is NOT wrong. He's probably just doing things you're not (and vice versa in all likelihood).
Smart pointers basically trivialize the so called "problem" of memory management and exception safety in C++. Simply put, it's NOT a problem. Before the boost library came into use it took SOME discipline, but nowadays it's just dead straightforward. A real time embedded programmer wants control over memory management. He can't tolerate garbage collection compromising his execution scheduling deadlines. It's a lot more than just Doom 8. It's your car. It's the airliner you ride in. It's process control.
Couldn't agree more with your last paragraph. These are the REAL places C++ falls flat on its head.
Re:Do *not* optimize for readability (do a tradeof (Score:5, Interesting)
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.
Missing the point (Score:1, Interesting)
You are all missing the important point of this language (or I've not seen anyone mention it yet), and that's it's concurency model. No, it won't replace C++ for some things, but it implements part of CSP, a VASTLY nicer model of concurrency than the traditional threads/locks model. You try write a program using threads and locks with 1000 threads all intermingling and prove there are no race hazards or deadlocks, then try the same thing in a CSP based language (this, occam-pi, Java with JCSP, even Javascript with worker threads). I can guarantee that for any non-trivial program this will be far easier in the CSP language, which is very important in the modern parallel market.
I was instantly happy to see this as I work in an area of concurrency research, involving a lot of CSP which most people have simply never heard of, or don't understand. This may not replace other languages for all things, but it will hopefully be a good start point to bring CSP to the masses.
Re:Build-in function library (Score:3, Interesting)
The easiest way is if there's already support for loading libraries (dynamically would be nice!) and calling functions defined in C. If there is, then there's huge numbers of libraries to leverage (not all of which are in C, of course; that's just the most common basic ABI by far). Wrapping them up into libs that feel native (or reimplementing if someone's feeling energetic) can be done piecemeal.
Replying to myself. Meh...
Of more concern is the fact that Go is a GCed language with a mostly implicit thread model. That means it is probably impossible to write libraries/modules in it that can be used from other languages (handling the integration of the threading and GC engines is... non-trivial). That means that the language designers probably think that they're going to be the most important and highest-level language in use in the application. Not very humble!
Re:Build-in function library (Score:4, Interesting)
From Go's FAQ [golang.org]
There is a “foreign function interface” to allow safe calling of C-written libraries from Go code. We expect to use SWIG to extend this capability to C++ libraries. There is no safe way to call Go code from C or C++ yet.
Re:"Systems" language? (Score:3, Interesting)
You cannot shoehorn a GC into C++. Explicit memory management is so tightly coupled to C++ that most attempts at introducing something automatic automatically impose significant restrictions on what you can do. This is OK for specific scenarios, not OK for a core language component.
Also, generic programming and template metaprogramming are one distinct advantages of C++ over other languages. The ability to metaprogram and use structural typing there is priceless, and some forms of metaprogramming are quite common in languages like Javascript, Lua, Python, Ruby, Lisp, Haskell. Without such features, C++ becomes little more than a Java without GC. No wonder the C++ committee put their focus on them.
I do agree however that a replacement is needed. Compile times are awful, memory usage while compiling goes through the roof, compiling errors fill several pages, the syntax is an abomination (especially in metaprograms), and it does not even have an optional GC.
No exceptions? Really? (Score:5, Interesting)
Go seems to suffer from the problem of not being done. Case in point: exceptions.
Google's C++ style guide [googlecode.com] 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.
Re:Build-in function library (Score:4, Interesting)
I have to agree with a couple of your points, however. It's an unfortunate truth, but a heck of a lot of programmers do qualify as dicks. I've worked with my fair share of them over the years, and I have to say I've never met a truly gifted coder with a CS degree. I'm not saying they don't exist, but I'll be damned if I've found one yet. Oddly, out of the "real asshole" crowd, many of them had a CS degree in addition to sucking at their jobs. The best coders I've worked with never even went to college, didn't finish, or graduated with a degree completely unrelated to computer science or IT.
My experiences are totally at odds with that - I've not yet found a truly gifted coder who doesn't have some degree - the best that I've worked with were the physics/maths graduates, the worst were the ones who had nothing but industry certification.
Re:Build-in function library (Score:3, Interesting)
Re:"Systems" language? (Score:3, Interesting)
I could see it as a 'system' language as in 'write applications in it'.
Not scripts, not embedded functionalities, not CGI, and no, not servers.
Just a typical "double click to start" applications that you install on your desktop computer, which serve a thousand various purposes. The kind of stuff you write in Delphi or Visual C++. Fast and easy to write, fast and easy to run. Not too far from the OS to require squeezing through 50 abstraction layers, not too raw to bother with kernel routine calls to do basic stuff. Not too abstract and high level to slow it down to a crawl like Ruby, not too low-level to be overly dangerous like C.
It's placed somewhere between C and C++ on the "level highness" scale, doing some things that were long overdue in C++ natively, but not compromising performance for stuff like advanced inheritance, exception handling and such.
Re:Build-in function library (Score:5, Interesting)
BTW, I agree that > 90% of code doesn't need to run fast or memory efficiently. I am a fan of Python, but when I'm slinging around gigabytes of data, I use C. Very few programmers ever need this kind of efficiency. Anyway, check out this table half-way down [sourceforge.net]. The "DataDraw" benchmark is still in C, but it uses carefully designed memory layout. The speed improvements are 100% due to cache hit rate improvements - 15X better than when using malloc for each object. Most slow memory-intensive programs waste most of their CPU time in L2 cache misses.
You want all the fields that are accessed in inner loops to be together in memory in dense arrays, and the other stuff should be somewhere else. So, for binary tree traversal, you want left and right and maybe some key value in a small structure, and all the other bloat needs to be elsewhere. Ideally, you allocate these structures which are nearby in the tree also nearby in memory. That way, when you get an L2 cache miss, the extra data you load into the cache likely contains data that will soon be accessed in the inner loop.
Garbage collectors typically don't bother allocating objects of the same type together. Careful management of memory can be a PITA, which is one reason I use the DataDraw tool for memory-intensive applications. It allows me to "cache together" fields, and puts wrappers around data access to hide the ugliness.
Re:Build-in function library (Score:3, Interesting)
In fact, good accurate garbage collections could be considered the most important development in programming languages since OO (and some even think more important). For instance, without garbage collection, this will (eventually) destroy the universe (where Foo and Baz are some classes):
return Foo(somearg).bar(someotherarg);
Compare that to the non-GC'd version:
foo = Foo(somearg);
result = foo.bar(someotherarg);
delete foo;
return result;
The second version is 4 times as long, but with no added benefit other than saving a bit of memory until the next GC run.
Re:Maybe C really is "it" for now... (Score:2, Interesting)
The reason that I still like my curly-braces is that I don't want the meaning of my code to change just because somebody (me?) changed the whitespace.
The reason that I now like my whitespace is that I don't want the meaning of my code to change just because somebody (me?) changed the curly-braces. In other words, it's nothing but personal preference.
Re:Found it... (Score:1, Interesting)
The problem with Java is that the checked exceptions don't include runtime exceptions, so a function "public void foo() { ... }" can still throw. Also, checked exceptions often result in lazy programmers just catching and ignoring exceptions (but maybe that's no different from other languages exceptions). I think it's fairly common to see checked exceptions in Java as a not-so-successful experiment:
http://www.mindview.net/Etc/Discussions/CheckedExceptions
Re:Fixes problems misguided people think C++ has. (Score:1, Interesting)
We are not all writing an OS, so why the hell do we all need to be using a language that can write an OS
Because at some point you *do* have to interface with the operating system, and if you're using the same language used to write the OS, it's a lot easier to do, not to mention being faster. Look at all of the hoops Java has to jump through with the JNI interface to execute native code.
Re:"Systems" language? (Score:3, Interesting)
You cannot shoehorn a GC into C++.
Actually, you can. See Microsoft Managed C++. But it's not happy. Destructors and garbage collection do not play well together. Calling destructors from the garbage collector introduces a kind of concurrency which leads to difficulties if the destructor does something non-trivial, like close a window or a file.
Re:No exceptions? Really? (Score:4, Interesting)
``Have a look at the Go Language FAQ. It states very clearly why exceptions were not added to Go.''
Yes, I've read that since. I hadn't bothered to read the whole thing before posting. :-)
It seems to me the reason Go doesn't have exceptions is that "we haven't figured out a good way to implement them yet".
``Have you ever considered, from an assembly language perspective, what exception processing looks like? How handling of multiple stack frames might take place?''
As a matter of fact, yes. I am the creator of the Voodoo programming language [inglorion.net], a low-level language intended to be used as an intermediate step to native code generation. I am currently working on mapping the constructs of my Mana programming language (which, alas, is mostly documented on paper as of now) to Voodoo. That includes exceptions, restarts, continuations, closures, tail calls, garbage collection, the whole enchilada. Exceptions aren't exactly straightforward to implement (they break call-return control flow), but it's work you only have to do once and that will save users of your language a lot of headaches. "It's somewhat difficult to implement" has never been a good reason not to have a good idea in a programming language, especially if it _has_ been done before.
``If you want languages that provide safety then you must sacrifice speed.''
Is that so? Care to back up that assertion with some argumentation?
``I, personally, have never found myself enamoured by exception handling. It has its conveniences but you may well find many old school programmers find themselves content without it.''
Oh, I manage just fine in languages without exception handling, too. I'd also manage just fine if all I had was an assembler. In fact, I've done just that for years (back when there wasn't Internet access where I lived). But that doesn't mean I don't think high level languages or exceptions aren't a good idea.
Re:Not actually safe (Score:3, Interesting)
Checking for CARRY flag is one instruction. Not exactly a dramatic slowing.
Moreover, at least on X86, easily predictable conditional jumps (like overflow checks) are often almost free. They execute in different hardware units than ALU instructions, and often don't add to the overall clock count or latency at all.