K Cartlidge

Coding on the (Apple silicon) MacBook Air M1

10 January, 2021

A brief aside about availability

I’ve seen questions about availability asked elsewhere, as the new MacBook Air M1 currently has a little bit of a lead time - from when I placed the order (UK Apple Store) to the expected delivery date was around 4 weeks. For me, though, it arrived a week earlier than expected. Rather oddly, the Apple Store was still anticipating a week later on the very day DPD delivered it.

The machine I chose and why

Having done a fair bit of research in advance, I went for the entry level MacBook Air M1 8GB version with 8 CPU cores and 7 GPU ones, and am running Big Sur.

For reference, my development includes the following:

  • Go tools and sites
  • C# (DotNet Core) tools and sites
  • Node tools and sites
  • Python sites
  • Ruby tools
  • Lazarus tools

What I don’t use are Docker or VMs. I have in the past, but I don’t create mobile apps so need no emulators, plus I find that Go, Node, and DotNet Core behave consistently enough that I don’t need the abstraction layer. For Python I use virtualenv, for Ruby my stuff only runs in the cloud, and for Lazarus I’m fine with just the Mac.

Not needing Docker and VMs is the reason why I was fine with the 8GB machine. Although neither are production ready on Apple Silicon (when I last checked), I would expect to need 16GB+ to make sensible use of them.

How it performs generally

Using Visual Studio Code, the terminal, and any of the above, I easily clear a day’s development with about 40% battery remaining. That’s including a few hours of videos (training, plus the occasional Netflix) and the usual intermittent browsing.

I’ve only felt the laptop get slightly warm in one particular situation, detailed below. Generally it runs cold. Obviously it’s silent as this model has no fan. I have no issues with the memory or performance, no matter how many instance of VS Code, Brave, and Terminal (for example) that I open.

How it performs for development

What I use

Thing Version
VS Code ARM Insider’s build - runs native
Homebrew ARM version - runs native
Node v15.5.1 ARM via Homebrew - runs native
Go 1.15.6 AMD64 - runs in Rosetta
DotNet Core 5.0.101 - runs in Rosetta
Ruby 2.6.3 - runs fine; don’t know if Rosetta
Python 2.7.16, 3.8.2 - not tried yet

For reference, installing ARM Node via Homebrew was simple:

# Homebrew
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
# Node
brew install node
node -p process.arch   # shows arm64

How it performs

In the last couple of weeks I’ve sold my Lenovo ThinkPad L14 (Ryzen 7 Pro) and MacBook Air 2020 (Intel) as I couldn’t justify three current-year new machines. That means I cannot give exact benchmarks across the systems as they were gone before the new M1 Air arrived (I used a 2012 Air as a stop-gap). This is, therefore, subjective.

It builds Go and DotNet Core at about the same speed, possibly slightly faster, as the Ryzen 7 Pro (remember this Air is entry level M1 running fanless and cold and with Rosetta emulation for both compilers). It feels at least twice as fast as the 2020 Intel Air but, again, this is subjective from memory. The take-away is that there is definitively no degradation in performance even though both Go and Core are running in Rosetta. For Node it feels an awful lot faster.

One of the main benefits is that fetching dependencies in Go, Core, and Node, feels hugely faster. This is slightly odd as it is the same broadband connection as before, but somehow the network stack or the SSD or the CPU performance or something is making a noticable difference. As it happens this is the same with general browsing - the fetching and rendering is lightning fast (when the serving site is performant of course).

When your compiled stuff is actually running, bear in mind that your code is also running under Rosetta as both Go and Core still generate AMD64 binaries. And yet it still feels at least as fast as before, probably faster.

As for Ruby, it feels instant. I mainly use it for running my static site generator to produce this site, and when I do it locally (for proofing purposes) I’m used to a few seconds. Not now. It really is too quick to notice. I’m sure if I did some Rails (I haven’t yet on this machine) that may well change, but I would still expect a speed-up the way this is going.

The keyboard

As a developer this matters hugely. The 2020 Intel Air had the updated keyboard, not the widely disliked ‘broken’ one of the last few years, and it felt good. Better than most laptops, but obviously not in the same league as the ThinkPad. This M1 Air is on a par with the Intel version, meaning unless you need the benefit of the travel and tactility of a ThinkPad one you won’t get much better than the Air.

The keys are large, well spaced, don’t feel mushy, and have reasonable travel.

The backlight differs in that there is no longer a pair of keys to control it. The OS (or hardware) now handles it automatically based on ambient lighting. I thought I would hate that, as I often like a bit of backlight even in daylight, but it is actually very good. As I’m typing this it is normal daylight but still has around (at a guess) 10% backlight active.


I’ve nothing to say about it. I just don’t notice it. So fast that it’s not worth considering. Unless you’re copying huge files around, most things feel instant.

Applications launch in 1 or 2 seconds (Rosetta ones a little slower the first time after booting). Even larger ones like Page, Numbers, Scrivener, and VS Code, are running almost as fast as you can click them.

If you’re technically minded there are multiple benchmarks elsewhere.


Surprisingly few. Everything works, even where Rosetta is needed.

There is still the peculiar issue that the backlight will not kick in at boot-up until after you’ve entered your password, something which I really wish Apple would address as it is awkward at night as the initial password entry often requires me to tilt the screen to illuminate the keys. That was the same on the Intel version, though.

My big issue is that something drains the battery faster than it should, and I think I’ve narrowed it down. When I produce cross-platform builds using Go on the M1 Air about one if five occasions I get one of two issues:

  • either the build fails to complete,
  • or I get rosetta error: ulock_wait failure: 105

In both cases, re-running it (which takes no more than a couple of seconds) usually works fine. The problem is that after it happens the laptop slowly starts to get warmer (never hot) and battery drain increases (I’ve lost 10% in the last five minutes whilst typing this as it happened just prior).

There may be a workaround, but currently I just reboot and it is back to normal. It needs more investigating, but it feels like something under Rosetta is not releasing it’s thread and remains running continuously. Just typing this paragraph I’ve lost another 2% (I have Terminal going in the background and as said a short while ago I had the rosetta error).

We’re expecting native Go shortly so that hopefully won’t be an issue.

Edit: I’m aware of the 1.16 beta which is native Apple Silicon (ARM). Most production software should not be built with a beta, which is why I have focused on the Intel-under-Rosetta version.

For reference, the ARM version has none of these issues and works reliably (for me). As an example, my own static site generator in Go builds in less than 2 seconds — but that is via a script that cross compiles binaries for Mac (Intel and ARM), Windows, and Linux.

So that’s actually 4 builds, 3 of which are cross-platform, in under 2 seconds (my Intel MacBook Air 2020 took around 10 seconds).


Well worth the switch. Fast, silent, cold, and mostly no issues. It feels like the future.