Ask HN: What's your experience with working M1 and M2 Macs?
I have been planning to buy a Mac for my development side projects. Before I do this, I thought I would ask people here for their experience and suggestions.
I bought my M1 MBP around a year ago. It's now 4:30pm, and I've been using it since 10am, sitting at 50% battery without plugging in at all. Everything just works. I even installed Steam and can play some games on it. I hated the idea of owning a Mac and have fought tooth and nail until I finally bit the bullet. It's literally the best laptop I've ever owned and I am never going back.
My gaming rig is a different story, but for productivity on-the-go, there's no comparison.
I use a surface laptop 4 as my mobile workstation, and I like it overall, but the battery life leaves a lot to be desired. I'm OS agnostic, so the M1s caught my attention, but I use the touchscreen so much I'm not sure how happy I'd be with it unavailable to my workflow.
The Mac trackpads are so responsive that they feel every bit as good as having a touch screen.
The build times for a M1 are so fast that it's still a requirement for me though. The battery life for a MBP is amazing - it's almost a whole work day even on full compiling. So it's not really a choice.
Don't know about the scaling, but for window management I find the Rectangle app quite helpful.
I was super excited to get one for work solely because of all the buzz about battery life. But here I'm getting 5 hours or so. Firefox and Chrome are by far the biggest offenders, but I don't do anything special.
Just wanted to give another anecdote.
[0] https://ublockorigin.com/ [1] https://addons.mozilla.org/en-US/firefox/addon/auto-tab-disc...
I leave Javascript off by default on uBO and only allow it selectively when I have something to gain on each website.
My M1 Pro (work computer) is such a leap from my old intel machine. It's wild to be running our services locally with Docker, install Xcode, and take a Zoom call without so much as hearing the fans. Battery lasts all day. Don't know if I'd fork over that much money myself, though.
Wow. My ears started playing a loud phantom fan noise just reading that. No way my 2019 mac can handle that.
Some background: I’m a professional ML dev.
I would buy an M1 if given the choice. But be aware that you’ll need to devote at least two weekends to compiling your own dependencies. Tensorflow “just works”, but the source code on M1 is closed source(!). Pytorch is relatively ok to compile, but you’ll have to figure out how to build it as CPU only. Jax was painful (sorry to say), but they seem to have recently sorted out their build issues.
Then we get into the hardware roulette. My M1 air has a “pink screen of death” issue (Google it and you’ll find dozens of stories, with no resolution). So get ready for a small chance of randomly rebooting when you’re in the middle of dev work, which is always so-much-fun.
Even with these flaws, I’d still take it. Even LuaJIT seems to work on M1 now. But it’s not all roses like the rest of the comments are saying.
Also fork over the extra $800 for the upgraded ram and disk space.
The laptop itself is absolutely amazing. The thousand paper cuts with things not properly supporting m1 was just too much to bear.
I think if the projects you're hoping to work on have first class support for Apple silicon you can't find a better machine for love or money. If they don't, then steer clear.
This was almost me in Nov 2020 - Firefox barely worked, Docker was a no-go, Homebrew choked on probably 50% of packages - but in 2022 I can't recall the last time I ran into a Apple Silicon-specific issue.
The biggest incompatibility to point out is VMs. UTM exists, but is more limited in its capabilities and isn't as fast as I'd like. I've switched to using docker for everything instead of the standard Vagrant/VirtualBox setup everyone else at my org uses.
Because of its popularity, there are so many open source Ruby provisioning scripts you can use as a reference when provisioning your own VMs. You can also package up a provisioned VM as what they call a "box" that can be shared with other developers. It also natively integrates with tools like Ansible, Chef, and Puppet which make it a lot easier to manage the provisioning process.
And finally, many of the books and tutorials I've read use Vagrant, so it's much easier to follow along if you have Vagrant installed. For example I was recently reading the book Ansible for Devops by Jeff Geerling, and Vagrant and Virtualbox were used pretty extensively throughout the book.
Also, if you decide to package VMs to use in production it's pretty easy to integrate with Packer, which is another Hashicorp product.
Let's say I have a bug in prod. I just adjust my code, or Dockerfile, or some declarative config (say cloudformation or k8s definitions) and push it, and the CD doesn't say "go to existing machines and update them", it says "spin up containers with this new build and configuration, divert traffic to them, and then remove the old containers when safe". For me, provisioning is not something I want to touch outside of setting rules for autoscaling and saying "start using this new build". So arguments about provisioning (for my usecases) don't help - they sound like adding more responsibility onto me that computers already handle for me.
I don't feel that this declarative and abstract model is necessarily ALWAYS better than the imperative model you get with ansible et al. And I can think of an example: if you just need to run 1 command everywhere, ansible (or chef or puppet) is much faster than pushing a commit and waiting for the build and deployment. Or maybe if you needed a custom kernel. But I've never had an instance where those things were valuable or valuable enough; in all my experiences, fine-grain provisioning and treating servers like pets instead of cattle has never been a better choice (especially given bursty traffic), so I'm trying to broaden my horizons and understand where it would be a better choice.
I used to think managing servers introduced unnecessary complexity until I tried it, and realized it's really not as difficult as I thought. With kernel live-patching and unattended upgrades, I never have to manually update anything. Blue-green deployment is as simple as rsyncing files to the server, starting the updated app on a different port, and then updating your reverse proxy's config to point to the new version of the app. Any decent reverse proxy like Caddy or Nginx will support zero downtime config updates. You don't have to build containers, store them in a registry, or update any yaml manifests. Kubernetes manifests have gotten so complex that developers are inventing programming languages like Jsonett and Dhall to generate configuration files.
Also, the skills you learn from managing servers are incredibly portable. Some of the Unix skills that I've gained from playing around with EC2 instances have actually helped me manage my personal Mac (which is of course a member of the BSD family of Unix operating systems). When you learn Cloudformation those skills don't even translate to other cloud providers. The skills that you learn from managing a server are also incredibly stable and stand the test of time. Bash is older than Docker, the programming language (Golang) that Docker was written in, and likely many of the developers using it.
Docker is still not easy with the new architecture.
I had 2 main issues at first, but they are both resolved. One, if you want to use arm native Python conda now supports arm which is great. The second issue was docker, but it turns out that docker has qemu built in. here is an example of how to use x86 docker images on a M1 Mac.
docker run -it --platform linux/amd64 ubuntu bashAs a counterexample, I have a friend who wants to do embedded development and FPGA, for his use case a Mac is useless.
(Regular full stack software engineering, occasional graphics editing in Affinity Designer, audio work in Logic Pro, and video in Final Cut)
Here's a review comparison: https://www.youtube.com/watch?v=FWfJq0Y4Oos
The fact that your video is in Final Cut might give advantages to the M2, but I think for your use cases if the M1 Max is in your budget I'd either get that or wait for the M2 Pro.
I have a company assigned m1 macbook pro 13.3 inch. It's a machine to make sure that M1 mac stuff works and it was the only M1 series laptop out when I started so I've done all my testing on that machine.
Synopsis: It's great, great battery life, operating is slick, can't complain except there is only two usb-c ports and you need one for power.
Would I buy an M series mac for personal use? nope, I bought an M1 ipad, which is an amazing piece of hardware that will only get better with iPad OS 16.
Now enough about me, lets look at why your two choices are:
14" MBP M1 Max Pro OR Mac Book Air with an M2 in it.
Why are those your two choices? First the big boy in the mix ... if you want a massively capable development machine to do all of the development things and it still be a portable laptop then the 14" mbp M1 Max Pro is your choice. The 16 is too big and if you must have the beefier Ultra, you should probably just wait until the new Mac Pro comes out or look at the studio. The 16" MBP is a desktop workstation disguised as a laptop.
So if you're going to go all out with money, then stick with the M1 series, but get the 14" MBP.
If you want the best bang for your buck and don't need all that extra horsepower than the M2 Macbook Air is up for order and starts delivering in a week. It's ultra portable, functional, future-proofed, and better design than the M2 MBP which is your only other M2 option at this time.
Overall 9/10. Everyone already agrees they’re fast af and very capable.
The MBP is fine. Before it I had a top-of-the-line Intel MBP which was a detestable piece of shit because of its shameful keyboard. And of course Apple compounded the offense of the "butterfly" keyboard by depriving "pro" customers of an entire row of keys and replacing them with the embarrassing emoji bar. I HATED that computer, almost entirely because of the keyboard.
The newer (old-style) keyboard is merely OK, but it hasn't caused me to pound the shit out of the computer to the point where internal components started to protrude through the back cover. It still lacks a real Delete key, but that's just Apple being petulant babies.
The physical design does repeat an absurd blunder, though: The USB ports are, AGAIN, so needlessly close together that you can't use two adapters next to each other. WTF, Apple. WTF.
Performance-wise, I haven't stressed it too much but Rosetta seems to work admirably. The biggest issue is the unfeasibility of running Windows in Fusion on it, but I guess I'll just get a Windows computer at some point.
What kind of adapters? I have usb-c -> usb-a adapters that fit side-by-side just fine.
"You're posting too fast. Please slow down"
THEN WHY IS THE REPLY BUTTON ENABLED, rude jerks? WTF?
It's much, much better than the 2017 MBP it replaced, which I quite frankly hated using. Build times are so much faster. The vast majority of stuff does just work, and most of the time I can forget I'm using an ARM device.
However, it is not all sunshine and rainbows. It stutters hard when you push it: If I build, say, a large iOS app, it might be 5 times faster than before, but I can't do much while it is building because everything else can almost freeze up.
Additionally, it's not a perfectly backwards compatible system. Just this afternoon I had to locally debug a rails app, and a few of the gems just wouldn't compile. I find myself frequently having problems where it turns out to be an M1 thing, and the workarounds obviously waste time.
Also, I didn't pay for the device and would never have spent what is twice as much for the same performance (not to mention poorly designed hardware, see my other rants), and had I not needed a mac for iOS development, I wouldn't have got one. I don't find the mac a better development environment these days with WSL.
My personal laptop is an M1 Pro MBP and it runs faster, quieter, cooler, and has over twice the battery life.
That said, for both machines I do a lot of c++ compiling and the difference would be far less noticeable if I wasn't regularly running the cpu at 100% for significant periods of time.
I can only imagine that the m2 air with 24gb will be even better. To me the extra weight of the 14 wasn’t worth the extra monitor hookup. The tiny power adapter and no fan airs are where it’s at.
I really hope this isn’t artificial market segmentation by Apple to sell more Pros.
The single external display limitation is a big downside to some of the M1/M2 machines.
Issues I've had, any node project that uses a native plugin has had issues. If you're lucky they've updated. If not, .... I haven't seen if there's a workaround that doesn't require the plugin to update. As an example, the canvas npm package uses a native plugin and tries to download from somedomain.org/foo/bar/<arch>/the-bin and since arch is now arm64 it just gets a 404. Note, that issue might have been fixed but I've run into similar issues on other projects with other dependencies.
I assume most of it will be worked out soon.
I think of your domain is web dev, data wrangling, backend development (or obviously Mac/iOS development), M-series are the best machines currently in the market.
Main things: 1/4 the RAM so I just need to be mindful about what I keep open. That said, Apple’s memory management is amazing, so this isn’t as big a deal as I thought it would be. Use macports. Native binaries. I don’t use Chrome. I use Orion or Safari and those are great. For dev work, I do Bash, Ruby, and x86 ASM. I test the assembly stuff in UTM. Nothing I do is really heavy, except for compiling Linux for random hardware I have as a hobby pursuit.
The only thing I miss is prototyping setups of servers. I don’t have enough RAM or threads. This doesn’t bother me much tho, since cloud pricing has dropped since 2017.
But is the M2 v2 or is it another v1?
For example, I saw some mention of M2-specific thermal throttling: https://news.ycombinator.com/item?id=31941326 (also mention of slow 256gb SSD?)
> Although after all this I'm still not sure why the M2 MBP exists. By the time it's useful it costs nearly as much as the MBP 14" for the same spec which is far superior. And if you want to cheap it out, the M1 MBA is probably a better deal because it's far cheaper and perfectly adequate.
> I've decided I want to work for a company that values my time and developer experience
That’s one of the reasons we’re switching. Being Windows-only absolutely hurts recruitment.
Bought my daugher M1 MacBook Air. She constantly uses it unplugged and sometimes it feels it never discharges. After getting MacBook Air, she completely stopped using her iPad. Every time I want to take it to upgrade to latest os -- it is discharged and she always says last time used a week ago.
So, we're happy with M1 Macs. Going to wait for M3 before upgrading any of the systems.
Back when I was backend, though, Docker and LEMP virtualization was nightmarish to use (late 2020). Maybe things have gotten better.
In general, if you need legacy support, I'd stay far away from the M1. Otherwise go for it, best laptop I've ever had by far! (the only machine that comes close is the ThinkPad x1 Carbon)
Assuming software comparability isn’t an issue, I don’t know how I could recommend any non-M1/M2 machines in earnest.
Nothing can beat the price/performance of the M chips. There are some drawbacks, but overall it’s the best computer I’ve owned.
100% uptime except for software update restarts. Literally my only issue so far is some obscure software from the Census Bureau doesn’t work on the ARM Windows VM
Besides that, I love the M1 laptops, the battery life and performance to cost ratio
I would say that the developer experience on MacOS (with or without Apple Silicon) is "sufficient" for the vast majority of use cases, but there have been some pain points that I describe below as emblematic issues.
If you're developing applications that are intended to run on Linux servers or with specific hardware (CUDA/ML), perhaps MacOS is not the best tool for the job. In that niche, you're likely to be running a different OS, on a different architecture, and perhaps even relying on binary translation (Rosetta 2) to run the same applications as in your target environment. For these sort of "close to the metal" development roles, I recommend aligning your developer stack with your target.
For the vast majority of other development roles, from data engineering to frontend web, I admit to being a little envious of what folks say about their Apple Silicon devices.
Examples of issues I've seen recently with development on MacOS (with or without Apple Silicon). Keep in mind, these are edge cases these days and only listed as examples:
* Major impediments to using the Python gRPC library on Apple Silicon until very recently (https://github.com/grpc/grpc/issues/25082)
* Docker performance was dramatically worse than Linux & Windows until recently, with a recent update improving things for all Mac users, not just Apple Silicon (https://www.docker.com/blog/speed-boost-achievement-unlocked...)
* Performance of virtualized x86-64 applications work against many of the performance benefits of the M1/M2, this is especially prevalent with Docker containers that are built only for x86-64.
* Homebrew is an absolute must, do install script maintainers and colleagues a favor by installing the latest GNU userland (coreutils), as your Mac will come with GNU utilities circa 2007 (the last GPLv2 releases of GNU utilities)
Some docker containers are still problematic, but most native software and dev tools work flawlessly.
The M1s are attractive, and can hopefully retire with proper Linux thanks to Asahi. But I'm worried that I'll come to hate it only past the return window.
For personal use, my only workstation is a iPad Pro with a keyboard and mouse.
I love it -- super fast and quiet and the keyboard and build quality are great.
Such a little thing makes a world of difference.