Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lapce

lapce.dev

Post reply on HN
Print view View original

141–150 of 229 posts

Re: Lapce

#141

Post by arghwhat »

akdjidensb wrote: post #123
arghwhat wrote: post #99

Earlier quoted context omitted.

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 f…

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 compu…

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

Re: Lapce

#142

Post by zozbot234 »

lchen_hn wrote: post #85

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.

Re: Lapce

#143

Post by bemusedthrow75 »

oorza wrote: post #50

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 d…

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

Re: Lapce

#144

Post by saurik »

dleink wrote: post #107
mafuyu wrote: post #38

Earlier quoted context omitted.

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 bet…

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.

Re: Lapce

#145

Post by dzhou121 »

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

Re: Lapce

#146

Post by fbdab103 »

boomskats wrote: post #20
guessmyname wrote: post #12

Earlier quoted context omitted.

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.

Re: Lapce

#147

Post by moritzwarhier »

lrhegeba wrote: post #108
nox101 wrote: post #102

Earlier quoted context omitted.

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.

Re: Lapce

#148

Post by nicoburns »

alluro2 wrote: post #3

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!

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.

Re: Lapce

#149

Post by sebastiennight »

nox101 wrote: post #134
robin_reala wrote: post #120

Earlier quoted context omitted.

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.

Re: Lapce

#150

Post by buzzerbetrayed »

Swizec wrote: post #111
SCdF wrote: post #93

Earlier 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…

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

Post reply on HN