Lapce | Hacker News Reader

Lapce

lapce.dev

524 pointstosh225 comments

Lapce dev here. Firstly sorry for the bad experience for some people.

Just a bit of context here to explain the status of the project. The first line of code was started around 2018 as a personal project. And as of today, we still don't have anyone who works on it full time. We don't want to defend ourselves too much here, because there are very good quality code editors out there such as Helix, which is also community developed. But still, GUI is just such a beast of complexity, which consumes lots of time and energy which we already lack. That said, we had developed our own cross platform GUI toolkit called Floem, because as you may know there aren't any good ones that exist.

The journey was fun and challenging, but the aim of the project isn't a toy, and we believe by taking slow but firm steps, we'll reach production quality, one day. Before that, please do bear with us, and help us if you can (as in code).

Don't apologize! It's not like you've taken anyone's money. HN can be a tough audience, but I don't see any (serious) comments that are putting down what you've done--just pointing out issues they personally experienced. I posted one myself. Informal bug reports.

Honestly this is about what I'd expect from pre-alpha software, though I do agree with other commenters that that label should be more prominent on the website to manage expectations.

Taking on something like VS Code as a competitor is ambitious, as is building a native UI library from scratch. Personally I applaud your effort and I hope this project succeeds.

Just wanted to stick a link the Floem GUI toolkit mentioned above:

https://github.com/lapce/floem

because IMO it's as interesting as Lapce in it's own right.

Thanks your contribution! I just downloaded it, installed the Rust add-on, and it automatically used rust-analyzer showing all the information of types and structs. It maybe needs some polishing, but looks like it works like it should, and it does it really fast. I'll test it better tomorrow, the running and debugging interface seems really simple and interesting tbh

On the side of the GUI, what made you make Floem instead of using egui or other similar library? As far as I looked, looks like a non-native reactive GUI using some 2D graphics library like the other ones. Does the granularity in that reactivity have a big importance in that?

Apart from that, if Floem is easier to use than other graphical libraries for complex designs, or if you make a GUI designer like you have in Visual Studio, Qt, and similar, it can help a lot of people developing apps in Rust

I think it might be better for all if the landing page was geared more to contributors (coders and bug finders) as opposed to end users.

From Servo's site:

> These pre-built nightly snapshots allow developers to try Servo and report issues without building Servo locally. Please don’t log into your bank with Servo just yet!

Though I'll say even Servo's site is lacking too.

There's no need to apologize, after all you're making this for free.

It's refreshing to see a new IDE that isn't using Electron. Yes, I know Zed is native as well, but it only is macOS compatible, and I use Linux.

I am using Qt Creator, and it is absolutely amazing for C++/CMake based development, but I will have to give Lapce a try and see how it stacks up.

I'm shopping for an IDE with Vim keybindings, but this doesn't seem to be it yet. Points for having Vim-like support out of the box, but most of what I tried failed, including:

- Exiting insertion mode with ctrl+c or ctrl+[

- Shift+U to undo all changes done to the current line

- `di[` to delete the contents inside the current [

- `dta` to delete everything until the next `a`

- Shift+[ and shift+] to jump paragraphs

- Shift+D to remove everything until the end of the line

- `.` to repeat the last action

It's a good start, and I'll definitely check it again in the future, but I'd hold on advertising "Vim-like" editing until the support gets better.

The rest of the editor is awesome, no complaints so far.

> Shift+U to undo all changes done to the current line

Been using Vim for over 15 years and didn't know this one.

I know right!

> I'm shopping for an IDE with Vim keybindings

Me too. Both extension for VS Code have too many quirks for me, and I left the Jetbrains world and intend not to go back (due to too many disappointing support issues).

Try a Neovim distribution like NvChad, LazyVim, LunarVim, SpaceVim, AstroNvim, CosmicVim, etc.

I try this editor every few months to see how it's progressing and is still way too early to use as a daily driver.

People suggest this over Zed very frequently. In my experience Zed is way more mature and stable. That being said, it's no one near as usable as neovim with a good plugin setup, let alone a mature ide like Jetbrains products.

Jetbrains IDEs might be slow, but I'll get a hell of a lot more done in 8 hours with it. Once you learn to use the features well, it's incredibly powerful. I love vim, but generally use jetbrains.

If Jetbrains took 500ms to load a file vs 1ms to load, my productivity isn't going to change dramatically. It's fast enough. Yes initial indexing is slow, but it's easily worth it.

All this being said, I think Lapce is very informative as a resource to anyone trying to build an editor in rust.

I've tried Lapce several times over the past year or 2, and have never gotten more than 5 minutes in without it hanging or crashing. I wish I was a rust programmer, but Lapce is not a good poster-child for the language, IMO.

It's not the speed, or even the phoning home that make me rage-quit VSCode on the regular. It's the RAM. EVERYTHING slows down if you only have 24GB and try to use VSCode.

I too use intellij and neovim for everything and agree mostly, but what's your motivation to check out new editors? Is it for just for fun? In my mind an editor is one of those things I wouldn't consider changing unless the alternative is heavily funded and leagues much better than my current choice.

I try new stuff regularly. People can build cool stuff. Google is releasing a new IDE soon. I'll try it. Cursor.so is a cool idea. I tried it. Zed sounds great (I love high performance) so I tried it. Haven't switched yet though!

But I was 100% vim for years and over time, slowly started using intellij and friends. I hated how slow it felt. But as I learned the features, it became a no-brainer.

If I didn't try new stuff I wouldn't have used it.

I did the same thing with terminals for a while, and settled on Kitty. (I'd never use fig / warp). Speaking of which, IntelliJ 2024 EAP terminal is horrific. I had to downgrade.

As someone who uses Neovim, I would love to have a near-vim experience in something that has all of the convenience of VSC + a great plugin ecosystem. However, I'm not sure about the fact that in `normal` mode `:` just brings up the `cmd+shift+p` command dialog. Maybe I could get used to it, but the fact that something as simple as my muscle memory for "I'm in `normal` mode, better type `:w` just to make sure I've saved" automatically bringing up that dialog and then suggesting I `Close current window` immediately... is not helpful. If the command experience is going to be so different from vim them it's not really going to ever be a suitable replacement even for brief stints/pairing IMO. It's a shame because the VS Code vim plugin leaves a lot to be desired.

Neovim with Lazyvim is pretty good out of the box. In the old days, both Emacs and (Neo)vim although highly extensible, well, it was hard to configure and set up for the things you wanted to do.

Now, we have Spacemacs, Doom Emacs and Neovim with Lazy, Packer etc., so I really can have a 1st class "IDE" without needing to learn LISP or Vimscript (or Lua). So you do need a little bit of that to be able to edit the package.el or init.lua, but it's pretty much uncomment or cut & paste.

If you're looking for a (Neo)vi(m) tutorial, try this:

https://www.barbarianmeetscoding.com/boost-your-coding-fu-wi...

Just to be clear I love neovim (though I don't really like Lazy particularly, maybe I should give it another shot). Mostly I'm looking for something that is close enough to vim for me but also close enough to VSCode for the people I pair with.

Not vim (by design) - but have you tried helix?

https://helix-editor.com

I've used vim at a moderate proficiency level for 10+ years, but Helix's selection -> action motion design is just better, for a lot of reasons.

Helix has been looking for a GUI solution for a while now. ( https://github.com/helix-editor/helix/issues/39 ) I wonder if Lapce's UI toolkit would be a good fit.

Helix is a very good and well-managed project, but it's quite hostile towards its own community. There are no plugins, and they won't be in Wasm like users want, but in Scheme dialect named Steel, that nobody want... if at all. Missing features like copilot or file browser expected by the community are essentially never merged into the master. This might be a better path than total dispersion and destruction of what works, but my expectations do not align with what the creators offer, so I give them the freedom to choose. I keep my fingers crossed for its development, but I personally use something else.

As a user, I certainly do not find it hostile.

In a "batteries included" edit a service like copilot that expose all data to a third party is a terrible anti-feature.

As for script-oriented plugins vs wasm - I see a tradeoff - and don't think neither are right or wrong.

Cross editor plugins via a common wasm api might be fun, but perhaps not very practical.

Edit: link to relevant issues and discussion:

https://github.com/helix-editor/helix/discussions/3806#discu...

https://github.com/helix-editor/helix/issues/122

https://github.com/helix-editor/helix/issues/1927

Copilot has many fans, and for many, the ability to use Copilot is more important than all the other "batteries-included" features. It's not for me or anyone else to judge. Everyone should make their own choices.

Regarding plugins, I'm with Helix from the beginning, i have read everything, and I understand the motivation well and can accept it. Perhaps this is what the ideal editor looks like for creators, but it definitely doesn't look like the ideal editor for me. I respect their decision, but I'm sticking with Neovim and might switch to ZED when Linux support becomes available.

Why do you consider switching to ZED from Neovim? ZED is lightyears away from a good Neovim setup in terms of functionality and efficiency. The problem with Neovim is the setup and config to do all, but you already mastered it.

I still don't understand why you claimed that:

> [Helix]'s quite hostile towards its own community.

"good and well-managed" vs "[merges everything] users want" - pick one

Generally agreed, but in the editor space that's where plugins come into play. The plugin story for Helix is a long one, but I think it's converging and bet it's coming within this year.

I pick to stay with neovim.

Helix is a dream, as far as I can say from having played a lot with it, but only played. To be fully comparable to some IDE or Neovim setup like LazyVim, you need to complement it with other tools and use some workarounds, e.g. working the files (tree) or custom snippets.

(I'm still using VS Code to get my stuff done, but in a couple of weeks I got some time to spent to re-evaluate Helix and Neovim.)

You can use a snippet LSP to work around Helix not having a built-in LSP manager. They're listed in https://github.com/helix-editor/helix/issues/395

No but this seems neat! I'll check it out, thanks!

Use https://github.com/vscode-neovim/vscode-neovim instead.

Since v1.0+ of this extension I have been constantly having issues with neovim's and VSCode's buffers got out of sync. I cannot reliably reproduce the issues however. There are a few similar reports, e.g. https://github.com/vscode-neovim/vscode-neovim/issues/1624. I've switched to other VIM extension (VSCodeVim) which I found more reliable, albeit less powerful.

That's funny, because I switched from VSCodeVim to NeoVim for a similar reason.

I guess both have issues. But still, the power of VSCode with vim keybindings is still my best setup.

What are you missing from neovim?

There are plenty of out of the box configs that do most of the work for the user in terms of configuration that begs the question: why demand vim in other code editors?

https://neovimcraft.com/c

When I'm developing alone I mostly don't miss anything when in Neovim. However, even with mouse features enabled vim is not a great experience when I'm pairing with someone who is only used to using VSCode (which is a lot of people I work with). Ideally I'd like to have an editor which is very close to vim in the ability to use basic navigation, editing, commands (for instance, macro support would be nice but I can probably live without it) when pairing.

I guess that makes sense, I'm rarely in a situation where I need someone to work on my computer.

Agreed. : should be standard Vim commands. Command pallete should be a separate keybind.

Does anyone have insight into how Lapce and Zed compare to each other? I.e. what are the differences in project goals, current capabilities and roadmap? Thanks!

Lapce being cross-platform is a major difference for now, Zed plans to be eventually but it's currently only on Mac.

Now that Zed is open source they're actually quite similar in capability (even sharing a number of underling libraries). The biggest difference is probably that Zed is backed by a commercial company (and I believe they have plans to sell collaborative functionality on top of the core editor) whereas Lapce is more of a community open source project.

Lapce is also cross-platform whereas Zed is currently macOS only. But they seem to be making rapid progress on linux support so this may not be relevant soon.

This is my question too. I think I’m going to have to try both. AFAICT so far, Lapce is ‘just’ someone’s open source project that has got popular, while Zed is made by a funded-looking startup with several employees that announced they were switching to open source just a couple of weeks ago. Zed also has Copilot built in. Both look like great editors at a glance. Zed has more easily findable information about their goals - there’s a blog and a roadmap on their site. (I guess with Lapce it might be possible to get a sense of goals/vision by sifting through GitHub issues and comments, which I haven’t done yet.)

One thing I know of is that zed'a scope is a bit wider and includes some collaborative tools and enhancements. Don't know the exact details though.

it seemes closer ti what I actually need than zed. love zed's speed but remote development is mandatory in thus day and age

What makes you say that remote development is mandatory? I think it has less to do with "this day and age" and more to do with your current employment.

For me and a lot of people it is. But not because of employment. one big use of remote is to remote into docker containers. why docker containers? I can have a different set of dependencies for each project and yet have my different systems communicate with each other over a network.

but for me, the big issue is I run phoenix framework and the older version I'm running my project on can't run the tests on the arm version of docker os I had to create a x86 machine on hetzner.

From a developer perspective, Zed's licensing prevents it from being used/inspected outside of the context of other GPL projects. For example, Helix can't use nor read any of the code in Zed because it would pollute the licensing.

Making a fast editor is such a common hobby, everybody seems to be working on one these days apparently, yet memory safety and speed has never been a real problem in editors.

It would be much more impressive to explore a novel approach for editors more extensible than Emacs, or with a more innovative editing model than vim's.

If we are reinventing the wheel, why not at least try to make a better wheel that's never been done before?

Editors don't get made in Rust because people want better memory safety in an editor. They're made in Rust because people like Rust, and the Rust trademark makes anything associated more cool, no other language has reached such a godlike marketing status.

Counterpoint: The only really pleasant + mainstream + cross-platform languages for new client/desktop software today are Go and Rust. Depending on the Python interpreter or the JRE or whatever is a huge pain when you don't control the environment. Just spitting out a native binary really helps. (I say this as someone who doesn't personally find Go pleasant, but I understand that lots of other people do, and I respect the tradeoffs it made.)

It's called a hype cycle. A decade ago it was editors written in Go.

Did some such editor succeed?

Yet there are common complaints about how slow emacs is, same for VSCode performance.

And a better wheel is much harder (but there is a feature request for helix mode, that's more innovative than vim, maybe they'll add that)

> with a more innovative editing model than vim's

I think Helix tries to do that

Kakoune too. But if a project focuses on a novel editing model and not some other aspect of an editor, then implementing it inside Emacs might be the best approach.

If implemented inside Emacs, then it composes with the rest of its package ecosystem. Kakoune, Helix, etc. are somewhat set back by having to reproduce functionality equivalent to Magit, Org, LSP mode, and so on in order to be on equal footing for many users.

Evil, Meow, and God mode seem to show that Emacs is a good platform for such experimentation.

I don't have a lot of experience with Emacs, let alone evil (and none at all with meow or god). But my experience with it was that evil felt distinctly.. hacky? For example, Evil felt like it interfered with selecting restarts in Sly.

I've had similar issues with VscodeVim being weird in VSC. Ultimately the text editor is so core to a text editor (duh) that deeply modifying it is bound to give a worse experience than implementing it from scratch, even if it does give you a lot of nice stuff 'for free'.

> But my experience with it was that evil felt distinctly.. hacky?

Honestly that was my experience with all of Emacs, not just evil. I tried Doom Emacs a while ago, and while Doom does a great job at abstracting a lot of that hackiness away, whenever I tried to configure something myself it just felt like the entire Emacs ecosystem is based on random hacked-together 10000 line elisp scripts with 3 GitHub stars which abuse some weird undocumented legacy parts of Emacs. Basically everything except a few famous big packages (eg. Org, Magit, etc.) felt very weird to use.

Kinda surprising considering how comprehensive the Neovim ecosystem feels compared to Emacs', despite it also being a very niche editor

Was just trying it out earlier this week. Or at least wanted to, after hearing all the good opinins about it over the net. Unfortunately using xmonad it simply refuses to display in certain positions. When I found a position where the interface was displayed, there was still no tooltip on the icons, which makes recognizing their function non-trivial. Anyway, after I spent 8 minutes trying to find a place to set custom include folder unsuccessfully for my project, I gave up, and went back to QT creator.

Will try again next year.

Just installed this on windows 10. First time I tried to open it the window hung for 3 minutes until I killed it. The second time, I couldn't reposition the window by clicking and dragging. Third time I loaded it, it hung again.

It's an exciting product pitch but isn't working for me. I see now that there's a "pre-alpha stage" disclaimer on the download page and wish that were in larger font.

Not sure if you tried the installer or the portable version, but for me, running the latter required me to put it in a location where it had permissions to create the 'lapce-data' sub-folder. (And no, there was no sensible error message when that inevitably failed).

Having said that, there doesn't seem to be very much "there" there, right now. I managed to open a C# project using the 'csharp-ls' language server, but, other than suggesting some refactorings that I couldn't successfully apply, there wasn't much that indicated that this actually worked. Debugging certainly didn't.

It did load very fast, though, so that might make it worth checking out again in, oh, a year or so...

I guess it had a lapse.

Experience on Ubuntu: It opens, but double clicking the header doesn't make it expand. Then `Open Directory` doesn't do anything; no typing, no nothing. So close again, and open from command line with the directory as agument, works. Now I can't see my mouse.

My experience on Windows 11 wasn't as bad as yours, but I opened a small Rust project with Lapce (~20 files) and it uses 1400MB of RAM vs VS Code's 900MB, and has very noticeable latency when navigating the code and typing.

But like you said, it's pre-alpha, and I hope this project succeeds. I'm sure these issues are solvable. It's exciting to see Rust-based non-web UI libraries finally starting to become usable for reasonably complex apps.

Lapce cannot use that much of memory, it's most likely that Rust Analyzer has allocated majority of it.

My VS Code instance is also using Rust Analyzer.

Edit: I just disabled RA in both editors and restarted them. VSCode is now at 320MB and Lapce is at 770MB.

Edit 2: To be clear, my above comments are meant in the spirit of an informal bug report/feedback. I get that Lapce is a labor of love for its core developers, and I'm not shitting on it. In fact I think it's pretty impressive. I'm keeping an eye on it as something to potentially switch to once it matures a bit.

Portable version loaded instantly for me on Windows 10. Remote SSH functionality doesn't work at all unfortunately[1]. Would be nice to try out but I don't do any local dev.

1: https://github.com/lapce/lapce/issues/2985

Correction: Remote SSH works fine, we haven't reimplemented the remote file picker in new GUI toolkit but that can be workarounded by using `lapce` CLI and built-in terminal.

Cool - that works.

How is a project with 30,000 GH stars a pre-alpha stage project?

Probably because it says in Rust. In Rust we trust.

It doesn't work but it's memory safe in being non-functional

It boggles the mind. Good for the team building this, lots of respect entering this crowded and race to the bottom pricing product. But I don’t get how this differs from vs code or why someone would be excited about it. I get the feeling people like trying new editors so they throw stars around for every ide project they come across.

None of the features advertised beat neovim nor does it have the crazy plugin ecosystem.

People like their editor to be fast, work on more platforms, be open source, not being tied to Microsoft, etc.

Plenty of reasons why someone would choose Lapce over VS Code.

Be a team of 3-4 people working in their spare time to maintain cross-platform native GUI FOSS project that people seem to like

You can buy stars

No opinions on the editor itself yet, but just wanted to chime in here to say that I didn't have any such issues on Windows 10.

There are plenty of issues like this in Lapce (no support beyond qwerty layout for instance). Just go for Zed instead.

https://github.com/lapce/lapce/issues/945#issuecomment-12853...

Isn't keyboard layout a function of the operating system? How is a usermode application supposed to support (or not support) different keyboard layouts?

How are they going to run Zed on Windows?

For an editor whose differentiating factor appears to be "written in Rust", having a first-time user experience of crashing/hanging is unfortunate.

On Ubuntu for me on my laptop, it opens, then I try to drag the top status area and it sort of hides under the icon bar at the left part of the screen. Then I try to click on it again and it is completely hidden. The icon is still there though.

Opened in macOS and it appears impossible to open a folder of any sort. I type the folder path into the Open Folder thing at the top and it just silently fails.

There's no menu or anything to open a folder either. This seems lacking some _basic_ UX principles that should never be overlooked.

I did eventually figure it out and the TS integration doesn't work at all. The file browser icons constantly and consistently do not render correctly.

Guess this is something to check back in on in a year or three. It's a long way away from being complete, let alone usable.

> Opened in macOS and it appears impossible to open a folder of any sort. I type the folder path into the Open Folder thing at the top and it just silently fails.

That sounds like it could be Lapce failing to handle macOS full disk/folder security permissions (which you can grant in the System Preferences app)

I still don't understand how Zed or Lapse can build a viable business out of an OSS editor but at the same time there is an OSS VC funded Python linter so it's probably me.

getting acquired by a big tech who wants to catch up with Microsoft's dominance in developer tools is one possible out

As far as I know Lapce is not business.

Absolutely, they won't even accept donations.

I'm not sure what the selling point is, not criticizing the product, but as an emacs user of some odd ten years, I feel like as soon as I open the page I should see _something_ that would entice me to switch.

“All the features of vs code but ‘fast’” even though as you’ll read in this thread, people are highly questioning that assertion.

Doesn't appear to support UI scaling on Linux :(

They rewrote the UI recently in their own toolkit, Floem [^1], and that broke all scaling under X11 for me (now the UI and fonts are rendered so large that it's unusable). It works fine in Wayland though...

Here's some issues that were filed for this same problem:

  - https://github.com/lapce/lapce/issues/2732
  - https://github.com/lapce/lapce/issues/2773
  - https://github.com/lapce/lapce/issues/2737

[^1]: https://github.com/lapce/floem

Lapce: Fast and Powerful Code Editor Written in Rust - https://news.ycombinator.com/item?id=38796524 - Dec 2023 (63 comments)

Lapce Editor 0.3 - https://news.ycombinator.com/item?id=38262775 - Nov 2023 (98 comments)

Lapce – A code editor with LSP and DAP support - https://news.ycombinator.com/item?id=38100570 - Nov 2023 (2 comments)

Lapce Editor, Release v0.2.0 - https://news.ycombinator.com/item?id=32714191 - Sept 2022 (40 comments)

Lapce – Fast open-source code editor - https://news.ycombinator.com/item?id=30708505 - March 2022 (224 comments)

Show HN: Lapce – open-source code editor inspired by Xi-editor - https://news.ycombinator.com/item?id=30526693 - March 2022 (2 comments)

Lapce – Fast and Powerful Code Editor written in Rust - https://news.ycombinator.com/item?id=29549173 - Dec 2021 (145 comments)

Find a way to port plugins from VSC and I'm in!

That will take a long time because plugins [1][2] are written in Rust too, e.g. Go LSP plugin [3][4].

[1] https://plugins.lapce.dev

[2] https://github.com/lapce-community

[3] https://plugins.lapce.dev/plugins/panekj/lapce-go

[4] https://github.com/lapce-community/lapce-go/blob/volt/src/ma...

I think VSCode is also moving in the direction of wasi extensions[0], including for its serverside extensions host[1]. So there's a chance we get some of that for free.

[0]: https://code.visualstudio.com/blogs/2023/06/05/vscode-wasm-w...

[1]:https://github.com/microsoft/vscode-wasm

That's exciting. While I have some minor gripes about VSCode, it is fine enough. What gets me worried is the plugin ecosystem continually becomes a selling point in which no other editor can compete. I want other editors to be built and have a chance to thrive, but it becomes impossible if all of the good development tools get locked to one program.

From the landing page:

"You can write a plugin for Lapce with any programing language that compiles to WASI."

We're not going to support VSCode extensions, it's not viable for us and would require to bring VSC/NodeJS runtime everywhere Lapce needs to run

As long as it supports C and Ruby, I'm happy.

I’m a big fan of this project. A native, GUI, fast code editor is a welcome change from what VSC does to my laptop’s battery. Unfortunately, I have to step away from it while I figure out a potential data corruption issue. While editing a complex config file in lapce yesterday, I reopened it later to find all KINDS of errors—dozens of deleted, moved, and changed lines. I haven’t pinned it on lapce and it may well end up being something else, but it’s the primary suspect at the moment unfortunately. But to be crystal clear: if the problem is with lapce, that’s on me for using early stage software with a real document. It’s a great project and I don’t blame the software at all for my choice! (Just … ymmv at this stage.)

I have my CapsLock key remapped to Escape with `setxbkmap` and yet it's not recognized in the modal editing mode (I have to actually press Escape) - anyone else experiencing that?

On Manjaro I opened it and it stuttered for a bit and then crashed my entire desktop to a TTY. I get that it's pre-alpha but I was not expecting it to be that unstable.

To be honest, if an application manages to crash your whole Window Manager, I don't think it's the fault of the application

That's fair. On the other hand, I've been using KDE for over ten years and never had another application crash the entire thing.

How easy it is to underestimate the effort needed to compete with the status quo.

There would be no sane individuals to try to siege it if this was evident for everyone though!

I remember the old days of using tinyIRC which boasted that it was hand-written in assembly. And indeed, it was great to use. But there’s nothing really notable about any of this today when so many editors are flexing speed. Two weeks can’t go by without a new editor coming out. I’m still on VS Code after ST shit the bed.

I could use a decent Rust IDE. I can't believe I'm saying this, but the VSCode plugin for Rust seems to be the best there is at the moment, way better than the JetBrains plugin. This cannot be the last word on that.

Ultimately, for Rust all you really need is an editor with good LSP support. rust-analyzer offers a lot of what you could want out of an IDE (although when trying RustRover I noticed some other nice things such as the ability to 'factor out' a function from a selection, which I don't think I was able to do with RA).

Which editor that is doesn't really matter. VSCode is probably easiest, but Neovim, Kate, LiteXL, Lapce, Emacs, kakoune, helix, really pretty much all of them should work decently well.

Please improve the UI before adding all the features of VSCODE but better :-) On a positive note, just to be sure I tried to run Eclipse - its UI is much worse. HN: please suggest open source code editor with great UI for MacOS.

I'd give this a try if I could find some way to configure it to wrap long lines.

By "wrap long lines", I mean that I will never see a horizontal scroll bar even if there is a very long line of text in the buffer.

The nightly builds got word wrap a few weeks ago, not been released yet afaik, but will be in the next one.

Thank you for letting me know! I will definitely be giving it a try!

Can it wrap at column 80 or does it only wrap at the right border of the window?

Apparently, currently based on width: https://github.com/lapce/lapce/commit/87e0fc06f1862d9124d3fe...

Looks like it doesn’t support Lisp languages?

I like the idea of natively compiled editors - fast!

For two days, I have been using the Lem editor written in Common Lisp, super fast and responsive.

What’s the benefit for a neovim user? Meaning I already got LSP, treesitter, it works in a terminal. I cannot think of a reason to even try this.

With neovim you're still dependent on plugins written in some scripting language, and their overhead can add up. Lapce plugins are compiled to WASM/WASI, so they should run a bit smoother.

Lua is not some random scripting language, it is designed for embedding and is very fast with minimal overhead. I'm not saying that using WAS* is bad but bashing Neovim when it uses the one of the best proven technologies for extension is just silly.

My point of view as well. Once you learned how to configure Neovim with all the features you need, there's no better IDE out there (except IntelliJ for Java), because none is as customized to your personal needs and preferences. The challenge is the getting there, but why should one leave it?

Given that the plugins are written in Rust, how does it dynamically load/use them? Is there a good description?

The plugins use WebAssembly.

It consume 2GB of memory to load a typescript codebase. VSC just need 600MB of memory to load the same codebase.

haha linkin park logo

No... It's 30 degrees different.

The reason I am sticking with cursor.so is the AI. It is convenient to be able to a) let AI read whole files b) feed in direct documentation of a certain package to have proper context.

Might not be worth to expert coders out here but definitely saves a lot of time for me debugging or onboarding into a new framework

Wish Lapce had that. Also Zed does not have the quite depth for AI compared to Cursor

Why not just use basically any editor with codeium.com?

You can use codeium with cursor.so as it is a fork of VSCode.

does cursor.so allow use of local llms?

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.

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.

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.

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

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!

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

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

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

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.

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

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

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.

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

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

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.

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.

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).

> 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.

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.

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.

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!

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

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

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!

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 :)

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.

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?

> 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.

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.

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

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

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.

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...

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)

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.

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

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).

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.

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

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

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.

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?

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

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.

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...

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.

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

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.

What are you waiting two minutes to do?

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

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

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.

> 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?

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.

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.

> 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.

> 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

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.

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.

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.

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.

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.

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.

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

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

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

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.

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).

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.

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.

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.

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?

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

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.

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

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.

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?

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.

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.

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

Emacs is not known for being particularly fast.

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

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.

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

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.

Just a bunch of people optimizing for the wrong thing.

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

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

I like lapce. Its simple and easy to use. Ive switched to using the terminal for now but I do like using it from time to time.

its also kind of hilarious to watch people be like "why would we need another editor" and then turn around and POG at Zed lmao

wow, a code editor

Who knew that the existential crisis of the modern developer would be choosing between milliseconds of latency and the perfect shade of syntax highlighting :)

Might be some ocd type of stuff or just people being different, but yeah those milliseconds of latency absolutely do get in my nerves.

No thanks, I don't want fake open-source apps anymore.

Some fake open-source software that are actually in it for the money:

- Langchain (and most "open-source" LLM software)

- Zed

Can you elaborate on how this is "fake" open-source?

Warp terminal comes to mind as well. But I believe they are just plain closed-source. What makes these projects fake open-source?

Huh? Both this and Zed are fully open source and licensed under a FOSS license

> actually in it for the money

Neither "open source" nor "free software" have anything to do with being non-profit and not trying to make money

In fact, GNU directly says this: "Actually, we encourage people who redistribute free software to charge as much as they wish or can." [1]

And that's GNU. Which is FSF - the most obnoxious open-source absolutists you'll ever find. And even they don't discourage for-profit open-source.

[1]: https://www.gnu.org/philosophy/selling.en.html

Reply on news.ycombinator.com