Recently I’ve been musing about C++ versus C. As predicted, a few people have told me that there is no way they will let anyone pry loose their beloved C compiler from their hands. I’ve said it before, and I’ll repeat it: I really do enjoy programming in C. But I also enjoy learning new languages, even some that I will probably never use in a serious project.
Why learn languages? For one thing, sometimes they give you ideas. You may have heard of the Sapir-Whorf hypothesis (which according to Wikipedia is really a misnomer for “linguistic relativity”). There are a lot of nuances to the concept, but basically it holds that our view of the world depends on our language.
Of course Sapir and Whorf were speaking of human languages, but I do think it holds true for computer languages as well. I also think we tend to slide into language boxes. That is, you tend to write in your preferred language even when using a different language, to the extent that is possible.
Today there are a host of languages floating around for desktop and web development. Sometimes you hear that one is being targeted for “embedded” development. That depends, of course, on how you define embedded. If you consider little BeagleBone and Rasberry Pi computers embedded, then Python or even JavaScript could be an embedded language. Most of us, though, don’t think of them that way.
Sometime I see a fledgling language (like Cobra) that I think might have promise in the embedded space. Then I notice that it is bound to the Windows/Linux/Mac platforms and I am in no mood to port them so I usually move on.
I’ve heard a lot lately that Google’s Go language is a “systems programming” language (another definition we could probably argue over). I noted a few things of interest. First, it does target processors like ARM (although, honestly, I haven’t tried it to see how robust it is yet). The second thing I noticed is that there is a front-end for GCC (gccgo). In theory, then, anyplace I have GCC I could have compiled Go code. Interesting.
The Go tour is very nice and you can do most of it online without any software download, but it is necessarily aimed at people who might not be C programmers. I thought I’d take a little time to give you a quick introduction of Go from a C programmer’s perspective.
The first thing you’ll notice is that Go has some Java influences. The first example program in the Go tour is:
package main
import "fmt"
func main() {
fmt.Println("Hello, 世界")
}
NOTE: That strange bit at the end is some Asian character set. See http://tour.golang.org/#1.
That package directive looks awfully Java-like. So does the import. Functions start with func, which is odd but you get used to it.
Notice the lack of semicolons? You can use them if you like, but generally any complete end of line has an implied semicolon. That means that you can’t mess with the brace positions. The brace must be on the same line as the func. In general, where you need a brace you always need a brace (as opposed to C where the brace is only needed if you want to group lines together).
The biggest difference that you notice right away is that type names come after declarations. So:
func add(x int, y int) int {
return x+y
}
This is a function called add that takes to integer arguments. The last int indicates the return type of the function. Flipped around from C (if you want to understand why, read this).
Other major differences from C:
- You can declare variables with
var, but you don’t have to in many cases. The:=operator creates a variable and assigns to it (the=operator assumes the variable exists). - Symbols that start with uppercase letters are exported, others are not.
- Functions can return multiple results. Assignments can be done in parallel (e.g.,
a,b = b,awill swap variablesaandb). Forandifstatements don’t take parenthesis.- You can put statements between an
ifstatement and its test. - Go supports pointers but not pointer arithmetic (although slices serve a similar purpose); pointer access is automatic through the . operator (no – operator needed or provided).
- Maps (arrays with arbitrary indices) are built-in.
- Functions are a type, making it easy to write things you’d use function pointers for in C.
- The
newandmakestatements create objects dynamically (with garbage collection). Thenewstatement allocates memory, whereasmakeis more like a C++ constructor call for certain types. - The
switchstatement can have multiple (and non-constant) cases. By default, cases do not fall through (although there is afallthroughkeyword to allow that behavior where desired).
One thing seems odd for a modern language: Go doesn’t exactly have classes. What it does have is a way to attach methods to types. But you don’t have to define that method with the type itself. The same goes for interfaces. You can define an interface without modifying classes that already implement it, even if they were written before the interface existed.
The other major feature is concurrency (light-weight threads) and a form of communications between them. I’m not sure how well that would translate to embedded systems. The same goes for the garbage collection. I haven’t torn into the library enough to tell how well you could stop these “features” from being used. It could be that one day we’ll see an effort to make real time Go (similar to the Real Time Java standard). I do know my friends at OAR have a port for RTEMS (a real time OS).
I’m not sure Go differs from C enough to stimulate the Sapir-Whorf effect, but it does have some interesting features. What’s your experience with Go? Are you using it in embedded software? Or anywhere? And yes, of course, C is still a perfectly fine choice.
