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 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.
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.
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.
> 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:
> 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.
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).
> 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.
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.
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.
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 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.
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.
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.
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.
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.
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 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?
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.
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.
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.
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.
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!
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.