BT

Google Experiments with a New Language, Go

by Abel Avram on Nov 11, 2009 |

Go is a Google experimental open source new language resembling C but adding features like reflection, garbage collector, dynamic types, concurrency, and parallelism.

Presenting Go on the Tech Talk Channel, Rob Pike, one of the main developers working on Go, said the language is experimental because “we don’t think this is the answer to everything, but we are playing and we think it is the time to tell the world about it.” The language has concurrency constructs included in the language and aims to let developers easily create parallel tasks. According to the authors, some of the language’s goals are:

  • Combine the efficiency of a static language with the easiness to write of a dynamic one. Practically, the developer can choose to go static or dynamic.
  • Safety. The language is type-safe not allowing implicit casts, only explicit ones. Also, the language is memory-safe by not providing pointer arithmetic and doing garbage collection.
  • Provide a good support for concurrency and communication.
  • Have an efficient, latency-free garbage collection.
  • High-speed compilation.

Some of the interesting features are:

  • The language has pointers but not pointer arithmetic.
  • It has interfaces.
  • It has synchronous channels. These channels are used to communicate between threads and is the basis for concurrency. Go encourages sharing memory by communicating it, not communicating via shared memory. Only one thread can have access to a shared value at a time, the values being passed between threads through channels.
  • Goroutines. This is another construct used for concurrency. A goroutine is simply a function or a method prefixed by the “go” keyword. A goroutine is associated with a thread and communicates with other goroutines through channels.
  • Parallelization. Goroutines and channels can be used to run computations on multiple CPUs.
  • Reflection. One can reflect on all types, channels.
  • Embedding. It is a simple way of inheritance.

The language has two compilers so far. One comes with different names for different platforms, 6g – 64-bit x86 or AMD64, 8g – 32-bit x86 or AMD32, and 5g for ARM platforms. The other compiler is gccgo. 6g has a mark-and-sweep garbage collector while gccgo has none, but a new one based on IBM’s Recycler is under work for both compilers. There is no IDE nor a debugger yet. 

One of the Go’s aims is to have a fast compiler which seems to be attained. The 6g compiler is faster while the gccgo is slower but creates more optimized code. The compiler generates only machine code, no bytecode for a VM, and they say it runs almost as fast a C code being 10-20% slower than similar C code.

There are already many libraries available for basic functions but many more are needed. Godoc generates documentation from source code similar to javadoc. Go is an open source project released under BSD license.

Resources: Go website, Go presentation by Rob Pike.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

needed ?? by Erik Gollot

we really need a new language !
It is the central problem of computer science nowadays, sure !!

might be nice... by Stephen Johnston

I hope it's nice... it's time for C++ to die in a grease fire.

Horrible Name by Nick Main

Surely Google could have come up with a more search-friendly name ?

Re: might be nice... by totoro totoro

>>I hope it's nice... it's time for C++ to die in a grease fire.
or java

Re: needed ?? by Luis Espinal

needed?


Maybe not by you. If people had stopped every time somebody questioned a need for a new language or software technology, we'd still be coding COBOL on punch cards.

Re: needed ?? by Luis Espinal

needed?


Maybe not by you. If people had stopped every time somebody questioned a need for a new language or software technology, we'd still be coding COBOL on punch cards.


I'll elaborate further:

In all *hard* engineering disciplines, engineers learn all the attributes of each and every type of material and tool available, they study the attributes resulting from their combination, the limitations of those combinations, and new ways to combine stuff to go over those limitations (or to bring about new properties.)

But in software, unlike our *hard* engineering colleagues, we have it backwards. It's not just one, or a small minority, but a large group that always groans at the sight of something new, however exploratory and tentative that might be (as if we have come up with all the tools necessary to tackle all the technical problems we have with sufficient satisfaction.)

Given that the constructs we create are far more complex, and inherently more fuzzy and chaotic that what's done in the other engineering disciplines, it just doesn't compute to do software engineering AND NOT ACTIVELY pursue new lines of research and implementation to (hopefully) get better solutions to the problems we face.

Re: Horrible Name by Bruce Rennie

Ha! Here's the really funny part: someone's already used the name. Apparently Google didn't even google it.

Just Another C++(C) Killer (JACK) by Oleg Olenin

Why not to support D language?

PS I was discussing with my colleagues Go today, they did not know about it, and when I was introducing it I mixed up Google with Microsoft. So my direct words were - "Have you heard about some new language from Microsoft called Go?".
I think my mistake has more sense than to be only mistake :)

Re: Horrible Name by Luis Espinal

Nope. The other language you are referring to is "Go!" not "Go" :)

Re: Just Another C++(C) Killer (JACK) by Luis Espinal

Why not to support D language?


Marketing? A tactical business decision? Or maybe the features of Go are specific for problems they've found within Google for which maybe D is not sufficient or perhaps not the best fit? Perhaps they have encountered specific technical difficulties with which this specific language is more suitable?

I mean to ask that question, you should at least present a comparison between D and Go. That way the question can have some ground with which readers can ponder on the answer.

I'd be honest that I don't know squat about D, but one feature in Go that I really, really, really like is that a class does not have to explicitly implement an interface to be used as a subtype of it.

That is one hell of a powerful, flexible (and even natural) feature right there. I think any discussion between languages should at least have a comparison of main features and the brevity (or verbosity) with which main tasks can be accomplished.

It sounds like a C or even C++ competitor by Dominique De Vito

Well, at first glance, Go looks like a language from an inside Google startup.

But it has some chances to grow :
- fast compilations,
- native compilation + byte-code generation for VM (=> different markets are targeted)
- may be more easier to master than C or C++ (for example, there is no pointer arithmetic)
- it looks like to provide a better support for concurrency and communication than C or C++ (multi-core CPU are targeted).

Then, Go looks like a better C, or even, C++ : it may be replacing (in the future) C++ internally used inside Google.

Dominique
www.jroller.com/dmdevito

Re: Just Another C++(C) Killer (JACK) by Nathan Youngman

I don't know anything about D either, but at least I'm aware of it. From Pike's presentation, he said there hasn't been any new systems languages in a decade (or something along those lines, paraphrasing here). Oblivious?

Totally agree on the approach to classes that avoids fixed hierarchies, there are some pretty cool features in Go.

Re: Structural typing by Daniel Kristensen


I'd be honest that I don't know squat about D, but one feature in Go that I really, really, really like is that a class does not have to explicitly implement an interface to be used as a subtype of it.


Structural typing can be very handy for dealing with code you don't have control over, but I much prefer the approach taken by e.g. Scala where structural typing is not the default, but an option you have when you need it. After all, interfaces often have more semantics associated with them than what is conveyed by the method signatures, and when you use structural typing you lose this part. So if I have to choose one of the two, I prefer nominative typing.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

13 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT