Classes (or Not)

 

Classes (or not)

Classes-or what are used for classes-are strange in Go, and it'll be interesting to see how people respond to their unusual nature. To create a class, you first declare a structure type. Structures can only include member variables, no functions. To add member functions to the structure (resulting in a class with methods), you create a function that includes an additional parameter called a receiver. For this receiver, you specify your structure. After that, instances of the structure can call the function as a member, just as in other object-oriented languages.

But this design results in something fascinating: Your receivers (that is, the types you're adding your methods to) don't have to be structures. They can be any type, including an array type or any of the built-in types. The end result is that you can enhance the built-in types, resulting in an extremely object-oriented language akin to something like Smalltalk.

But this isn't really that unique if you've worked in C#, which uses extension methods. Or, if you've worked in JavaScript, this will remind you of how you can use prototypes to add methods to existing object types (such as String). But it is rather unique in a natively compiled language. (And it makes me wonder how some coding purists will feel about it. When C#, for example, added such a feature, some people were upset because it's easy to hack into existing objects and create confusing code.)

Another interesting thing about Go is that it doesn't support inheritance. Why not? Because instead it's interface-based. This might take some getting used to, just as JavaScript's prototype-base takes some getting used to.

Concurrency

If you look through the specification, you'll see a "go" keyword (which is where the language gets its name-plus the fact it's the first two letters of Google). At first I figured this was an old goto statement, and I skipped over it. Wrong.

Go supports what Google has called goroutines. This is basically a coroutine approach, but much more lightweight than what you'll find in some other compiled languages. The whole idea behind goroutines is that data can be shared between the routines, except only one can access it at any given time. Basically that means a form of mutexes is built right into the shared data using what are called channels.

To call a function concurrently, simply use the go keyword, like so:

go list.Sort();

Take a look at the official docs for more information. I think you'll find it pretty cool.

More Features

The language is sprinkled with some nice little features: Declarations can be grouped, which is handy and quick. Break statements aren't necessary inside switch cases. The default is to not fall through. (How many times do you actually use the fall-through feature in C/C++, anyway?) But if you need it to fall through, you simply add the word "fallthrough" at the end of the case. And your code is all package-based, similar to the way Java is.

Further, the language includes a small but rich set of packages for handling things like I/O, regular expressions, and more. Google apologizes that the package list is still small, although growing. Frankly, I think it's already pretty good.

Interestingly, the language also includes no assert. That's fine with me, and I completely agree with Google's rationale that too many C/C++ programmers use assert as a crutch, resulting in bad code. (I, for one, never use assert in my code for just that reason. Well-constructed code should properly handle error condition without covering every other line of code with calls to assert.)

Finally, the language includes garbage collection, even though it's compiled and doesn't make use of an external runtime. The presence of garbage collection is a sticking point for a lot of C++ purists who have grown up with the mantra "for every new, there's a delete." But in today's huge systems, garbage collection is more of a necessity, even though some people might object.

Final Analysis

I like Go. I think we're going to see more of it. But do we need it? I would say yes, and here's why. Let's face it--C++ programming is a pain. Don't get me wrong, I've programmed extensively in C++ since about 1990. I've written several books about it, and have worked with advanced concepts in C++. But that doesn't change my feeling that C++ is a pain in the butt to code compared to modern languages.

With that said, modern, runtime-based languages are not light-weight, and they're not usually as fast as something like C++. Yes, we have just-in-time compilers that can really haul. But they still rarely keep up with a well-written C++ program.

Go seems like the decent replacement for C++. It's truly compiled, yet it has the beauty and simplicity of modern languages. It isn't perfect--for example, I'm not sure I welcome the return of pointers, and I'm a bit suspicious of the interface and receiver approach to classes and objects. That's going to take some relearning, which isn't always easy. But I would say that Google is certainly on to something here.