Blog

Qt taught me to appreciate explicit contracts. It also taught me that an object system can acquire enough machinery to qualify for municipal government.

Go’s interfaces are much smaller. A type satisfies an interface by having the required methods; it does not announce the relationship in its declaration. This took a moment to trust because I am used to inheritance lists serving as signposts.

Here is the complete contract for something that can write bytes in my current snapshot:

type Writer interface {
    Write(p []byte) (n int, err os.Error)
}

A file can satisfy it. So can a network connection or a tiny test buffer. The producer only needs to accept a Writer:

func emit(w Writer, p []byte) os.Error {
    _, err := w.Write(p)
    return err
}

There is no implements Writer marker on those concrete types. The advantage is that I can define an interface around behavior already provided by a package. The package author did not need to predict my abstraction.

The cost is discoverability. Looking at a type alone does not list every interface it happens to satisfy, and a method signature changed by one type is a different method. Compiler diagnostics are doing more of the navigation work than they do in my C++ code.

I tried the idea on a log collector. The original Python version accepted anything with a write method because Python accepts almost anything until it does not. The Go version gets similar flexibility, but verifies the method set when values are connected. That is a useful middle ground.

Interfaces also contain a pair of things internally: a dynamic type and a dynamic value. An interface value can therefore be non-empty even when the pointer stored inside it is nil. I managed to manufacture that surprise within an hour, which must be some kind of efficiency record.

These details reflect a weekly build, not a stable release. Method-set and library conventions may still shift. Even so, structural satisfaction feels important. It encourages narrow contracts at the point of use rather than grand interface families designed before the program has done anything useful.

Go declarations looked backward to me for about ten minutes:

var retries int
var name string = "worker"
count := 12

Then I noticed how little punctuation I was reading. The name comes first, the type follows when it adds information, and := handles the common local case. My C-trained eyes complained briefly and then found something else to complain about.

The useful distinction is scope, not cosmetic shorthand. := declares at least one new variable in the current block. Assignment remains plain =:

line, err := readLine()
line, err = readLine()

Multiple results make this especially tidy. In C I would pass pointers or return a status and fill a buffer. Here the success value and os.Error can travel together without inventing a result structure.

There is also a practical trap. A short declaration inside an if can create a new variable and leave the outer one untouched. The compiler catches many unused-variable accidents, but it cannot infer my intention. Small scopes help.

This is from the current weekly snapshot, so details may move. The principle already feels sound: write the type when the reader needs it, let the initializer provide it otherwise, and keep declarations close to use. It is not revolutionary. Neither is a sharp screwdriver, and I still prefer one.

Since I cannot give any details on Suquia Creek, what could I possibly talk about? A lot, it turns out. I can talk about things I’m learning while working on the project.

Ah boy, am I learning!

It turns out Suquia Creek is going to be the longest, most complex project I’ve worked on. Until SC came along, the longest project of my life had been Lava Peak, which ran for about two years. But that included post-launch activities. We managed to go from ideation to shipping in just under a quarter (I even won an award because of that back in 2007.) Suquia Creek, on the other hand, is scheduled to ship in 2014! That’s nearly half a decade of work.

As well, for earlier projects I only had to worry about software. Suquia Creek, however, is also hardware. And on the software side, off the top of my head, it involves —

• Processor µcode

• Chipset code

• BIOS extensions

• Firmware code

• Drivers

• An SDK

• User-level apps

• And a few other things I can’t say without revealing more than I should.

Bottom line: it’s huge as far as I’m concerned! And we should support multiple versions of Windows and one distro release of Linux. It also involves several cross-functional, geographically-dispersed teams based mainly in Argentina and the US, but also with some smaller efforts coming out of China, India, and Israel. That amounts to six different timezones, for a current maximum time difference of 17 hours.

And then we come back to schedule. I have no idea what I’ll be doing at home during this weekend, but I have to have a rough idea of what we’ll be delivering on, say, week 41 of 2013! That assumes the world will not end in 2012, of course.

This week we had our first engineering meeting to plan on a tentative schedule. Late next month I’ll be flying around between Silicon Valley and Silicon Forest to work out the (semi-)hard schedule. By then, we’ll actually have one internal alpha release in place already. After that, we’ll have another alpha before our first “release”, an internal proof of concept, which will then be used by customer as part of a (quasi-confidential) pilot. The customer? One of the world’s largest… well, can’t say what is their industry yet. It’s huge though.

After that pilot I expect to be able to open up a bit on what the project actually does. In the meantime, I’m going to be sharing my learning experience.

It’s going to be an exciting half-decade for me :–)

Most of my systems work still begins in C. If the job needs a user interface, it usually grows a Qt shell. If it needs to be finished before lunch, a Python script appears beside it and quietly becomes permanent.

That arrangement works, but every boundary charges rent. The C tool has ownership rules, the Qt side has objects and signals, and the Python helper has a different deployment story. I have spent an unreasonable amount of time explaining to machines where their libraries live.

I have been trying the experimental Go compiler from the weekly snapshots. It is plainly unfinished, and the language may change under this post, but it occupies an interesting spot: compiled programs, garbage collection, a small syntax, and concurrency that does not begin with a page of pthread ceremony.

My first useful experiment was the sort of filter I normally write in Python:

package main

import (
    "bufio"
    "fmt"
    "os"
)

func main() {
    in := bufio.NewReader(os.Stdin)
    for {
        line, err := in.ReadString('\n')
        if len(line) != 0 {
            fmt.Printf("%d %s", len(line), line)
        }
        if err == os.EOF {
            break
        }
        if err != nil {
            fmt.Fprintf(os.Stderr, "read: %s\n", err.String())
            os.Exit(1)
        }
    }
}

ReadString may return bytes together with os.EOF, so the line is handled before the error. That keeps a final line without a newline. EOF ends input normally; another os.Error gets reported instead of masquerading as a clean finish.

On my snapshot, I build that directly with 6g and 6l. A later snapshot may spell an import or an I/O call differently; that is currently part of the admission price.

The pleasant surprise is not that this is shorter than C. Python already wins that contest while barely getting out of bed. The surprise is that the result is a small native executable and the source still exposes the mechanics I care about. There is no class hierarchy between the input and me.

I do miss deterministic destruction from C++, especially around Qt resources. Garbage collection is not a substitute for closing a file. Go’s defer looks like the intended answer for many such cases, and I plan to abuse it scientifically.

I am not replacing working C or Qt code. That would be migration as a hobby, a particularly expensive hobby. I am moving the little glue programs first and watching where the new language becomes awkward. So far, it feels less like Python made fast and more like C with several recurring arguments removed.

After I recently accepted my old age, I was talking to some friends who, to their own surprise, found they were old too. We were talking about when each of us started working with Linux and a friend noticed he had been working with Linux for 10 years. That’s when I realized it’s been a decade since I was first paid to work with the operating system.

I had been using Linux for a little while. My first contact with it was in mid 1995. I had bought a computer magazine from the UK that had this pink CD-ROM with something called Linux-FT.

One of the cool things about Linux-FT was that it had a licensed copy of the Motif window manager, which was pretty cool at the time. I had been using some RISC boxes in college running CDE, so I felt right at home.

Then in 1999 I was hired to help this company migrate from Windows to Linux. It was the first time I was ever paid to do anything related to Linux.

I went to work at Conectiva the next year, where I learned I didn’t know anything. What the heck do I do now? That’s also where I learned like never before, made lots of friends, and found the love of my life. (No, not another Linux distribution! I mean my wife! What’s wrong with you?)

In 2004 I left Conectiva and started working with one of the company’s founders on another Linux project. The work itself was interesting, but it was also my first contact with something that I would see a lot more in the future: the downright dishonesty of Linux entrepreneurs in Brazil. Of course, I then thought it was an isolated thing and decided I didn’t want to be a part of that and left the company in 2005.

That’s when I came to Intel to work at the CSO, a “personal” project of Andy Grove. CSO had a simple mission: to foster Linux usage by financing and providing engineering to business with good ideas. How great is that? I was going to work on my passion (Linux) and meet all kinds of people who shared it with me. What could possibly go wrong?

Oh boy.

In the following year I’d see things that would still make me sick years later. From businesspeople to self-appointed free software leaders, all I saw was guile and greed. It was such a disappointment that I requested a change. I stopped working with Brazilian businesses and projects completely, moving to support projects in other countries. Things were much better, which is another disappointment and one of the reasons why I hold us Brazilians in such low regard as a people.

Outside Brazil things were very different and despite some funny things here and there, I am proud of the Linux work I’ve done, especially the megalarge project with the government of Venezuela. I even met Hugo Chavez, which is funny considering my political stand 🙂

Regardless, I was also getting disappointed at other things as well. After years developing projects such as KDE, I was bored to death. I started witnessing things being done on other platforms and suddenly the Linux desktop just felt stale to me. It was dull and lifeless and at the same time I was doing all these cool stuff on Windows.

Add to all that the fact that KDE started getting full of kids adding more and more useless features… and politics… ever heard the one about the moppet who decided that all KDE About boxes should contain a thank-you note to American troops worldwide? And he wasn’t even American? You know what?

Screw Linux.

I dropped it like you wouldn’t believe. And it felt good. Not having to edit configuration files to do something simple made stuff pleasant again. I was introduced to Mac OS X and I loved it. It was Linux on steroids. All the good stuff without the kludge.

No more politics. No more GNU Slash Linux. No more open source vs. free software. No revolutionary-audio-framework-of-the-month. No juvenile cockiness. No rWindoze. No Micro$oft.

Just fun.

After nearly 15 years, I’m truly free.