Hacker News Reader

Comment by dkarp | Hacker News Reader

M1 is amazing and I bought my partner one and she loves it.

However, when it came to buying a new engineer on our team a laptop, we had to go with the last 2020 Intel model.

We still have some uncertainty over whether or not our development tools/environment will work on M1. Many python packages will take longer to install I imagine (if there are no wheels for the M1 mac, not sure if that's an issue) and I suspect some won't build at all. I also have some concerns over our Docker environment building.

Is there anyone doing python development and using Docker who can share their experience so far?

Edit: please also share non-python development experience, it's really interesting to hear

View on HN

As an engineer on an M1, I have to say you made the right choice. Half the stuff that I try to work on is just straight up broken, especially Python/AI related tools. I have to switch to my Linux laptop regularly to get anything done. I've wasted days just trying to get certain dev tools working.

I have hit the same problems with Python deep learning tools. Apple’s version of TensorFlow was an OK start. If you like conda, they now have pretty good support for M1. I have the usual Docker problems, and I don’t think that they will get sorted until many more pre-built containers are also built for ARM.

That said, I love my M1 MacBook Pro and for now I don’t mind too much keeping my old MacBook nearby.

I've found the experience better, most stuff I've used works out of the box, but there are often weird lib problems that require various hacks. You then can't check them into source control as it'll break intel users, and it becomes a bit of a headache remembering all this.

I think the situation should continue to improve, but there is an extremely long tail of stuff to get working.

The other thing I would mention is that Rosetta is very very slow. A lot of the initial impressions made out it was basically a bit slower, but for a lot of stuff it's slow as hell. You do not want to for example run an IDE in Rosetta.

Apple should really hire a couple smart devs to just focus 100% on getting working M1 wheels on PIP for all the most popular Python libraries (same for conda forge). Seems like a no-brainer given their dominance in laptops for software developers. I'm sure the community would just do it on its own, but if they can speed up the process by 6 months they will be able to sell enough extra units to pay for the devs.

Maybe they have, but whoever does the work, there is a lot of ground to cover in the space of developer tool chains. It's going to be a minute to get to a point where devs don't feel like they have to make compromises.

I just default to an x86-emulated terminal and everything I use on my M1 works exactly as it did on my Mid 2015 MBP, except faster. The only exception is virtualization, which only works if there’s an ARM image available (which there isn’t, mostly).

Totally agreed and tensorflow is pretty broken (I guess the alpha release tag is fair). But the newest brew released has fixed maybe 90% of the issues. With miniforge + pytorch, you can run most things.

I do a lot of Python on my M1 and now that NumPy compiles correctly, I have no complaints. Docker also works fine presuming your base image has a ARM version (I haven’t tried their x86 emulation, but presumptively it’s slow since it can’t use Apple’s Rosetta speedup).

It was bumpy until March or so, but now I really really like it for Python.

I don't have any Python experience but Docker has been a mixed bag but mostly fine.

ARM-native images are 100% fine, and x86 images are surprisingly usable via emulation (albeit considerably slower). During the technical preview stage some x86 images simply didn't work at all (MySQL being a big one that springs to mind). However, I've just checked it in the stable release and it's working now. Not sure if there's still images that don't work under emulation though.

That's good news. I was having trouble with some MySQL images using the Docker Preview. I have installed the final version but frankly, I never use that machine unless I have to test something in Safari. I just can't stand having to always remember what arch I need to use for a particular tool. (I do have an alias that opens another terminal in "emulate x64 mode" but, that's annoying too"). I think in a few years, when there are more toolchains built out, the ecosystem may be more attractive to me.

Current lineup has too little RAM for many dev-tasks. Like running multiple docker containers, or developing in a ram-hungry language (java+intellij), or running emulators (mobile dev).

If the next MBP16 lineup with M1 (M2?) supports 32+ GBs of RAM other vendors will have to step up their game, though.

> running emulators (mobile dev)

16GiB is insufficient for mobile? iPhone SE has 3GiB and 12 has 6GiB. That is less than half your M1 RAM. How much more does the emulator consume?

At least my coworker's former 16GB MBP (until he got a new one now) basically halted when the emulators were running, and he had to close lots of programs. Not strictly appdev, though, so he was then running and developing our backends locally, running some other needed services in docker, and then working on the android and ios app at the same time to match and test the changes in the backend. So basically all of my examples above, but at the same time.

So not strictly necessary, but when you're used to it going back to having to work around the limitations is burdensome. People not having lots of ram seldom complain, but they don't know how much time they're wasting on an inefficient workflow.

I'm not a mobile developer, but between docker, my IDE, Chrome, and whatever other crap I've got running on my 16 GB MBP, I'm using 14.8 GB of RAM and 20 GB of swap.

I'm using 25 G of ram (out of 32) right now and I only have one IDE open.

When I need to run VMs as well, sky's the limit.

I have a M1 Mini with 16GB memory. The machine's SSD is incredibly fast, so it swaps very well.

Whereas my 2019 MBP will suffer incredibly when I start running out of memory (it literally becomes unusable and requires a hard reboot), the M1 will transparently start swapping, and I generally don't even notice.

Just the other day I noticed a python process was running slower than expected, and it was a bug in my Pandas code so I had allocated 85GB of memory. The rest of the system was operating normally - Chrome, VSCode, Music were all fine.

I regularly kick off a data pipeline process with 8x concurrency, even though each process uses between 4-6GB memory. It's probably inefficient in some way, but overall is still much faster than running at 2x concurrency (where everything would fit in memory and it wouldn't need to swap).

Not python, but I have had hiccups with both Go and Java when targetting x86 linux docker images. The Go stuff would make qemu choke when building multiple go binaries in parallel, and the java testcontainers I use had some sort of an issue.

In general though, I love my M1 air, but I am sticking to my workstation (5950x, 64GB, debian) for dev work for now.

Why wouldn't you just cross-compile Go programs, instead of compiling them from inside an x86 emulator? CGO?

Being able to control the base platform is sometimes important - in this case the target is aws lambda, and even building on Ubuntu 20.10 we ended up with links to incompatible GlibC library versions compared to the lambda runtime environment.

Quick fix for all of this - whatever platform you run the build on, do it in docker on the exact same base image that lambda uses at runtime.

I know, you’re going to tell me there’s an easy way around this with cross-compilation. But when you already have docker available , quite often everything looks like a nail.

I've recently gone through the process of getting our stack, which includes python, go, and docker, running on an M1. Docker for Mac only recently released M1 support but it runs well enough. We upgraded to Python 3.9 to incorporate some M1 compatibility updates as well.

Overall, developing on the M1 Macbook Pro has been great so far.

> However, when it came to buying a new engineer on our team a laptop, we had to go with the last 2020 Intel model.

There is no rush into purchasing an M1 for developers since, the software ecosystem at the time (and still to this day) is somewhat immature and not ready. There is plenty of time to switch to Apple Silicon until the ecosystem is mature.

By then, you would not even consider an M1. It might be an M1X, M2, etc. On top of the already existing issues that plague the first generation, the best thing to do for now is to stay on Intel for now. I am long term Apple Silicon, not long term 'M1'.

This is what I have been saying for weeks [0][1] and weeks [2][3] and now just yesterday. [4] I even said it a day after 'launch day'. [5]

Just wait for WWDC or September.

[0] https://news.ycombinator.com/item?id=26748321

[1] https://news.ycombinator.com/item?id=26159495

[2] https://news.ycombinator.com/item?id=26361883

[3] https://news.ycombinator.com/item?id=26327064

[4] https://news.ycombinator.com/item?id=26879674

[5] https://news.ycombinator.com/item?id=25066189

I know it's not what you asked, but it might help someone else. Rust and JS/TS work well, no complaints so far. Performance is great. The only issue I had an issue where some package depended on Chromium for something and I couldn't get it to work. But it was a relatively minor thing so I let it go.

> Many python packages will take longer to install I imagine (if there are no wheels for the M1 mac, not sure if that's an issue) and I suspect some won't build at all. I also have some concerns over our Docker environment building.

Just use an x86-emulated terminal and you don’t have to worry about this. The only limitation is x86 docker images, which I can’t get to run on my M1. Everything else works as it did on my 2015 MBP (when executed in an x86 terminal).

Have you tried the newest docker? I was on RC2 and managed to run a couple of x86_64 containers minus the issue of networking (for some reason uploads times out)

This x100

Will currently rock my 2017 MBP until it shits the bed. While there have been huge strides in getting tools compatible with apple's ARM, I am not a fan of spending huge amounts of efforts to get a tool(s) to work on something that was already working sufficiently enough on x86.

Plus, I imagine in most corporate environments M1 will break many internal tools making it nearly impossible to access protected resources.

Roughly the same scenario. Was buying new laptops (3) for me and a new team. We looked into M1, but need to do some things like run Parallels/Windows, and underlying software, that we didn't have enough confidence yet would work as needed on the M1. I figure we'll wait a year or so for the M1 ecosystem to get a little better understood and then re-evaluate.

So I'm not using docker or Python so my opinion isn't so worthwhile but I would say you made the right choice for right now.

I have an M1 Air and ended up listing my iMac I use for work as the Air was just wholely faster for my tasks. For the average dev, I think there's a weird hap right now of "M1 now vs M1X/M2". It's getting later in the cycle and while M1 support has greatly gotten better, it's now closer to new models with drastic changes.

Now in my use (TS/Node), the M1 in native Node is unbelievable, it's twice as fast as Intel machines. But that's my use case.

I am in this weirdness . Have they fixed the USB-C PD frying boards issue? That made not buy one so far as an USB-C dock is a must with the Air.

I'm working a lot on M1 and few months ago it was unusable for Deep Learning stuff but now its mediocre not good but also not terrible. (even coreml stuff wasn't working properly on M1 2 months ago)

Reply on news.ycombinator.com