[debrisapron]

I am constantly confused by text editors pitching themselves on speed. Is the world really full of developers going crazy with frustration because they’re waiting on vs code to do something? I opened a 100,000 line text file a few days ago & it rendered in like half a second, considering I do this about once a year it’s really more than good enough.

[SCdF]

I would invert that: when was the last time you tried using a text editor that boasts speed instead of VSCode?

I am forced to use VSCode for extension-based reasons, but have Sublime Text installed as well that I can very occasionally use. The difference each time is staggering, like a slap in the face. Scrolling smoothness, input latency, snappyiness to jump between files, or search workspaces. Each time it's so obvious. It's just so much more pleasant. Like going from being hunched over a tiny laptop screen to sitting in front of an all encompassing ultrawide, or going from an old laptop to a new desktop.

It doesn't mean that VSCode is an unusable pile of garbage, just as a tiny laptop screen isn't unusable. But the difference, at least to me, is undeniable.

[amelius]

I'm often coding on a server with like 10ms round trip latency, so I'm not bothered by the small latency that my editor introduces. I'm using Vim, by the way.

[samtheprogram]

Same, and despite this, Vim over SSH feels better than regular VSCode (assuming a decent internet connection).

[rpacut]

Ever tried the Remote-SSH plugin from Microsoft? With it I had the exact opposite experience, I'd regularly forget I was working on a remote dev machine!

[yjftsjthsd-h]

I was under the impression that the smallest time humans can perceive is like ~30ms, in which case 10 is effectively instantaneous

[nox101]

my machine must be faster than yours. I have both. I can't tell the difference

[lrhegeba]

i guess which and the number of extensions will have a significant effect on lag

[moritzwarhier]

In this case it's important to note though that this is a necessary side-effect of offering a powerful extension API. If you – for example – install some badly coded extension that blocks the main thread to parse the open file into an uncached AST on every keystroke before rendering the input, that's the extensions fault.

Take my example with an ounce of saltt as I've never coded a VSCode extension. It is very well possible that the extension API prevents this particular example. I guess normally things like parsing source files have to follow guardrails that prevent this kind of bug, or at least discourage coding this way. And ASTs are exposed by VSCode's core for the natively supported languages.

Still, it's probably safe to assume that there is a lot of badly written code out there that does not pay attention to performance, or follows an "optimize-later" mindset.

Features surely often seem tempting to implement in a slow and unoptimized way, and anyone can contribute to VSCode extensions.

[robin_reala]

Also, size of files. Less of an issue for typical codebases, but VS Code historically has slowed to a standstill on anything remotely large.

[nox101]

I regularly work on a code base with 250k files. Haven't noticed any slowdown

[sebastiennight]

I think the comment you're replying to was blaming slowdowns on the size (in lines of code) of individual files, rather than the total size (in number of files) of the codebase.

[yjftsjthsd-h]

To be fair, that's always true; I've managed to make even vim stutter with the right extensions/configuration.

[Bjartr]

Also, some people are just more sensitive to it than others.

[dan-allen]

I have exactly the same workflow: VSCode when I want a specific extension and Sublime as a fallback.

I think a lot of people don’t notice the difference but I can’t un-notice it.

Huge generated files and whatnot, VSCode just spins but Sublime opens them instantly.

Not to knock VSCode: it’s amazing what they’ve done especially comparing it to other web-stack apps (like what is Slack doing that it’s slower than VSCode with 6 extensions running?!).

Even when things are running smoothly, the just-perceptible delay in switching files or a slight stutter scrolling feels like the digital equivalent of working with a cheap tool.

The cheap ratchet is a little sloppy and occasionally the pawl doesn’t catch but it still does all the same stuff. Yet Snap-On still has customers.

[Swizec]

VSCode is blazing fast on my 5 year old personal laptop. VSCode is frustratingly slow on my M2 work laptop full of corporate nannyware.

It’s not VSCode’s fault ;)

JS-based apps happen to interact terribly with nannyware for some reason. I see it every time I run one of our node services, everything just grinds to a halt while the antivirus freaks out about how dare I run a piece of uncompiled code.

Slack and friends have the same problem. Discord actually runs better in a browser than as a standalone app.

[whizzter]

This probably needs far more attention than it's given.

A half-wild guess here is that because viruses uses various ways to hide themselves the anti-virus software probably scans W^X codepages on changes, so anything JIT compiled (all modern JS engines) will trigger a lot of spurious scans (kinda like how compiling and writing .exe files can grind turnaround times to a halt).

[buzzerbetrayed]

> JS-based apps happen to interact terribly with nannyware for some reason

I mean, yeah.. because they're slow and resource intensive. Your comment directly contradicts itself: It IS VSCodes fault.

And BTW, it doesn't have anything to do with "nannyware". They slow down on any computer that is under the tiniest load.

[serial_dev]

I'm in almost the same boat. Speed absolutely matters, but you only notice it when you don't have it.

I'm working on a large Dart project and a long time ago someone thought that having the project split up into 100 packages would be a great idea (it's not).

My previous editor was IntelliJ as I am used to its keyboard shortcuts, but it struggled with our setup: constant freezes and even if it didn't freeze, it would take seconds until the suggestions came up (or when I wanted to rename a local variable, smh).

I was so frustrated by it, that I installed helix, it was fast so I'm now learning to use it as my daily driver.

I have now both open, doing my editing on helix, and if I feel like I can go something faster in IntelliJ (which now happens less and less often), I do that little thing in IntelliJ and come back to helix.

Why helix: it's "great by default" and I didn't have much success with setting up and customizing NeoVim (it didn't feel good, the plugin were annoying to learn, and it started to slow down). I'm sure it a skill issue, but helix just works for me, and I can live without plugins for now.

[mafuyu]

It’s the small latencies that add up for me. I usually use a tmux + nvim setup, but for codebases that require a bit more language server support (eg. C++20 and sometimes Rust), I have a VS Code setup with the nvim plugin that I’ve spent way too many hours tweaking hot keys and things.

Despite all my tweaking, VSCode sometimes just feels like it’s a beat behind, and keyboard commands get dropped in the transition between panes and such. Even just scrolling with nvim keybinds feels a bit off. My key repeat rate is fairly high, and I’ll hold down ^D to skim through a source file. VSCode’s renderer struggles to keep up smoothly sometimes.

This is all nitpicky stuff, not enough for me to swear off VSCode or anything. But it’s just annoying enough that every once in a while I end up in some rabbit hole of VSCode internals and css tweaks, instead of doing actual work. Most coding does not require a ton of bouncing around, but it does feel very liberating to have confidence in my inputs as I navigate around.

[dleink]

Wow, that's a great way to phrase it. I'm currently setting up a basic laptop with speed like you're describing as a goal. "Confidence in my inputs" is an underrated value in HCI. Of course websites have to implore users to not click on this again while it loads, they don't have confidence in their inputs!

[saurik]

Something actively dropping inputs is an entirely different category of problem than it merely being slow to process them.

[dleink]

Yes, But for "confidence in inputs" the difference doesn't matter.

[saurik]

I honestly don't see that? If it drops inputs, you can't have confidence in your input; but, if it is merely slow to process them, then you don't lose confidence. If you know for sure that something will happen--and even that it will happen in the correct order, as in this case--you can just move on with your life. Have you never worked with a remote text editor over high latency? Or played a musical instrument that had a slow reaction time?

For avoidance of any doubt, I care deeply about my editor latency and agree that those terminals who claim to be "fast" and yet only care about average--not even common--throughout instead of latency misunderstand the problem space... and yet, I still can't say that it is reasonable to lose "confidence in your inputs" if a system is merely slow to process without losing any of your events. If an editor drops any of my inputs at all ever I 100% lose all confidence in what I'm doing; but if it always works then I can close my eyes and still use it without issue!

[mafuyu]

I think this gets at my feelings on latency as well.

Terminal emulators with GPU-accelerated rendering became popular, but I often found the latency to be quite bad. (I eventually settled on Kitty and foot.)

With VS Code in particular, it’s just not designed to be operated via keyboard. With enough effort, you can map/script everything, but many actions translate to opening a pane and then focusing it. It’s an implicit modality switch that often ignores input during the transition. Also, opening a new terminal is oddly slow, I think due to VS Code injecting things into zsh init.

With tmux+nvim, it’s much more predictable. For example, if I think “I want to copy three lines out of this file and paste it into a new shell”, it’s just: `3yy alt+enter ctrl+shift+v`, and I know it’s going to work every time. Not to mention the composability of keybinds in different scenarios.

(Also, hi saurik! Cydia on my OG iPod Touch is a big part of what got me into coding in the first place :)

[bemusedthrow75]

You are a data point for the notion I mention in my own reply to the parent that keyboard-only navigators might be feeling this more than mouse/trackpad users. Which seems likely to me.

[mafuyu]

Agreed. I elaborated a bit more in a sibling comment about how many keybinds result in opening a pane and focusing it, and it’s just not built for being operated by keyboard. Although you could make the argument that using the mouse just hides all the latency. Scrolling through text buffers is super smooth… but at what cost?

[WuxiFingerHold]

> but for codebases that require a bit more language server support (eg. C++20 and sometimes Rust)

Unfortunately, for this use-case, neither Zed or Laplace will likely to fill the gap, as they rely only on LSP as Neovim. That's also my issue with both: They should focus more on providing features to support coding, not just speed.

[stracer]

Some corporate employees use a notebook loaded with extremely invasive and performance-degrading security and spying software that can't be uninstalled. When your available cpu and disk time is 10% of what the hardware can do, you need as efficient editor as you can get.

[mattlondon]

You're probably not going to be able to install random binaries from the internet on those kinds of machines though.

[stracer]

Sadly true... Maybe in a few years, if it gets popular enough, and the key decisionmaker gets wooed into allowing it.

[akdjidensb]

Don't need to install them if they are portable (most everything can be made portable with some work, see scoop packager manager for instance). As long as the company isn't batshit crazy and has the resources and IT spend to afford to use something like applocker, in which case I'd seriously recommend looking for other employment if you cannot get explicit guarantees about administrative access.

[Keyframe]

For me it's the latency. It's not a deal breaker, of course. It's more of a first world problem akin to I don't know, guitars? High vs low action if you know guitar "problems". There's no coding problem where it's dependent on speed of typing; programming is mostly about reading anyways. It's more about the feel of it, like we're picky about keyboards and touch feedback we get. I guess spoiled, but nonetheless...

[bemusedthrow75]

Hm, except high action is also a positive choice for some, not an inherent problem.

(Though I like the attempt at an analogy and I see how it works for you at least)

I am a high-action player —- I know I know, a monster! (but also a brass and heavy glass slide player)

[rplnt]

Gonna pile up. VS Code with barely any plugins on M1 is noticeably slower than IDEs I've used 15 years ago on a hardware from 20 years go. Slower to render, slower to react to my inpit. It's bordering on unusable on a x86 laptop from few years back.

Better showcase on how ridiculous the tech stack is would be to open a 500 line file with a code and scroll. Startup isn't great either, though it isn't comically bad as it used to be.

So yeah, I want to see the authors of any desktop software to address this modern problem of writing slow UI. Otherwise I might assume they don't care.

[jmrm]

Some people need to use at least one time in life IDEs like Visual Basic 6 in a Pentium 4 to feel what it's like to use a fast IDE

[pwython]

What IDE do you use nowadays if not VS Code? I'm curious because I'm also using an M1 Mac and I've ran through the gamut (Sublime, PyCharm, Atom, etc).

[rplnt]

Sublime mostly, not a fully-featured IDE I'd say. For front-end I'm using VS Code, that's only here and there, and that's where the struggle comes from.

Last time I've tried Idea/etc was quite a few years ago. It didn't feel great. But maybe I should force myself into it. Might be better on M1.

I also open regular Visual Studio every few months for C# on Windows, and while it's slow to start, the editor feels really solid, quick, and responsive.

[jahsome]

Yes. I have an org issued machine with crap specs and dozens of repos I switch between all day long. Waiting 30s-2m doesn't sound like much but it breaks flow and leads to a lot of "what was I doing again...?" Sidetracks

[Cort3z]

Sounds like your org is bad at basic arithmetic. 12230s = 12 minutes per day minimum. Assuming an engineering salary at perhaps 100k usd /year, that is about 40,7 usd per hour, they would save money by giving you a max specced frame.work(2500$) after 307 days (maximum). Assuming you do this more than “2 dozen” times per day, as you say “all day long”, at minimum they would make that money back in 7.7 days. The same numbers for a max specced MacBook Pro (at 7200 usd) is 22.1 to 884,5 days.

I get mad at this attitude from some companies. It’s like telling a carpenter that they have to build a house, but are not allowed power tools. It makes no sense.

Edit: typo

[arghwhat]

This is the case for most orgs with corp IT. Their KPIs are around security, which often manifests itself as a game of "how many security products can one run in parallel". Crapware like Cisco Secure Endpoint (not to mention Umbrella), Thycotic, Netskope, and whatever else is the current cool way for a corp to MITM itself and introduce kernel vulnerabilities.

This in turn puts departments at odds, as their argument for speed is turned into an argument against security, which is a very hard position to be in if your department is a few layers down the corp stack.

[Cort3z]

I don’t understand. How does speed implies inverse security, even with corporate blinders on? Let’s say the add all the bloatware in the world, how would a slower developmental speed compromise the security? That their ability to push code goes up and their potential for bugs increase?

[arghwhat]

Security solutions impact speed, rendering reasonable and performant machines borderline useless. There is no implication that working fast is bad for security.

[akdjidensb]

We should be clear that it isn't ALL of corporate IT that is on board with this, or probably even the majority. Its the windows sysadmins that have to deal with non-technical end users, and are constantly being hounded about trivial shit like people clicking on phishing emails and that sort of thing. In fairness to the windows people, you probably wouldn't believe just how awful the majority of workers are with computers. So it's understandable why windows sysadmins become hyper paranoid and irrational in a lot of cases. The low pay doesn't help either. Windows sysadmin is usually a lower tier job within IT and is the most likely to suffer cost cutting and be forced to "outsource" security work to a pile of rotten security software. It's also entry level, and so sometimes they are only marginally better with computers than their end users.

Ideally, most programmers should be in IT or have some kind of alignment with IT and able to give some pushback about this during CAB for instance, and/or get some exceptions but that is increasingly difficult the more 'agile' an organization becomes and the more it seeks to silo infrastructure people from application people. A good IT department imo is one that doesn't do this and retains a more traditional culture where programmers are part of IT and able to actually influence the technical direction of the company, not just be treated like a product factory for business units.

Just from personal experience working as a programmer on the infrastructure side...complaining about windows sysadmins was the favorite past time of probably the majority of higher tier IT employees. It makes our jobs incredibly difficult for the same reason it makes application developers jobs difficult.

[arghwhat]

Problem is that most corps in my experience are run by such windows sysadmins, and when you're a subsidiary or two away from the IT department it doesn't matter whether you're all greybeards - you don't have authority. Best you can do is manage to fly under the radar.

On the other hand, you'd be surprised by just how many career programmers are completely inept at sysadmin work and have no sense for security (nothing like CI pipelines using personal credentials and committing keys into public repos), so just letting all programmers do whatever isn't a great policy either...

[Cort3z]

This assumed by the way that the speed goes to infinity, which is untrue. But the result would most likely be indistinguishable from instantaneous from the point of view of the developer.

[reaperman]

Except carpenters bring their own tools, so they can determine the price: value that’s right for their pocketbook.

[jimbokun]

A lot of developers would be ecstatic to have a tools allowance and the ability to use whatever laptop they buy on the corporate network.

[jonathankoren]

What are you waiting two minutes to do?

[formerly_proven]

With corporate Windows laptops the real question is "what aren't you waiting two minutes to do?"

[jahsome]

My machine to respond to double clicking an icon, or using Windows search, or open teams (just kidding that one takes closer to 10).

[Daeraxa]

I'm on the team working on Pulsar, the community fork of Atom. You have no idea how much we hear "Atom is slow", "are you making it fast?" etc. I have honestly yet to work out exactly what is meant by it. Startup times, sure, you are never going to get Pulsar/Atom or VSCode to launch as fast as a terminal editor or a super lightweight native one but that isn't how I personally use that kind of editor - once it is open it stays open for a long time. Keystrokes, context menus, highlighting performance, I honestly don't see where this perceived slowness is.

I'm not saying it isn't valid criticism but I guess the way I work with an editor just isn't the same as others who experience this.

[maccard]

> Startup times, sure, you are never going to get Pulsar/Atom or VSCode to launch as fast as a terminal editor or a super lightweight native one

Would you consider something like emacsclient's approach - a daemon running in the background that a window connects to?

[jwells89]

Sometimes it’s actually speed that’s the issue (when e.g. opening massive text files) but usually “speed” is more about responsiveness in editing, text navigation, etc, which some people are very sensitive to. The time between action and reaction is best minimal as possible.

[bemusedthrow75]

I have a sneaking feeling that the people who use only their keyboards to navigate are the ones who really notice latency in e.g. VSCode.

I navigate with the trackpad on a Mac and seem not to ever feel it, but I know others do not like this way of working, which is fair enough.

Lapce is interesting to me for other reasons: it is one of the few[0] GUI text editors with a remote dev option that matches what VSCode can do. And it might have a smaller footprint on the remote machine/in the container while doing it.

VSC’s remote dev support is very nearly non-negotiable for me now, so I say more power to them; I intend to try it again properly soon.

[0] there is another editor that was mentioned here recently that can achieve this with a plugin, but I forget the name

Update: Zed is that editor.

[nicoburns]

> Is the world really full of developers going crazy with frustration because they’re waiting on vs code to do something?

Absolutely. How new/fast is your developer machine? A lot of developers are working on computers that are several years old and may not have been that high-spec to begin with. It's generally not basic editing that's slow on it's own. It's trying to run several editor windows at once (say a frontend and several backend services) along with all the other things required for work: the project itself, compilers, video calls, etc.

As a reference point my 2015 MacBook Pro struggled with VS Code + Google Meet at the same time.

[pcthrowaway]

> Is the world really full of developers going crazy with frustration because they’re waiting on vs code to do something?

If programming in Rust on a medium-to-large project, you might be waiting minutes for your editor to finish checks to highlight compilation errors every time you save. That was me on a Rust project last year when I was trying to program on a 2019 macbook air with 16GB of RAM and 1.1 GHZ quad-core intel processor. Typical wait times to check what I'd written would be 30 seconds to just over a minute. It was excruciating.

I finally demanded the employer set me up with a cloud VM that I could use when working with that codebase, as the network lag with VS code opening the project remotely was so much more tolerable

[danielheath]

A few years back, someone built a webpage that had various text fields with different typing latencies.

A bunch of my friends tried it, and it was really interesting to see that many of them were not bothered in the slightest by even quite high latency numbers.

Personally, I was mildly bothered by the "single frame of latency" example and _intensely_ bothered by all the higher numbers. It just felt really yuck to use; I would hate to be doing that all day.

I can't tell you what exactly it is, but yes: the world contains many developers going crazy with frustration - not because of a 30 second wait, but because of a 30ms render delay.

[veber-alex]

It's like phones with 120Hz displays.

You don't know you need it but once you have it it's hard to go back.

[bloopernova]

Similarly with monitors, 60Hz LCD panels are OK, but 120Hz panels are just so much easier on the eyes. At least for me. Try dragging windows around or scrolling quickly, and you'll see the difference between 60 and 120 very fast.

[FpUser]

I can spot the difference but the value proposition is zilch to me. I would not pay 1 extra cent for it. If I was a gamer this would of course matter.

[giancarlostoro]

As someone who owns a Sublime Text license if its not an IDE it better be as fast as Sublime or im just going to use Sublime instead.

[franky47]

Frustration often comes with extensibility: adding extensions on top of VSCode that need to run at file save time (eg: formatters) can lead to pretty significant performance drops.

This extensibility is probably what made VSCode popular though, especially for web devs since the extension mechanism is JavaScript-based.

Makes me wonder if those Rust-based tools (Lapce, Zed) will have as much success with Rust-based extensions authoring.

[maleldil]

I don't know about Lapce, but the plan for Zed is to have WASM extensions.

[Fraterkes]

Vscode is nearly unuseable when my 5 year old thinkpad isn't plugged in. So yeah.

[systems]

for me its the plugins speed

a good example is magit on emacs, magit seems great, and i really want to learn it and use it, but its very slow (at least on windows its slow enough to make you unable to practically use it)

in short, speed changes everything

[akdjidensb]

It's less about waiting for vscode to do something and more about the general feel and experience of movement and typing in the editor.

"Speed" is probably the wrong word, it's latency that matters.

[myaccountonhn]

Yeah I find delays make me lose my train of thought and can be frustrating. Especially once you've experienced an editor where everything is instant (kakoune).

[baby]

I think it's just that everybody has been looking for THE editor, and so it is natural that people would develop their own. I think what we're seeing is that VSCode is becoming THE editor (if it's not already there). At this point it's hard to compete. I think the biggest contender is IntelliJ, as many people really seem to enjoy it, but I would predict that it's going to be hard to fight against free.

[pandemic_region]

Is anybody else finding Intellij more and more getting in the way in an obtrusive manner? Code completion suggestions are getting worse, formatting ability is basically none existent if your statement is missing a comma or a lambda, it keeps reindexing my local maven repo, code completions are slow to appear... I was a huge fan of their products but now I'm getting more and more annoyed. Maybe I'm getting old?

Several times I have been on the brink of trying out spacevim for java development , out of pure frustration but the amount of config and tweaking needed scares me. I don't need much, lightning fast auto complete, auto import and Google code formatter integration. One of these weekends I'll bite the bullet I think and set it all up.

[WuxiFingerHold]

I noticed that a couple of years ago. 10 years ago or so, Jetbrains was the gold standard. Then support and quality started to rot. Issues not resolved for years, esp. for Webstorm. Instead building new products and features I was not interested in. I needed proper tailwind support back then, not some cloud colab solution for enterprises.

[FpUser]

Not sure about how Jetbrains does in general but I have zero hesitation paying for perpetual license of their all inclusive package. It is peanuts compared to value. I still use VS code to do some remote editing / debugging as it is somewhat better experience. Hopefully Jetbrains catches up in this department one day.

So yes. These two are THE editors for me.

I only deviate from these when I need to do Delphi / Freepascal development.

Notepad++ / Notepadqq are being used as in place hotkey invoked text editors.

I still try new ones out of curiosity but I have hard time understanding why any would succeed. How they're going to get the same amount of extensions / plugins in order to match functionality?

[jlengrand]

Not that I disagree, but IntelliJ has a free version, and they're building up Fleet as an attempt to compete. Future will tell.

[FireBeyond]

I had such high hopes for Sublime Text, but then development slowed to what seemed like a glacial pace, with every upgrade requiring another licensing fee.

[andrepd]

I'm happy with it even with "slow updates". What features are you looking forward to?

[antisthenes]

Okay, just as a counterpoint, I opened 2 10,000 line files and tried to do a diff between them in VSCode. It took more than 20 seconds?

Yes, it breaks workflow and is incredibly slow.

Just like refreshing elements in UI shouldn't take multiple seconds, or a webpage shouldn't take multiple seconds to load on a good connection.

[stracer]

I tried the same in my Linux terminal emulator, and it took 0.2s, when I added colors, 0.3s. That's 100x faster - maybe diff in VSCode means something different than running diff and printing the output? Did you include the time needed to open the files?

[antisthenes]

Yes, the files themselves open quite quickly, but I will admit that it's a complicated diff (lots of expected differences), and VSCode is not primarily a diff tool.

But also 10k line file should be nothing for a modern PC.

[serf]

if vs code felt as responsive as emacs or vim, i'd use it. I don't really care about 'start-up time', and if I did then using emacsclient or some such with a daemon takes care of that issue entirely.

there is no convenient way for me to 'plug-in' the responsiveness of something like vim or emacs into vs code.

to be clear : responsiveness is things like opening a context menu of any kind, switching contexts, text drawing and blanking ; just things that add up to create a quick feeling piece of software. vs code/atom/whatever and other 'larger' graphic-heavy text editors feel slow.

[camel_gopher]

Is it as fast as vim or emacs? If not then a tough sell from my view. Same with chewing up cpu cores.

[umanwizard]

Emacs is not known for being particularly fast.

[tomlin]

They are saying it's made in rust, so they are probably trying to counter concerns.

[perrygeo]

It's not about speed in terms of absolute cumulative time. It's about the interleaving, the user experience of latency, and the effect that has on our cognition.

A few ms of noticeable latency here and there, a few hundred ms freeze every once in a while, it's maybe an extra minute per day in clock time. If it was just a 1 minute startup penalty, that would be different. But this 60,000 ms is split up throughout the working day into hundreds of small pauses, making the system feel laggy and unpredictable. If you're lucky, it's merely a subconscious drag on your attention. If you're unlucky it will, have you constantly breaking concentration to wonder "is my editor frozen? Oh wait, never mind." Hundreds of times a day.

Now contrast that to a text editor with literally zero instances of noticeable lag. It's not that it has zero latency, it's that the I/O latency on modern hardware is faster than our fingers and eyes can work. So we don't experience it.

Hundreds of noticeable pauses versus zero pauses. Once you cross the threshold below which our fingers type and brain can read, you're lag free. Getting a faster text editor doesn't just slightly improve the lagginess, it completely solves it.

[xutopia]

If you pair program every ms counts. In video conference another half second does a huge hit.

[tasn]

Nowadays I just assume "lighting fast" means "written in Rust". Even if it's actually slower than the status quo.

I'm a Rust fanboy, so not dunking on Rust. Just an observation.

[spullara]

Just a bunch of people optimizing for the wrong thing.

[rstat1]

Optimizing for efficiency and performance is never "the wrong thing"

[spullara]

Optimizing for efficiency and performance over utility is absolutely the wrong thing.