Hacker News new | past | comments | ask | show | jobs | submit login

VS Code remote in some cases is better than local.

As the remote can be a docker container, so when I have to do some experiment, I create a container takes 5 min to setup. I than can play around, test dozen packages and configs, once I am comfortable commit last version.

If I want to do some quick testing on project by different team, again a local container is setup in 2-10 mins. Once done delete the container and my local system isn't messed up.

Last is obvious use case if you want to test anything on reasonable large data or GPUs. Create a cloud server, get data run your code, tests. Push data to S3 and done.




vscode's model of server on host is good because of low latency.

It can be a bit heavy in cpu usage depending on plugins though.

I like emacs tramp in theory since it doesn't impose that, but latency suffers.

With correct ssh config it usually works well, but many times I'd prefer lower latency with emacs being on the host.

That's supposedly possible, but I've never gotten it working.


What were you trying to do with tramp? I’ve used it for coding Common Lisp, together with a remote SLIME session - ie slime-connect - and while I have run into at least 1 limitation with paths, I have a decent enough work around for it. I think the setup was just a matter of setting some customizable variables.


I typically use tramp for:

- docker containers - accessing boxes on same network

Sometimes its fine, but then perhaps because of regressions, I get buffers that never seem to recover and have to be cleaned up.


I see. I thought I had some .emacs customized settings I could share, but they're all slime specific. It appears tramp otherwise just works without further configuration - unless I set them in ielm and forgot about them before copying them over to .emacs, but I didn't see anything like that in my ielm history.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: