Insider Build of VSCode for Windows/ARM64 | Hacker News Reader

Insider Build of VSCode for Windows/ARM64

github.com

106 pointssoapdog79 comments

The Visual Studio Code version from the Insiders Program is now available as a native arm64 build for Windows 10. Owners of Surface Pro X can finally use a native editor on the platform.

Still this is still an electron-based editor and even in native arm64 it uses a lot of RAM. On my Surface Pro X, I just launched both VSCode compiled for ARM64 and Sublime Text compiled for ia32. VSCode is using about 300MB+ and Sublime Text (working under built-in ia32 emulation) is using 15MB.

I’m happy to have native VSCode, not only because many people rely on that but because it means that Electron, NodeJS, and node-gyp must be working for Windows on ARM in a somewhat stable manner and that will open the doors for other applications to arrive in the platform soon (I hope).

I know that most readers here are not keen on anything Microsoft related, I understand that and in many cases share the sentiment and views but there might be readers that got an SPX and were waiting for this release like I was. If you were running the insider preview compiled for ia32, it won’t automatically change to arm64, you’ll need to download again.

I feel like a dinosaur because a "native" app to me means pretty much the exact opposite of an electron app.

I totally agree with you there, buuut, before this release VSCode on a Surface Pro X would be Electron running as a ia32 emulated app, which is not only web technologies but also the wrong ISA.

I'd love to have sublime text, textadept, or any other real native editor running under ARM64 on Windows but so far they are not available. This VSCode is the first editor shipping ARM64 binaries, even if Electron stuff.

Also it is important to notice that many developers using that machine are using the ia32 version of VSCode and this version will benefit them (and it more native to the platform).

Is it not possible to compile editors like emacs or Sublime Text for ARM64? I know very little about native programming but surely GCC/Clang/Visual C++ have ARM64 compilation targets?

It is a chicken and egg problem. Many languages do not yet support Windows on ARM, so you can't rely on them to build stuff for the new platform. For example there is no official release of NodeJS, Python, Ruby, Perl, on the platform.

Lots of FOSS rely on gnu stuff which is usually compiled on windows using mingw/msys2/cygwin, all of which are not available for Windows on ARM. So you can't easily port stuff.

You can run Visual Studio and cross-compile from ia32 to arm64 on a Surface Pro X but that is unsupported by Microsoft who wants you to have two machines, one running x64 and compiling stuff and another running arm64 and testing stuff. That is unreasonable for small independent developers.

So until the development ecosystem is a bit better, porting stuff will still have a lot of friction and that is why for now, IMHO, every port needs to be cherished.

It certainly is! Not sure what the situation is on Windows but Linux distros that have ARM versions typically have nearly all the same software that you’d expect on x86 in their repos. (I’m thinking of Debian in particular here, but I suspect others are similar.)

True, but remember when many apps were not made for Linux, because it was not worth it? With Electron at least we have apps like VSCode for Linux too. Not ideal, but better than nothing.

Blender, Photoshop, Premiere, Maya, ZBrush, CATIA, AutoCAD, and hundreds of other specialized tools are not moving to Electron anytime soon...

My point is that we shouldn’t embrace for Electron just because we want applications in Linux.

In addition, Election is not a guarantee of a Linux port either.

Eventually we're going to just have a means of saying: Save this webpage as an app.

I mean, we do already. It's called PWAs, and I have many of my favorite sites saved as an app. But it's featureless and lame.

Point being, Electron is just a stopgap while PWAs are figured out. And with the advent of WASM, we'll be able to run some pretty heavy stuff.

https://wasm.continuation-labs.com/d3demo/

My long term strategy: Learn rust for WASM, keep an eye on PWAs

Wasm is still very early and lacks a lot of features. It is also not as fast as a native application.

The browsers also lack many APIs to compete with native applications, and those are not coming soon either.

Web apps are just fine, even nowadays, for many things. But for heavy lifting, no, they are still way, way behind.

(By the way, you can compile to Wasm with almost any popular language, not just Rust).

AutoCAD has a web version. I wouldn't be surprised to see an Electron version sometime. (One wonders how feature complete it would be though.)

In any case, I personally embrace Electron due to its development value. I can use the same codebase on all platforms, using technologies that my colleagues and I are already very familiar with (TypeScript/React/etc), with a supporting cast of a mind-shatteringly large ecosystem of FOSS packages. The speed at which I can turn out features in Electron just vastly outpaces anything else we've worked with. And that seems to be worth more to users than the 200MB footprint.

> AutoCAD has a web version

A shitty version, you mean. Same as Office 365 vs. the native Office.

The web versions of most native apps are very, very bad at the moment.

> I can use the same codebase on all platforms, using technologies that my colleagues and I are already very familiar with (TypeScript/React/etc), with a supporting cast of a mind-shatteringly large ecosystem of FOSS packages.

Everything you wrote here applies to most languages, including .NET, Java, C++, Rust and others.

The fact that you and your colleagues know other technologies does not mean they are the right approach.

> The speed at which I can turn out features in Electron

I think that is exactly what users don’t want. Users want stability and quality, not feature churn.

> A shitty version, you mean.

Indeed, hence the parenthetical.

> Everything you wrote here applies to most languages, including .NET, Java, C++, Rust and others.

Superb! Direct me to a rich Rust GUI application which targets the web, Linux, and iOS. Speaking to team tech familiarity, our front-end web engineers will be thrilled to get cracking with Rust. That'll be a sight!

> I think that is exactly what users don’t want. Users want stability and quality, not feature churn.

I'm glad you know what users want. I generally prefer them to tell us, and incidentally, "feature churn" never comes up in such discussions. What user stories do come up can be completed remarkably quickly in our Electron stack with stability and quality too.

> True, but remember when many apps were not made for Linux, because it was not worth it? With Electron at least we have apps like VSCode for Linux too. Not ideal, but better than nothing.

and yet on Linux you had already the entirety of debian already available in native ARM64 years ago, which is a lot more than what you have on windows ARM64.

But then unfortunately, even then some companies do not provide their Electron app on Linux e.g. Notion.

Though, it is usually easy to rewrap the version from another platform using Electron on Linux. E.g. writing a Nix derivation for Notion on Linux isn't much more work than for any other Electron application:

https://github.com/danieldk/nix-packages/blob/master/pkgs/no...

(Not tested more recently though, I don't use Notion a lot.)

> But then unfortunately, even then some companies do not provide their Electron app on Linux e.g. Notion.

Add Figma to the mix. Since I moved to Linux exclusively, I've abandoned plugin authoring. Granted, there is a Linux-Figma[0] app, but every time I try it, it doesn't take long before something essential (e.g. fonts) breaks.

[0]: https://github.com/Figma-Linux/figma-linux

I feel like even more of a dinosaur then because "native" to me means compiled for the target processor architecture vs being emulated (which is exactly what this is about).

Electron is running natively. What is running in electron is not.

> VSCode is using about 300MB+ and Sublime Text (working under built-in ia32 emulation) is using 15MB.

On my mac VSCode sits at ~380MB without any files open, but opening one empty plaintext file brings that up to 460MB, opening one tiny Lua (a language known for being especially small and efficient) file makes that 500MB, and opening a second tiny Lua file makes that 535MB. Does Sublime increase like that?

There are advantages to having VSCode in Electron. I run VSCode as a web application on my server that I access remotely using a browser on a number of different machines. That instance has access to the file system on my server, allowing me to use any machine to do my work without installing anything. Try doing that with Sublime.

Microsoft is leveraging this by allowing you to open up VSCode in Github for any file, no installation necessary. Amazon is doing the same with Cloud9 on AWS that they acquired earlier.

You don't actually need to install VSCode on the server - the SSH extension lets you use VSCode locally.

https://code.visualstudio.com/docs/remote/ssh

That's useful, but I think the person you were replying to doesn't just use the host machine as a remote file system but also as a build host and to have a single workspace with all its settings available from any machine.

I recently set this up as well using code-server [1], which works brilliantly. I have a VM running on a powerful hypervisor host, which has all the source code, the workspace configuration with all my customisations, build tasks, etc. Compilation is fully on the host side, which is a 12-core with 32GB memory, way beyond any of the computers I use as clients, and all I need to access it is an SSH connection to it. Code-server has a progressive web app mode that makes it pretty much indistinguishable from running a local installation. First time I have had to acknowledge it wasn't such a bad idea to implement VSCode as an Electron app to be honest.

[1] https://github.com/cdr/code-server

The ssh extension actually does all of that as well, but it does mean the frontend runs in the Electron app vs in a browser. The first thing the ssh extension does is install the VS Code server backend in the remote host, enabling the remote host to run extensions, the terminal, and so on.

That instance has access to the file system on my server, allowing me to use any machine to do my work without installing anything.

Many editors have had remote editing support for a while. It requires that you have installed the editor locally, but why wouldn't I have an editor on my laptop or desktop?

(Tramp + LSP all the way ;).)

Though being able to open VS Code in GitHub is a really nice feature!

> why wouldn't I have an editor on my laptop or desktop

Because it's not just the editor. It's the toolchain. I get remote terminal inside the editor. All my tooling lives on the server and can be specific to the project I'm working on, instead of gumming up my local machine.

If you use e.g. the Emacs LSP package and edit files remotely through Tramp, you are using the remote toolchain, language server, etc. [1]

(Though for me it doesn't really matter, because I can reproduce exactly the same environments between server and local with Nix.)

[1] https://emacs-lsp.github.io/lsp-mode/page/remote/

Have you heard about Emacs? It has all the features and more. Plus had them for long long time. 44 years on.

Indeed I have. I just don't want to party like it's 1976.

Yet, you are probably deploying on an operating system that is a clone of another operating system that was started in the early 70ies.

Just because I sometimes go through a tunnel doesn't mean I want to live in a cave.

Your setup sounds really intersting, do you have any links for tutorials on how to setup something similar?

Not sure if the parent poster has a custom setup, but there's now tooling to set this up yourself and use Microsoft as a secure proxy so you can access your host from anywhere in the world: https://docs.microsoft.com/en-us/visualstudio/online/referen...

You can also "cheat" and instead of registering your VS Code server instance with Microsoft and find the path in your ~/.vscode-server or whatever directory, and there should be a shell script that starts it and runs VS Code on port 8000. You can then set up any reverse proxy/TLS/auth layer in front of that and access it similarly.

I think the VS Online (now called VS Codespaces) experience is a bit better but the process of creating an account and logging in is messier.

I just used https://github.com/cdr/code-server

It doesn't grow like that in my experience.

I just loaded the source for Luarocks on Sublime Text and my RAM usage while browsing some Lua code in it is 31MB, pretty decent.

If you're doing Lua, there is always Zero Brane Studio (https://studio.zerobrane.com/) which is built with Lua and very nimble (uses wxLua which is wxWidgets + Lua), unfortunately it is not playing well with my hidpi screen. Another good option for Lua developers is TextAdept (https://foicica.com/textadept/) which has wonderful support for extending it using Lua, IMO it is like an Emacs but with Lua. Those editors are available as ia32. I didn't succeeded in compiling ZeroBrane studio for arm64 even though I managed to compile both Lua and wxWidgets for it. As for TextAdept it uses GTK and that is not available for Windows on ARM.

For the past week I've been using sublime text and am quite happy with it. I also use VSCode when I need some more intelisense help.

Ram usage will increase in Sublime Text as syntaxes are loaded into memory. The last time I checked on a Mac, loading every single default syntax would get you in the low 200MB range.

A large part of that with the current stable builds is syntaxes that embed others - so Markdown fenced code blocks and LaTeX files. For simpler syntaxes you’ll see a much smaller jump in ram usage.

No. Once I reached 750 MB but that was because I was working on a JS project with a `node_modules` of 110 MB and by default ST indexes the text contents of all files so I can do find all across files. After that folder was excluded, it took 250 MB and it was indexing 20 MB.

Good thing Raspberry Pi now comes in 8GB models! https://www.engadget.com/raspberry-pi-4-now-available-with-u...

I kind of want to compare this to some older laptops I've been given before.

Can you install Windows on Raspberry Pi?

In addition to what the others have said, we've had good experience with Windows 10 IoT on Raspberry Pi 3B (a few dozen units deployed in daily use) for some sensor data capture applications.

However, based on our experiences with the Pi 3B+ and Microsoft's promise to get an update out "real soon now" (probably over year late at this point), we've concluded that Microsoft is not serious about Windows on the Pi. So we decided to not do any more development on the RPi Win10 IoT platform, and move future development to .NET Core running on Linux which they seem far more enthusiastic about supporting.

Yes for full Windows 10 see https://github.com/WOA-Project/WOA-Deployer-Rpi although targetted for RPi3 some success with 4 has been had but currently RAM is limited to 1Gb slightly less exciting.

Yes.

https://www.microsoft.com/en-us/download/details.aspx?id=550...

This is not "full" Windows 10, not even close. He means an full installation like what this can provide:

https://github.com/WOA-Project/WOA-Deployer-Rpi

It does not work on Rpi 4 and it is not full Windows environment.

I can't seem to find the link, any help? The Insider win64 downloads are x64 only still at https://code.visualstudio.com/insiders/

That issue link contains the links for download for many different versions. If you go to https://update.code.visualstudio.com/latest/win32-arm64-user... you'll get a direct download of it as well.

That reader is me, thanks.

Awesome, now we just need VSCode running natively on an iPad with Docker support! Pipe dreams?

Unless they adapt it to run on iOS’s WebKit APIs then it’s unlikely you’ll see VSCode on an iPad. You’ll probably never see Electron apps on iOS because they violate the submission guidelines.

They could bring the pure editor with no extensions to iOS without violating the guidelines. Not entirely useful I suppose...

They cannot. Apple forbids iOS apps that does JIT. V8 cannot run on iOS.

The editor is a webapp that can run in any browser. It's what powers the new github codespace feature as well as most code editors in the azure portal.

Well they could...

The frontend can run in webkit as demonstrated by the various online versions of VSCode. There is a functional project to run nodejs on ios via V8 with jit disabled. That's probably a significant performance hit, but then a device like the iPad Pro really has resources to spare.

Visual Studio Codespaces (based on VSCode) runs on the iPad: https://twitter.com/notdetails/status/1258070699165585410

edit: this tweeter is a GitHub employee, can't remember what their title is.

I have absolutely no hope for docker support on OSX, let alone iPadOS

I am hoping that WSL/WSL2 makes Windows so attractive for developers, that Apple feels the pressure to either implement Linux syscall emulation or very lightweight VMs like WSL2.

(I know that macOS has Hypervisor.framework)

I don't think it's economically feasible for them to do so. Microsoft invested in WSL because they are trying to lure developers into Azure's cloud ecosystem and Docker + Kubernetes is a big part of it. Apple has no incentive to do, Macbook sales hardly matter to them as evident from their behaviour.

I'm confused about this - I don't use OSX for anything other than Logic, but there's a Docker desktop app for OSX [0] so I assumed it could run docker containers? Is that not true?

[0]: https://hub.docker.com/editions/community/docker-ce-desktop-...

I think the poster may mean performance, or other aspects are problematic. You can definitely use the Docker desktop app for macOS to run docker containers.

It's running inside a Linux Virtual Machine, so the performance is piss poor. My i7 Macbook pro runs hot 24*7 because of such high usage.

Docker works great on macOS. It builds images, runs containers, and you don't even need the Official Desktop App - brew install docker.

It's not a real container, it's a Linux virtual machine.

I don't see an alternative though.

If your deployment target is Linux and your development machine is not then you need a Linux VM of some sort to host your Linux containers.

How would you implement "real" containers without a VM in that scenario.

Support cgroups and namespaces in your kernel and let CRI-O do the rest?

I'm a bit out of my element so I apologize if I'm missing something.

Microsoft implemented cgroups and namespace analogues in Windows Server 2016 to allow it to run "real" Docker containers without the need for virtual machines. The limitation is that the real Windows containers can only run Windows based applications because the underlying architecture is still Windows. Something similar would happen with macOS. The underlying architecture of macOS would remain macOS regardless of whether it could run real containers or not.

No you got it right. I'm actually asking for things like nginx:osx when developing in local.

Got it. Thanks.

It's a Linux virtual machine running real containers though.

So? That's not real support. This is akin to saying MS Office is supported on Linux because you can run it inside a VM.

Someone on Reddit claims they successfully ported VSCode to iPad

https://www.reddit.com/r/webdev/comments/g7rhtw/i_ported_vsc...

When Apple stops suppressing third-party browser runtimes.

Meanwhile, Google still hasn't released an arm64 Windows 10 build of Chrome.

I don't know if you know but Firefox has native builds for Windows on ARM. You might want to give it a try. It is one of the reasons I was OK with buying the Surface Pro X, I was sure I'd have a good native browser.

I forget to use Firefox. I just installed the Edge Chromium browser to see how fast it feels.

Edge Chromium and Firefox (both ARM native) is better in both speed and RAM usage, you can grab normal chrome extensions in edge Chromium too so there's literally no loss.

Try Edge, I'm sure there will be a build if there isn't one already.

Looks cool. This combined with the release of the new RasPi will be a great era for lightweight computing on small devices.

While I don't think this is what you intended with your comment, it got me thinking that Windows on a Raspberry Pi would be a very interesting proposition!

Good news!

https://www.tomshardware.com/reviews/install-windows-10-on-r...

There's also the more official "Windows 10 IoT Core" option which has images specifically for Raspberry Pi.