10 ms·
I'm a developer as well and don't use apps like VSCode, or Java/Gradle... but instead develop open source projects running Python, and Rust. 1. For my open sou
by X-Istence 6y ago
I'm a developer as well and don't use apps like VSCode, or Java/Gradle... but instead develop open source projects running Python, and Rust.
1. For my open source projects, running tests has sped up so much that I find it more of a joy to work on this projects now. Test suites that take ~60 seconds on my 2017 MacBook Pro i7, now take just ~15 seconds. That's a HUGE win in the edit, run test suite cycle.
2. My Rust projects now compile in WAY less time. Something that used to take 3 minutes to compile + link for a debug build is now down to 40 seconds. Once again, this has increased my productivity in the edit, compile, test cycle.
For other projects like node/npm the speedups are also massive and running various pipelines to go from source code to final deployable object is also much faster.
I use vim to develop, and it runs on Rosetta just fine, so I can continue to use all my existing plugins. I don't extensively use docker containers, but for those I connect to the cloud instead of running them locally, which is a move I was already making even on my Intel based MacBook Pro.
I got the 16GB 13" MacBook Pro. I, like the blog author, was thinking of this as a secondary laptop, something fun to have around, but I have hardly touched my old 15" MacBook Pro because this one does everything I already need. And does it faster.
I've been living with 16GB of RAM forever, so maybe I am used to fitting in that memory space... I avoid Electron based apps like the plague, and with being able to run iPad/iOS apps on the M1, I've been able to cut down even further since things like Authy are way faster to launch when they aren't large Chrome based hogs.
I am looking forward to the 16" MacBook Pro's with Apple Silicon based processors, but only because I do miss the additional screen real-estate, and prefer the larger size. But the 13" MacBook Pro M1 has been absolutely fantastic so far.
- raverbashing 6y agoGood to know I'm glad Vim is running fine on Rosetta, still, if you wanted to compile it from source, it really shouldn't be too hard. (Rust is a harder problem, so I wouldn't worry too much, still, once the dependencies are downloaded and compiled it's usually fine)
- saagarjha 6y agoNo need to use Rosetta: $ file `which vim` /usr/bin/vim: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e] /usr/bin/vim (for architecture x86_64): Mach-O 64-bit executable x86_64 /usr/bin/vim (for architecture arm64e): Mach-O 64-bit executable arm64e
- lmedinas 6y agovim 8.2 included in MacOS is native, neovim is not yet ported :(
- mlindner 6y agoNeoVIM works fine after adding a compilation target. See: https://github.com/neovim/neovim/pull/12624 https://github.com/neovim/neovim/pull/12624 It hasn't been merged yet as some of the dependencies aren't available, one of them apparently being LuaJIT, but if you build it yourself without that it shouldn't be a problem.
- X-Istence 6y agoI install from Homebrew, specifically MacVim. The system version is usually behind on patch levels/plugins that can be loaded.
- mlindner 6y agoGluing yourself at the hip to homebrew is a bad idea IMO. It's trivial to install things yourself. It's just a matter of `./configure && make && make install` and you're done.
- ibraheemdev 6y agoWhy do a `git clone pkg && cd pkg && ./configure && make && make install` instead of just a `brew install`? The whole point of a package manager is to make installations and upgrades easier.
- arcticbull 6y agoI'm doing my Rust development in a Docker container deployed on AWS w/Fargate and EFS to store my source, via VSCode Remote on my M1 MacBook Pro :) Thin client, arbitrarily fat server. VSCode Remote makes it a very pleasant experience. I'll document my experience once I've smoothed out the kinks. The nice thing is I can just wait out the compatibility issues re: arm migration, especially with some of the third party crates my rust projects depend on currently failing to build.
- aledalgrande 6y agoWhat is the monthly expense to run your dev on Fargate?
- arcticbull 6y agoJust got it set up a few days ago, but happy to report back. I'll also write up a quick medium post or something.
- X-Istence 6y agoBeing able to easily install it using homebrew is really where that need came from. I can use the existing bottles and the recommendation for right now is to not mix and match both Intel/Arm binaries. Also, the ARM version of Homebrew is not yet ready for primetime, there is a ton of software that doesn't compile for ARM yet (Including MacVim).
- spideymans 6y ago>I've been living with 16GB of RAM forever, so maybe I am used to fitting in that memory space... I avoid Electron based apps like the plague, and with being able to run iPad/iOS apps on the M1, I've been able to cut down even further since things like Authy are way faster to launch when they aren't large Chrome based hogs. iOS apps on the Mac are a game changer for me. The UX isn't 100% perfect, but it sure is better than web apps, which are very often slow, resource intensive and kill your battery. I haven't touched the Twitter web app since I've installed the iOS/Catalyst app on my Mac. Even with its iOS-optimized user interface, the better performance of the iOS app makes it so much more enjoyable than the web version. I'm very much looking forward to seeing other iOS apps arrive on the Mac, to replace their web variants. There's really something to be said about how web developers have been killing the performance of their websites with their bloated frameworks or whatever. I know web apps will always be at a performance disadvantage compared to native apps, but the performance regression has gotten absurd. Using Reddit via the Apollo iOS app is a quick and buttery smooth experience, meanwhile the redesigned Reddit webpage is a laggy stuttering mess on my MacBook Pro.
- lstamour 6y agoSimilarly, it’s a joy to use the Jira app for macOS which uses Catalyst to port their iPad app to macOS. Compared to how long it takes to load and use Jira on the web, it’s just a bit snappier and nice. The dark mode support is also appreciated, though aesthetics could still improve to be a bit more mac-native... and because of Jira’s design, it’s possible the app will always lag in functionality compared to the website. But still— progress! :)
- girvo 6y agoI wonder how it compares to the existing Mac native Jira app?
- lstamour 6y agoThe Jira Cloud iPad app does not appear in the App Store. Apps can opt out from the macOS App Store, and this is especially useful if there already is a macOS version. Why? Generally, any macOS version of an app -- even one like Jira which is nearly a straight port of the iOS app -- is 10x better than the iOS version. Running iOS apps on the M1 is a lot rougher around the edges compared to running Intel apps on the M1. I expect Apple will polish up how iOS apps run on macOS in future releases, if they maintain the feature in its current form.
- someperson 6y agoI think a lot of the performance gain is due to switching from an aging 2017 Intel processor to a modern processor on a recent TSMC node (5nm in Apple's case). Had Apple switched to AMD Ryzen processors on TSMC's 7nm node the performance improvement will have been similarly stark.
- read_if_gay_ 6y agoBut not the battery life.
- totalZero 6y agoPower efficiency is indeed one of the benefits of smaller process nodes, so it has a direct impact on battery life.
- nightski 6y agoThat's not entirely true. My Ryzen 4900hs laptop gets great battery life with integrated graphics. Not as good as the m1, but it's a zen 2 chip and we have yet to see what zen 3 mobile will do. Apple clearly has a huge advantage here with a cutting edge process and for all practical purposes unlimited money to throw at this. Their cash on hand is more than AMD s full market cap.
- threeseed 6y agoCan you clarify what you mean by "great" i.e. in hours. From all benchmarks the Apple M1 laptops are around 1.8-2x more battery life than anything from AMD/Intel.
- neogodless 6y agoMy friend sent me a screen shot from `powercfg /batteryreport` on his Asus Zephyrus G14 (Ryzen 9 4900HS) and it had consumed 16,704 Wh of battery in 1:47:27 of active use. That tracks to about 8.5 hours (capacity showed just under 80 Wh).
- in3d 6y agoWhy are you using a laptop for development in the first place unless you have to be on the move? Why not take advantage of even faster CPUs or GPUs, more RAM, many times more screen space, more disk space, ergonomic keyboard and mouse, or even real speakers if you work from home?
- joshmanders 6y agoLiterally everyone who chooses a laptop as their main driver is doing it purely for the portability... We don't choose it because it's small, we choose it because while most of the time we're stationary, the time we do need to be portable, its easier to just undock and walk away than to make sure your laptop and desktop are synced.
- macintux 6y agoI was considering picking up a new Mini so I could drive two displays, but then I remembered another laptop advantage: TouchID. I would really miss that.
- joshmanders 6y agoI drive two 27-inch 4K displays at 3840x2160 on my 2019 16-inch MacBook pro.
- macintux 6y agoDitto, but the M1 laptops officially only can do one display. People have hacked around it but I’d rather wait.
- joshmanders 6y agoAh I didn't know that.
- threeseed 6y agoYou can use DisplayLink to get around it. I wouldn't class it as a hack since it is pretty standard in enterprise environments. Downside is that it does consume CPU which depending on your workload may/may not be noticeable.
- runeks 6y ago> Test suites that take ~60 seconds on my 2017 MacBook Pro i7, now take just ~15 seconds. Interesting! Are you compiling to arm64 or emulating x86?
- X-Istence 6y agoThis is Python 3.6 -> 3.9 compiled to Intel running under Rosetta 2. For Rust I am running the ARM toolchain that was recently released, so no Rosetta involved at all.
- dr_zoidberg 6y agoDo you think moving from python 3.6 to 3.6 had any impact whatsoever? I'm surprised by such a large improvement in performance as other reports I read indicated similar-to-slightly-worse python performance of M1 vs x86.
- X-Istence 6y agoI run test suite across those Python's. So Python 3.6, 3.7, 3.8, and 3.9 using tox to drive the automation to test against all of those versions to validate compatibility and that nothing breaks. So there is no moving anything. Python compiled using pyenv for the Intel platform. Which reports are you reading? Are they using C libraries or doing heavy math computation that is not CPU bound because there's no optimized ARM version yet?
- dr_zoidberg 6y agoOkay, I'm not finding any benchmark that supports the idea of a slowdown, so probably I remembered some rumour I read on twitter or reddit. What I am finding now is that python is working more than fine on M1, be it through rosetta or native code, which is consistent with your experience. Also to clear things a bit, I parsed your "3.6 -> 3.9" as meaning that you had moved from Py36 on intel to Py39 on apple, which is why I asked if maybe there were speedups or differences from moving to 3.9.
- chii 6y ago> Test suites that take ~60 seconds on my 2017 MacBook Pro i7, now take just ~15 seconds. wow, a 5x improvement without you doing anything but changing hardware!? That's an excellent upgrade imho. I wish apple would be able to sell the M1 as a generic processor to which other machines can use.
- kzrdude 6y agoHow is Rust support for the platform?
- steveklabnik 6y agohttps://github.com/rust-lang/rust/issues/73908 https://github.com/rust-lang/rust/issues/73908
- X-Istence 6y agoIt's Tier 2... and I've been using the ARM toolchain that was just released. So far all the crates that were not working have been getting updates to work on the new platform, so far I haven't found any issues!
- throwaway201103 6y ago> Something that used to take 3 minutes to compile + link for a debug build is now down to 40 seconds. 1990s me laughs remembering edit/compile/test cycles measured in hours.
- zeroonetwothree 6y agoWell it still can be hours. Really depends what you work on.
- selestify 6y agoWhat were you compiling back then?
- kossTKR 6y agoWhen do people think the 16" with a M chip will be available? I'm honestly for the first time in a decade a bit excited about an upcoming computer, pretty great. Still running on a 2014 MBP that honestly is still great so can wait a bit.
- pfranz 6y agoNobody actually knows, but I remember Apple saying something like a 2 year transition (which includes new Intel products). So if you're not in a rush that's likely the longest you'll wait.
- thejohnconway 6y agoI don’t think this transition will take two years, the transition to Intel took less time than they said last time. Maybe for the Mac Pro. The MacRumours buyers guide has the MacBook Pro 16” as due an update right now: https://buyersguide.macrumors.com/#MacBook_Pro_16 https://buyersguide.macrumors.com/#MacBook_Pro_16 Honestly, I’d be surprised if we don’t get an M1x (or whatever it’s called) within six months.
- wulfklaue 6y ago> I'm honestly for the first time in a decade a bit excited about an upcoming computer, I think we are more excited about a shake up in the whole computer world, that may mean the dead of ATX/MB's/etc as we know it. And a more profound move to eGPU/NUC/Laptop like powerful devices with a low power usage. This feels a bit like a wakeup call to the industry. Like how the first (commercial) successful smartphone, the iPhone 1 fueled a entire industry for over 10 years to massive evolve. What is kind of funny because i felt like the smartphone evolution was starting to loos steam. The conversion between PC/Laptop/Smarthones will begin now.
- alwillis 6y agoI use vim to develop, and it runs on Rosetta just fine, so I can continue to use all my existing plugins. Don't forget—Vim comes as a Universal binary, so it already runs natively on the M1. /usr/bin/vim: Mach-O universal binary with 2 architectures [x86_64:Mach-O 64-bit executable x86_64] [arm64e] /usr/bin/vim (for architecture x86_64): Mach-O 64-bit executable x86_64 /usr/bin/vim (for architecture arm64e): Mach-O 64-bit executable arm64e