Ask HN: Is an ARM-based laptop a viable development machine for a Backend dev?

I think for the next year to two years, backend development on ARM Mac will come with some additional pain. There will always be some package with a C extension that doesn&#x27;t compile on your platform (for example).<p>As a non-Mac user (and someone who develops for ARM targets of all sizes) I&#x27;m really happy about the situation though. Apple is forcing developers to not be able to assume processor architecture any more, just because what they&#x27;re developing is aimed at desktop. Lots of software is going to become more portable and we&#x27;ll all benefit. In the meantime though, I&#x27;m going to keep developing on x86&#x2F;64.

I&#x27;ve used a ARM chromebook reinstalled with Linux for dev work. I&#x27;ve ran into problems, especially where you depend on a third-party library that&#x27;s difficult to build from source or isn&#x27;t very portable, like JavaFX, some popular Python scientific libraries that are optimized with C code, some GUI packages on Julia behaved weird. I&#x27;m happy that Apple is moving to ARM, because it will invigorate the consumer ARM space.

I personally would recommend to go with the T440 series, as it&#x27;s the last generation of Thinkpads where you can replace all hardware parts yourself. But it&#x27;s core i-based, so it needs some work regarding Intel ME etc.<p>The Linux support is amazing, the only thing with Thinkpads is the synaptics driver which needs a config file to make it work as you want it to.<p>The thinkwiki contains a lot of information about all models, including a list of known problems. [1]<p>Before you install Linux on any laptop, I would recommend to check for BIOS compatibility. Sometimes there were OEM versions out there where the EFI vars could be deleted and then it&#x27;s bricked unless you flash coreboot or reflash the original BIOS on it with an adapter.<p>If you want to go full tinfoil and libre, why not switch to a pinebook?<p>[1] <a href="https:&#x2F;&#x2F;www.thinkwiki.org&#x2F;wiki&#x2F;Category:Models" rel="nofollow">https:&#x2F;&#x2F;www.thinkwiki.org&#x2F;wiki&#x2F;Category:Models</a>

Very little will change for most developers.<p>I suspect you&#x27;re deploying on Linux, right? You&#x27;re already building and deploying on different operating systems, how much can a different architecture complicate things? Well...<p>What if you&#x27;re using interpreted or VM languages (Python, Java, PHP)? Unless you have native dependencies, very little changes.<p>If you build native code (C&#x2F;C++, Go, Rust), then you might need to cross-compile. That might range from super-easy if you&#x27;re 100% Rust or Go, to challenging if you have C&#x2F;C++ dependencies.<p>But you use CI, right? In that case, the problem almost disappears. Test locally (ARM) without cross-compiling, build and deploy on CI (x86) without cross-compiling.<p>Who builds deployment artefacts locally these days? Hopefully very few. :-)<p>There are some macOS-on-M1-specific issues you might face if you&#x27;re using Docker (native ARM or virtualised x86) containers, but those will clear up soon enough.<p>I&#x27;d take the improved CPU and memory performance of the M1, but I don&#x27;t need a laptop refresh, and the Mac Mini can&#x27;t drive two DisplayPort displays yet.

My recollection of the PowerPC Mac era is that compiling anything open-source was fraught with challenges. My system would typically end up with acres of cruft and one-off hacks just to get things to build.<p>Life&#x27;s different in 2020: there&#x27;s Docker and, if you can tolerate the attitude, Homebrew. It should be easier this time around. But I&#x27;d be wary of moving to ARM quite yet for anything that requires manual compilation. I&#x27;m certainly not going to make the leap until I&#x27;ve seen that other people have successfully built some of the more esoteric parts of the toolchain I use.

What kind of backend dev work?<p>I do backend with Python, Julia and PHP.<p>They all have ARM builds and I’m not expecting issues. I’ve worked with them on ARM and have a few pi’s around running with projects on them.<p>But it depends on the type of backend work. If you’re using C and assembly and need to target x86, then I can see issues.<p>Regarding the move, I expect these first ones to be targeted more to regular users and to projects testing their projects on them.<p>IMO the main reason why things aren’t working on them right now is due to there not being availability and projects not having to move to it yet. But there’s no technical reason why things won’t be ported for them. The ecosystem just needs to grow.

If you do decide to go with Linux:<p>- Dell XPS (mac-like comes with Linux)<p>- Lenovo Thinkpad (excellent Linux support, as it is used by a lot of Linux devs)<p>- Any of the Linux CTO laptop builders (Librem, Tuxedo, ...) will have excellent support, but will not look as good as the Dell<p>- Anything else: YMMV, check the reviews.

The RAM limit is a bit concerning in the long term. Apart from that, there are some pains right now with some tools (Docker doesn&#x27;t work yet) that will be resolved soon. It still runs macOS software for x86 too, so that&#x27;ll help with the transition. When available, I&#x27;ll get a maxed out 32 or 64GB one myself.<p>On the Linux side, my advice is to avoid the &quot;fancy&quot; ones that don&#x27;t explicitly support Linux. Avoid dGPUs if you can and stick to Intel graphics. Beware some machines are coming out with soldered RAM, mostly in the ultrathin category.

&gt; If the answer is no: good 13&quot; Linux-able laptop suggestions?<p><a href="https:&#x2F;&#x2F;puri.sm&#x2F;products&#x2F;librem-14&#x2F;" rel="nofollow">https:&#x2F;&#x2F;puri.sm&#x2F;products&#x2F;librem-14&#x2F;</a>

I think you mean ARM, not AMD. There&#x27;s absolutely no problem with using an AMD device for backend work.

This is just a personal preference, but I like to do all of my development work remotely.<p>I use visual studio code and just have ssh connections set up. When I open a project, the terminal auto connects to my dev server.<p>I can open and edit any file, push to git, deploy, and not need anything on my local machine.<p>It keeps the need for resource usage low, and all of your code is in one place so you can switch machines easily.<p>Throw a sim card in the laptop and you can literally just open it up and program from anywhere without a hassle.

It depends a lot on the tools you use and what your target system is. Docker and all (edit: some!) of the GNU tools won&#x27;t work for a while on the Macbook.<p>What I would suggest, if your target is Linux and your tooling allows, is to develop directly on the cloud. It is completely seamless with Visual Studio Code. You can run edit your files, build your code, run it and debug it on a cloud VM just like you would do it locally. It also means that it doesn&#x27;t really matter how fast (and expensive) your Notebook is, since all the real work takes place in the cloud. Not sure how well other development environments support it though.<p>Another issue you may run into is that none of the ARM Macbooks support two external screens. You can only use a single screen, plus the built-in screen. I don&#x27;t mind, since I prefer to use a single widescreen, but I know a lot of people who work with 2 monitor setups.

Pardon my ignorance, but wasn&#x27;t Docker supposed to fix this? (disparity of environments). I have read the other recently post as well about &quot;Docker doesn&#x27;t work on the new ARM based Macs&quot;, but I don&#x27;t understand why. I mean, Docker has this in their website (<a href="https:&#x2F;&#x2F;www.docker.com&#x2F;use-cases" rel="nofollow">https:&#x2F;&#x2F;www.docker.com&#x2F;use-cases</a>):<p>&gt; It works on my machine! As a developer you know that one of the trickiest problems in software development is having to deal with environment disparity across different machines and platforms. Docker allows you to run containers locally, eliminating disparity between your development and production environments, and everything in between. [...] (Docker) is the ultimate answer to your portability concerns as containers can easily move across machines.<p>Is that not true?

Anything webdev related should have good support because so many web developers are using macs.

I needed 2 days to support aarch64 for SIMD heavy and assembler optimized code for smhasher, a collection of all useful hash functions. Extremely low level stuff. Even without using any SIMD abstractions library. I don&#x27;t expect any problems for all my higher level work. aarch64 is much nicer than power, s390, mips or sparc (oh the horror)<p>It&#x27;s extremely nice to offload heavy computations to all your phones in parallel btw. They are faster than my Macbook Air. I have now a little phone cloud via GNU parallel and ssh. Comes more handy than the heavy x86 machines.

Why not fire up an ARM vm instance of linux on your machine using qemu and see if the packages you want are viable? Make sure to enable acceleration and nested virtualization if you want to test containers.

What&#x27;s the likelihood that running a non MacOS in emulation would still be a reasonable dev environment compared to native on some other hardware?

Well, the only honest answer would be &quot;we don&#x27;t know yet&quot;. Stick to your current hardware and keep watching what&#x27;s going on.

Yes.

&gt; I&#x27;m concerned that Apple&#x27;s move to ARM with the next generation will make them non-viable as a daily driver for dev work.<p>Nothing will change, you’ll have still possibility to work as a developer, with each year even more and more. Adding to that Apple will not ditch intel any time soon, at least until they can satisfied needs for most customers pro and not.<p>People are always afraid of changes on big scale, but they are good to move industry forward. Embrace it and don’t panic too soon. :)<p>EDIT: Yes, of course downvotes. To anyone doing this, you can still use your favorite C64 but don’t slow down the rest of the world.