21–30 of 236 posts
Earlier quoted context omitted.
You found it to be fast in comparison to vim and emacs? I am surprised to hear someone say this. I also think it is plenty fast for my needs, but certainly not faster than vim or emacs. Did you mean fast in terms of performance, or in terms of your ability to edit, or something else? And you weren't using a GUI version of vim/emacs, right?
Vim can be really slow with too many plugins running.
VS Code is such an excellent open-source project, and also such a great tool despite the obvious and much-bemoaned inherent disadvantages (aka "tradeoffs") that come with being an Electron-based app that it, along with its cousin TypeScript, fundamentally changed my perception of Microsoft. I'm not monogamous with my code editors and typically have a few of them open. These days, I notice VSCode is very likely to be…
It certainly changed my perception of electron. I don't use it daily because my editing requirements are already well met, but it really is a lovely piece of work.
(For those who don't know, applications are typically QA-ed and packaged so they can be automatically requested and deployed via MS SMS or whatever the latest version is. No downloading .exe)
Typically this packaging process takes longer than it does MS to release a new version. They're in a constant state of catch-up, and it's frustrating for developers that want the latest and greatest version.
This release cadence from MS is completely killing some internal packaging operations at big corps I've worked at. (For those who don't know, applications are typically QA-ed and packaged so they can be automatically requested and deployed via MS SMS or whatever the latest version is. No downloading .exe) Typically this packaging process takes longer than it does MS to release a new version. They're in a constant sta…
As much as I wanted to like and use VS Code, Electron base still ruined it for me. If it was some other app where I do not expect instant snappiness and lower memory usage, for example, Slack (also Electron app), I would swallow it, but for an editor, I can`t.
How much memory does it use? My emacs instance uses ~200M with a moderate amount of files(along with other processes mostly repls). I would imagine VSCode to be in the same ballpark, and 200M is not that of a big deal imo.
https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-...
But an even better test is when using these editors on large projects with hundreds or thousands of files. Atom is a disaster. I tried to like VSCode and except Electron part and baggage it is great.
For this reason, I am switching to vim for everything except Java/Kotlin. There is nothing even remotely close to IntelliJ for Java or Kotlin and you can use very nice vim bindings in IntelliJ. I also keep Sublime installed for quick file edits when browsing the filesystem with GUI apps.
Earlier quoted context omitted.
You found it to be fast in comparison to vim and emacs? I am surprised to hear someone say this. I also think it is plenty fast for my needs, but certainly not faster than vim or emacs. Did you mean fast in terms of performance, or in terms of your ability to edit, or something else? And you weren't using a GUI version of vim/emacs, right?
Yes, absolutely. I'm running vim in iterm2, and I haven't had time to figure out why it's slow. Things that are really slow in vim are scroll speed, a 1s-ish pause when ALE fills the quickfix window, and an undiagnosed merlin-related pause when opening ocaml files. So scrolling is slow. Terminal related? Maybe - terminals are slow. But when highlights an error in elm or ocaml code, scrolling becomes unusably slow (no…
Earlier quoted context omitted.
Yes, absolutely. I'm running vim in iterm2, and I haven't had time to figure out why it's slow. Things that are really slow in vim are scroll speed, a 1s-ish pause when ALE fills the quickfix window, and an undiagnosed merlin-related pause when opening ocaml files. So scrolling is slow. Terminal related? Maybe - terminals are slow. But when highlights an error in elm or ocaml code, scrolling becomes unusably slow (no…
iterm has terrible latency, you should try using alacritty - way faster.
This release cadence from MS is completely killing some internal packaging operations at big corps I've worked at. (For those who don't know, applications are typically QA-ed and packaged so they can be automatically requested and deployed via MS SMS or whatever the latest version is. No downloading .exe) Typically this packaging process takes longer than it does MS to release a new version. They're in a constant sta…
This speaks more about enterprise "packaging process". Why can't they let the devs manage their own machines? This is one big reason devs love Macbooks, because OSX just doesn't allow the employer to fuck around with the machine a lot.
And no devs at the corps I've worked at (big banks) have Macbooks for coding. If they do, it will just be connecting to a VM somewhere.
This release cadence from MS is completely killing some internal packaging operations at big corps I've worked at. (For those who don't know, applications are typically QA-ed and packaged so they can be automatically requested and deployed via MS SMS or whatever the latest version is. No downloading .exe) Typically this packaging process takes longer than it does MS to release a new version. They're in a constant sta…
This speaks more about enterprise "packaging process". Why can't they let the devs manage their own machines? This is one big reason devs love Macbooks, because OSX just doesn't allow the employer to fuck around with the machine a lot.
Part of the problem is that then the devs aren't actually managing the systems, they are blindly trusting the vendors. To a large extent, (re)packaging is make-work that should not need to happen, but it does provide a kind of safety fuse. In the event that a vendor breaks something or worse, unilaterally decides to change the product, organizations needs to be able to put a stop on new versions. The change of icons on VS Code was a trivial misstep, but it demonstrates that the VS Code team has the power to push changes that that users do not actually want on to large numbers of systems.
It is the same dynamic as the snap/flatpak vs. Linux distribution packaging debate. Most of the time, the developer can deliver their software faster, more reliably, and with better QA, if they are given a direct pipeline to user desktops. Sometimes, though, they will screw up, or they will make a decision that works for them, but not their users.