Channels ▼

Al Williams

Dr. Dobb's Bloggers

Ready, Steady, Go!

July 27, 2012

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

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 two 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, a will swap variables a and b).
  • For and if statements don't take parenthesis.
  • You can put statements between an if statement 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 new and make statements create objects dynamically (with garbage collection). The new statement allocates memory, whereas make is more like a C++ constructor call for certain types.
  • The switch statement can have multiple (and non-constant) cases. By default, cases do not fall through (although there is a fallthrough keyword 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.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.