171–180 of 227 posts
Has anyone tried this and ssh'd into a container ? IIRC VSCode struggled to correctly ssh into a container that's set up in your `.ssh` config file. Not sure if this fixed it: https://github.com/microsoft/vscode/issues/194879
Earlier quoted context omitted.
You don't need to beat microsoft in order to have a viable business. You just need to get enough market share.
But, you also have to be better than what’s freely available by enough to get someone to pay for it. Having a good product isn’t good enough, you have to be significantly better. Dev tooling is a notoriously difficult space to make money. Free tools tend to win because if a tool costs money, a developer is just as likely to write their own version. (For better or worse)
No, free tools win because a proprietary license is a rent-seeking ball and chain on your means of production.
Earlier quoted context omitted.
I use VSCode + SSH remote for this and works great. The only nitpick I have is needing to manually reconnect when I suspend my laptop and ssh connection breaks. It's a separate session though, which doesn't matter to me but may be a deal breaker for you. I use Tailscale for a personal VPN so the beefy workstation is always securely available from my laptop, even when across the pond).
Thank you both for sharing the experience. I'm tempted to go lightweight laptop + beef server. Do you get used to the the input delay? I guess coding is not a FPS game so it's fine. Just a flow of words being edited.
(edit to explain: VSCode is still running locally, but it also installs the server-side (headless) component on the remote machine. That way editing files is local/fast, but stuff like running the code, search/replace/etc also works fadt because it's handled by the serverside).
Terminal (incl vscode terminal) feels slightly sluggish, and it's noticable if the server is in another country and uncomfortable if across the pond.
Just a FYI, this feature will install a binary on the remote host and run it. > Your local machine will attempt to connect to the remote server using the ssh binary on your path. Assuming the connection is successful, Zed will download the server on the remote host and start it. https://zed.dev/docs/remote-development
As long as that is notified and correctly authenticated, it is a reasonable approach because the remote process can progress without having to send the whole workspace through SSH. I also expect most language servers would have to be on remote for the same reason.
(You could theoretically make a truly portable and hermetic binary blob with something like WASM, but I guarantee you this black magic is not accessible to IDE developers.)
Those who do not understand Emacs are doomed to repeat it. Poorly, in worse languages. —C.S. Santayana Emacs TRAMP mode has been doing this for 26 years, since November 1998. Fashions come, and fashions go, and Emacs remains. Anyone remember Atom? Anyone remember TextMate? Just use vi or Emacs.
"Just" does quite a bit of heavy lifting here. VSCode and Zed are much easier to use than emacs or vim. To me as a user, emacs lisp (and lisp in general) is the worse language compared to TypeScript which I can work with.
False. It's just that Emacs comes with fewer features out of the box.
> emacs lisp (and lisp in general) is the worse language compared to TypeScript
Elisp is truly a piece of shit language, but TypeScript is not much better.
Earlier quoted context omitted.
As long as that is notified and correctly authenticated, it is a reasonable approach because the remote process can progress without having to send the whole workspace through SSH. I also expect most language servers would have to be on remote for the same reason.
It's not a reasonable approach because these binary blobs they're installing are guaranteed to be non-functional unless the target OS somehow happens to be the exact distribution and version the binary blob developers are testing for. (You could theoretically make a truly portable and hermetic binary blob with something like WASM, but I guarantee you this black magic is not accessible to IDE developers.)
Whoever makes publicly available binary blobs are necessarily aware of all those issues and try to engineer them to be resilient enough for most environments. That's why they typically work well even though they generally have little information about the system besides from most basic ones (ISA, OS/kernel and ABI to be precise). This is significantly more difficult in Linux due to its higher variability, but not even close to impossible.
Earlier quoted context omitted.
Unless you need a graphical debugger, then vi/vim/nvim/emacs all start to get creaky. That single requirement keeps me on vscode. I'd love a terminal based alternative.
Graphical as in integrated with the normal editing view? There's a new very nicely done one for Emacs: https://github.com/svaante/dape . The documentation about using it is currently a bit terse though.
At the moment, the Zed IDE is more like an lightweight ai-assisted text editor for me.
Earlier quoted context omitted.
This is answered in their FAQ: https://zed.dev/faq : We envision Zed as a free-to-use editor, supplemented by subscription-based, optional network features, such as: Channels and calls Chat Channel notes We plan to offer our collaboration features to open source teams, free of charge.
For a VC-backed company, this will never ever generate enough revenue growth. So, the real answer is: "If all goes well, we will keep raising VC money and get acquired and shutdown / butchered in 5-10 years". Like Bluesky, this monetization plan they present is just something to calm down the haters and sceptics. But if you think for two seconds, it does not make sense.
Whenever you encounter a VC backed open source project you know the rug pull will come eventually. It doesn't make the code they have written any less useful. If the tool is good enough then it will be forked and live on.