Comment by cedricgle | Hacker News Reader

Comment by cedricgle | Hacker News Reader

My take with VS Code is that their support of development container and ssh is the best and it's a killer feature.

My ultimate goal for quite sometime now was to pack all my development dependencies inside containers or cloud-init files to keep my host bare-bone and have reproducible/shareable setups anywhere anytime. Before I was an Emacs fan. I tried multiple combination of Emacs, Tramp and containers but it failed: there always was a package that didn't played well and kept looking for stuff at the wrong location. After a while, I was fed up to make low-level fixes in random packages. I also tried weird setup with Nix for the same exact bad result.

So I took my nerd pride away and tried VS Code with containers and ssh: - https://code.visualstudio.com/docs/remote/containers - https://code.visualstudio.com/docs/remote/ssh

It just worked. The experience was flawless. In a matter of second, it blew the competition away like nothing. Nowadays, I cannot live happier: I clone the repo i need to work. It comes with a development Dockerfile. VS Code starts the container and everything is there for working. If I need a beefier host, I spin up a cloud VM with cloud-init and 5 minute later the setup is ready without any manual intervention. Any extension I tried in marketplace worked.

In my opinion, the Emacs/Vim communities clearly missed a golden opportunity for a more larger adoption.

I desperately wanted VS Code's remote development functionality in IDEA, and was keeping track of their remote development feature in YouTrack. When CodeWithMe was released, I was sorely disappointed.

All I wanted was my code to run anywhere, and my local machine to be the IDE.

mutagen.io ended up being my answer. After learning how it worked, I got it set up and it works really well. I'm mostly doing PHP development these days, and have a LAMP stack running as docker containers on a server.

The sync is nearly instant (99% of the time), the rare conflicts are easily resolved, and of course debugging still works.

The only thing I'm missing is collaborative editing, which I still have to jump over to VS Code to do. I haven't tried out two people using `mutagen sync` on the same instance of code, but that could be a really interesting solution if it works.

An editor agnostic solution to collaborative/pair coding would be really fantastic.

I've spoken to some Jetbrains employees and it seems their vision of remote development is nothing like what VSCode does. No matter how much I explain they just don't seem to understand the advantages of being able to host the IDE in a docker container/remote system. "Docker isn't supposed to be used for that, you deploy to a container, not develop inside one" they say.

Jetbrains Projector seems to be their solution. It runs the IDE on the server, and renders the GUI in a browser. Seems experimental so far, I'm running it at home and it's surprisingly far along but still ... Kludgey? A great POC.

Agreed, mutagen is great for remote development.

As for the conflicts, I chose the option of one way sync, with everything being overwritten by what's on my local machine if there's a conflict. Works like a charm, since the remote machine will only ever produce build artifacts and run them, which I don't need to sync back to my machine.

I agree 100% that being able to work on a project that actually lives on a remote server, or on Windows subsystem for Linux, or in a container, is a killer feature. It's really awesome. It still wasn't enough to tear me away from GoLand though. I hope JetBrains implements something similar, I think they may have done so already in a limited way for certain languages, but it's not on VS Code's level if I recall correctly.

In my opinion, the Emacs/Vim communities clearly missed a golden opportunity for a more larger adoption.

They just copy their init.el/vimrc to the server, Emacs/Vim users have been able to do this (coding on remote environments without all the kludges) since forever ;) and personally, I find it superior to vscoce's remote plugin since your editor and tools sit on the same machine.

For GUI editors, I agree that vscode's remote development extension is a killer feature and nothing can't match it today.

> They just copy their init.el/vimrc to the server, Emacs/Vim users have been able to do this (coding on remote environments without all the kludges) since forever ;) and personally, I find it superior to vscoce's remote plugin since your editor and tools sit on the same machine.

Unfortunately this doesn't work well if your connection has a high latency though, which I think is what VScode does really well.

did you ever try this? or is this just something which you think should be it's distinguishing feature?

Asking mainly because I think this is cool, but the whole setup (lots of random binaries in the server) is not so different to an AppImage of emacs+xpra (if you could do tha) and the times I tried, the thing was _very_ picky about connection losses/timeouts...

Sorry for the late reply,

Yes, I did try this and although I don't particularly need remote editing, the fact that it took me less than 2 minutes to setup a remote editor with auto-complete and other IDE features was pretty amazing.

Fully agree. Also, if you need to debug your code that runs in kubernetes pods, VS Code also smokes other IDEs. In my case, not only the API calls are forwarded from the cluster to my debugging session but I can also consume during debugging some Kubernetes services by using their DNS names. Just awesome.

I'm the same - editing remote code is required - full stop. Of course, VS goes further.. But all I really needed was remote projects with intellisense. Remote debugging, git, and everything else are just bonus.

I run my editor on my desktop, and expect to be able to work on whatever remote server I need to.

Do note that the remote containers extension is not open source (not that we're entitled to that or anything, I just wanted to point it out).

Reply on news.ycombinator.com