Last week Apple released new versions of their iMac line of desktop computers and the iPad Pro. They all shared one thing in common - The M1 chip. This is clearly the trend moving forward for Apple and it’s something I’ve been keeping a watchful eye on.
Prediction: Apple will stick their own A-range CPUs in their Macbook Air lineup.
— Rob Morgan (@_rjm_) March 5, 2015
At Gruntwork, nearly all of us develop on the previous generation x86 MacBook Pros, so I was very interested to see how Apple Silicon goes for us developers. As it turns out, my lovely partner recently decided to purchase a new M1 MacBook Air and whilst I don’t normally write about hardware, much like the AirPod Pros, the new M1 MacBook Air is one of the best devices I’ve ever owned* (technically not mine).
Daily Workflow
I’m not a snowflake when it comes to my daily development workflow. As much as I like to think I’m doing something fancy, truth be told, the most exhilarating thing I do is dabble in virtual machines from time to time. Even then, they are written in Go which is now natively supported since version 1.16.
Besides the thrill rides, I’ll often find myself using Zsh and Vim, SSH-ing into servers, executing Terraform and building and pushing Docker images. It was important for me to get a basic developer toolchain up and running on macOS Big Sur, and fortunately Homebrew is now at a point where everything basically works out of the box providing your Terminal is running natively on Apple Silicon (more on that in a second).
After running various scripts and manually downloading a darwin_arm64 version of my terminal program, I was able to install Homebrew in /opt/homebrew instead of /usr/local. I also sprinkled a bit of cross-architecture compatibility in my dotfiles including my .zshrc:
# vim setup
if [ "${ARCH_NAME}" = "x86_64" ]; then
alias vim=/usr/local/bin/vim
elif [ "${ARCH_NAME}" = "arm64" ]; then
alias vim=/opt/homebrew/bin/vim
fi
export EDITOR=vimThat way I can easily keep compatibility with my existing Mac whilst preparing for the inevitable switch in the future. The key thing here was ensuring that I was using a darwin_arm64 Terminal emulator so Homebrew compiles and installs native Apple Silicon versions of my toolchain. You can do this with the built-in Apple Terminal, just be sure that Rosetta emulation is disabled.
Besides getting the developer toolchain sorted, I also installed the range of Apps I use on a daily basis - Zoom, Slack, Google Chrome, 1Password, Pixelmator Pro for quick image editing and Visual Studio Code for banging out the next software masterpiece. I even dabble in a bit of Logic & Final Cut Pro with the hopes of one day becoming an audio visual master. The good news is that all of these Apps now run natively on Apple Silicon! The one thing I couldn’t get to work properly was Packer, but I had a little bit more luck under Rosetta emulation.
Terraform
At Gruntwork, we use Terraform. a lot. In fact, our core product now has more than 350,000 lines of code so it seemed to me like a good idea to actually try and get some of this up and running. I took some of our products for a spin and realised I needed to do a tiny bit of lifting. Firstly, as a way to handle module dependencies in older versions of Terraform (there was never an easy way to do this), we take advantage of a workaround using the template provider. Much to my surprise, this provider was deprecated with no published darwin_arm64 releases, so initially I had to run it under Rosetta emulation.
I decided to deploy our Landing Zone for AWS solution as it’s technically one of our most complex products with roughly 30,000 module and provider dependencies computed in a single Terraform apply. I found that execution times had dramatically decreased from approximately ~20 minutes on my 2017 i5 13” MacBook Pro to roughly ~10 mins on the new MacBook Air. Next, I decided to throw away the emulation and tried to install native Apple Silicon versions of the Terraform providers instead.
All the providers were downloaded automatically once I’d switched to the darwin_arm64 version of Terraform, but I had to manually compile the template provider and install it myself:
$ cd $GOPATH/src/github.com/hashicorp
$ git clone [email protected]:hashicorp/terraform-provider-template.git
$ git checkout v2.2.0
$ make build
$ mkdir -p ~/.terraform.d/plugins/registry.terraform.io/hashicorp/template/2.2.0/darwin_arm64
$ cp $GOPATH/src/terraform-provider-template ~/.terraform.d/plugins/registry.terraform.io/hashicorp/template/2.2.0/darwin_arm64/terraform-provider-template_v2.2.0_x5After a little bit of Bash-foo, I had a fully functioning native-Apple Silicon Terraform experience up and running! The good news is that I was able to further reduce the execution times of our Landing Zone solution down to somewhere around ~5 minutes. The end result was jaw-breakingly fast!
Docker
Docker is probably one of the more controversial changes when using a Mac with Apple Silicon. In case it wasn’t obvious, there’s a slight difference between the x86 and ARM64 architectures. It wasn’t properly supported for a long time but is now available as a GA release. This is great news for many of us, particularly our Co-Founder who was complaining last year.
The new ARM-based Macs, or rather, the new macOS they require, have some pretty major drawbacks:
— Yevgeniy Brikman (@brikis98) November 13, 2020
1. They send Apple message of each and every program you run, when you run it, with your IP/location. https://t.co/5yFGwQjmvb
2. Docker doesn't work. https://t.co/DksTu9S6HH
😡🤦♂️😤
Some of the included binaries are still technically using darwin/amd64 and there are still a lot of missing images for the ARM64 architecture, but you can pass --platform linux/amd64 to run an x86 image under emulation.
Hardware & Device Support
The hardware was really a game-changer for me and I’ll explain why: One of my biggest gripes with computers for a long-time was plugging in an external display. Back in my Windows days and even with Intel-based Macs it would typically result in the display going blank, then redrawing several times and finally scattering my Desktop icons desperately all over the place. It was a moment I dreaded at the beginning and end of every work day. Now, with the M1 MacBook Air, I can plug in an external display and the picture appears in a near split second. I can even adjust the screen resolution and the external monitor will display these changes instantly. Kid me not, it really felt magical the first time I tried it. I don’t care if the GPU will never be able to play AAA games (I’m sure its probably capable), whatever they’ve done inside this tiny SoC is incredible.
I was warned that there might be a few compatibility issues with the devices I use, but so far my external Logitech C920 webcam has been working great.
Bittersweet Goodbye
Reluctantly my test drive was short-lived. It turns out my partner wanted her shiny new computer back and I’ve been fondly reminiscing of an M1 ever since. If the rumours are true, then I’d be very interested to see how the new MacBook Pros fair later this year, but besides that I feel that the Apple M1 MacBook Air is possibly the best laptop I’ve ever used. The Touch Bar is gone, the reliable keyboard is back and the eerie fan-free silence during a Zoom call with Slack and Google Chrome open is incredible. I look forward to the day when I have an M1 in front of me again.
