One of the lovely things about Zig is the way that you can just create types at compile time and then use these types elsewhere in your code. The other day, I needed a sparse array, but the standard library didn’t really have what I wanted. I could have used one of the hash-map types, but that wasn’t really what I wanted, so I created my own.

pub fn SparseArray(IndexType: type, DataType: type) type {
}

The first thing I did was create a function that returns a type and takes in the types that I’d be using for the index and data types.

Creating a list of primes takes a long time. This is especially true if you are using the very boring and simple sieve algorithm. In Zig, this is really easy to do:

pub fn calculate_prime_numbers (comptime size: usize) std.StaticBitSet(size) {
    var sieve = std.StaticBitSet(size).initFull();
    sieve.setValue (0, false);
    sieve.setValue (1, false);

    const last: usize = @intFromFloat(@sqrt(@as(f64, @floatFromInt(size))));

    for (2..size) |n| {
        if (sieve.isSet(n)) {
            results.set(n);
        }
        var i: usize = n * 2;
        while (i <= last) : (i += n) {
            sieve.setValue(i, false);
        }
    }
    return results;
}

The code is really simple. It creates a sieve set, initially full, except for the number 0 and 1. It then looks through from the number 2 up to the square root of the size parameter given, and then looks at the sieve set to see if the bit is set. If it is, then it goes from double the current number up to the size parameter jumping by the current number, and clears the sieve bits, effectively removing all the multiples of the current number as not prime for future iterations.

I have a theory that when writing software, you will do the best work only after you have written it for the third time. My hypothesis is that the first time you write it, you don’t really know what the problem is and therefore are just stumbling in the dark trying to find your way. The second time you now understand the problem domain but you haven’t worked out the best way to implement it yet. And then the third time you not only know the problem domain but understand the implementation constraints and therefore can create some of your best work.

My first real paying job was at a small little company in Camberley, England called Digital Integration. The two-line advert in a national paper said “Assembly language programmers wanted for real time software”. The number included was in Reading, England. I called the number and the next week was on a train to Reading to go to an initial screening interview.

I don’t remember much about that interview. It was in a boring office building walking distance from the station. I had just finished university and had no luck getting a job, along with about two thirds of my course. This was 1991 and a recession was hitting hard. Nobody was hiring. I still remember the careers advice given to us in the last year of university: