Given that the plugins are written in Rust, how does it dynamically load/use them? Is there a good description?
Lapce
131–140 of 229 posts
Re: Lapce
#132Given that the plugins are written in Rust, how does it dynamically load/use them? Is there a good description?
The plugins use WebAssembly.
Re: Lapce
#133I 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.
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 ext…
I don't know about Lapce, but the plan for Zed is to have WASM extensions.
Re: Lapce
#134Earlier quoted context omitted.
i guess which and the number of extensions will have a significant effect on lag
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
Re: Lapce
#135Earlier quoted context omitted.
Not vim (by design) - but have you tried helix? https://helix-editor.com
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…
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...
Re: Lapce
#136I 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.
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.
Re: Lapce
#137I 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.
Re: Lapce
#138Earlier quoted context omitted.
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 obv…
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…
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).
Re: Lapce
#139I 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.
Re: Lapce
#140I 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.
> 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.