Hacker News new | ask | show | jobs
by albertzeyer 2243 days ago
While we talk about JetBrains, I think they really should push some priority on their remote development support. Take the VS Code Remote SSH extension as a good example of how it could work, which is extremely seamlessly, and it just works. E.g. even the embedded terminal provides a shell on the remote host, and if you e.g. open a file in there via `code somefile.txt`, it will open in your VS Code.

It's basically this feature request: https://youtrack.jetbrains.com/issue/IDEA-226455

Maybe they just need a few more votes on it. Or some more popularity.

Or is it just me and most people don't really need this? I'm still not really sure about the optimal remote work setup. Other people might just use Mosh + Tmux + Vim... I heard that Google has some very nice internal web IDE. If there would be a web IDE as powerful as PyCharm and the other JetBrain IDEs, that would also be a nice option.

6 comments

FWIW: In the 2020.1 updates that have been rolled out in the last week the SSH support is now much better.

But serious question though: what workflow do you have that remote code editing is necessary?

I find remote code editing to be useful when I don't have the necessary resources on my machine such as disk/memory/gpu and I am still prototyping a solution, which happens a lot in ML/DL.

I agree that remote code editing is not strictly necessary since you can perform such task with sshfs or git push/pull workflows.

On the other hand, having the remote environment in your local IDE quickens the development and you don't have to setup a full replica of your environment locally.

edit: ML/DL here stands for Machine Learning/Deep Learning

I also tried SSHFS, but there are hiccups. I did not really debug this. But sometimes PyCharm just freezes for 5-10 seconds. Which is extremely annoying, basically this makes it unusable. Maybe too much files are opened at the same time or so. Maybe I have to increase the cache size. I don't really know...

Also doing any Git action (git commit or so) over SSHFS is way too slow because it needs to go through the whole project directory. Maybe it's fine if the repo and project is smaller. But in this case, a Git commit can easily take a minute (while locally it takes a few milliseconds).

A Git push/pull workflow would also be quite annoying when you are prototyping and just want to try out things.

I get that through remote interpreter and automatic upload features.
I sometimes code on my Surface Go (with a Pentium Silver CPU) and remote in to my home desktop (with a ryzen 3900x). For one of my Rust projects, the Surface Go takes about 25 minutes for a clean build and 2-3 minutes for incremental build. The desktop does a clean build in 2 minutes and an incremental build in 10-20s.

Since it needs to do an incremental build to provide any of the intelligent tools for Rust, it means editing directly on the Surface Go degrades to a text editor experience, while doing the remote editing lets the IDE-like features work.

Not the parent, but I do all my development with VS Code's remote editing. I generally don't run anything on my main desktop. Instead, I have a local VM server that runs a dedicated VM for each of my projects. Dedicated VMs are great because I never run into a situation where project A relies on node.js version X and starts clashing with project B that relies on node.js version Y. And I just manage everything with Ansible so it's easy to blow away a VM and rebuild it if I ever need to.

I wrote a bit more about my setup here: https://mtlynch.io/building-a-vm-homelab/

I do research on speech recognition and machine learning, i.e. I run lots of TF code, on lots of big data, and it runs for a long time (days, weeks). All the data, user files, everything in our lab is accessible via NFS, and every node in the cluster has the same FS. From the outside, I only have SSH access.

I want to work on code which runs there in the cluster.

I could have a local Git checkout of the code (partly). But sometimes it's a lot of trial and error, and it would be quite annoying to keep extra care that my local Git checkout gets synchronized with the copy in the cluster. Sometimes it might also have other files as dependencies which are simply only there in the cluster - or it would be extremely complicated to replicated all the same locally, and keep it all in sync. Even if PyCharm could help on the syncing part, it would still not be perfect, and would be annoying.

VS Code Remote SSH is basically perfect and exactly like I want it. The only problem is that I still prefer PyCharm.

For me the big one was using linux VM's on a windows host. If I want to work with Linux command line tools by far the easiest way is to have VS Code ssh'd into my VM and a few terminals open. I get the comfort of my normal daily driver and access to whatever command line tools are best suited to my current project.
Would you mind elaborating on what the improvements are? I've just been through this a couple of days ago and found it quite messy.
Many companies build/execute code on cloud desktops.
I develop on multiple machines and have just been through this exact thing with both VS Code and Pycharm. I was surprised at how different the implementations are. The VS Code SSH extensions work great - I would almost say "seamlessly", actually - whereas the Pycharm approach feels like a real kludge.

For starters, there seems to be more than one way to do it - one of the responses below refers to remote-mounting the filesystem using SSHFS, but another way to do it is through the Tools -> Deployment menu. The SSHFS approach is presumably the better one if your particular problem is trying to write code across several machines; the Tools -> Deployment avenue seems much better suited an actual deployment (it is, after all, in the name).

It's got me wondering whether I could get away with doing all my Python development in VS Code but obviously everyone has different constraints.

Using remote dev boxes can definitely be a huge productivity boon, from having better specs to much faster networks.

Here's an example of how Databricks improved their dev cycle with beefy machines running Bazel + remote cache: https://databricks.com/blog/2019/02/27/speedy-scala-builds-w...

With sshfs, what is the point? It seems to me that an editor shouldn't be dealing with the particularities of on what machine a file resides, that should be handled by the kernel or a userspace module. Like if Intellij had a feature that could allow it to access NFS drives people would decry it as unnecessary, but for some reason ssh is different.
Your point stands for an editor. Do note that PyCharm tries to be more than that, providing a bunch of tools around the editor.

In Pycharm, you don't just open remote files via SSH, the files are actually stored on the local machine. The point is to run the interpreter and the debugger on the remote machine.

This allows an integrated workflow with access to things you might not have on the local dev machine.

If your workflow is editing files in Vim / Sublime Code / whatever and then running them from the command line, I guess there really isn't that much benefit to this.

Examples:

- Access to some firewalled-off machine - Load big amounts of data from another machine while your dev machine is on a low bandwidth connection - Access hardware you might not have locally, such as a big GPU while coding on a light laptop

The remote machine might have packages installed that are required to run, debug and code-completion.
Agreed, SSH-based remote development could certainly be smoother. But I love the way PyCharm uses pydev to run a Remote Debugging Server - that works for most remote-development use cases I encounter. Once you get it set up and a run configuration working, it’s a joy.
i'm using remote dev right this second in pycharm. other than the terminal thing (which is solved by just having ssh open) i don't have any issues.
You can use Tools -> Start SSH Session and select the session used for the interpreter. I think it would be event better if the Terminal tab opened it directly, but this is good enough for me.