Live data from Hacker News

Lapce – Fast and Powerful Code Editor written in Rust

github.com

131–140 of 152 posts

Re: Lapce – Fast and Powerful Code Editor written in Rust

#132
post #30

Earlier quoted context omitted.

Jetbrains is trying to catch up on this, and in some cases has.

If I escape vscode I'd rather it be to something lighter rather than heavier. I used sublime before vscode and I'm tired of my editor using up half my ram.

I'm pretty happy with spacemacs with lsp-ccls for c++ development now. vscode had all kinds of weird bugs with its intellisense for me but lsp-ccls has been working great.

Re: Lapce – Fast and Powerful Code Editor written in Rust

#133
post #119

Earlier quoted context omitted.

Not FOSS. For many, that's an issue. Personally, I just don't feel comfortable working with sensitive information or proto-executables in closed-source software. I get the appeal, if you come from macOS or Windows, but for Linux it's often the first "dirty" thing you would introduce, so it feels like a big deal. Btw. I have used Sublime. It is a very nice Editor. Most importantly incredibly snappy and so far no other…

> Oh, yeah, and it's fucking expensive... ~80 USD per user (not per computer, per user), and then you have support for that version the X upcoming years. I understand 80 USD is a lot of money for some people, but I would argue for businesses it isn't and it isn't if you compare it to other stuff. Which requires subscription, or lets you pay with your data / advertising. Even if FOSS, that's arguably worse . (I use Su…

Eh, 80 dollars is pretty expensive yeah, but I bought my Sublime Text 3 beta license like 6 years ago while I was a student. I had like 200$ to my name back then and felt like it was worth it despite not even adding anything to my experience other than removing the "please activate sublime" popup.

I have access to Sublime Text 3, and even to the Sublime Text 4 beta.

I also pay the yearly Jetbrains full-suite subscription.

Re: Lapce – Fast and Powerful Code Editor written in Rust

#134
post #95

Earlier quoted context omitted.

The fact that it makes you think about it all the time, rather than using a garbage collector?

That wouldn't be a fix, it would be a regression.

In an editor? This isn't a real time OS.

Re: Lapce – Fast and Powerful Code Editor written in Rust

#135

Earlier quoted context omitted.

Either the plugin needs to be written in a common language (JS for VSCode, Python for Sublime Text) or native (Terraform does this for custom providers) but need to support many architectures. WASI fits snuggly in between, being a common intermediate language

But JS _is_ a common intermediate Language. I guess more languages compile to JS than to WASM.

WASM actually started life as a subset of Javascript called asm.js. Code in other languages was compiled to this subset of Javascript so they could execute in the browser. Once that proved useful, they decided to skip the Javascript step and agree on a binary format that browsers could execute directly. That's WASM.

From https://en.wikipedia.org/wiki/Asm.js

> asm.js consists of a strict subset of JavaScript, to which code written in statically-typed languages with manual memory management (such as C) is translated by a source-to-source compiler such as Emscripten (based on LLVM).[2] Performance is improved by limiting language features to those amenable to ahead-of-time optimization and other performance improvements.

> asm.js is mostly rendered obsolete with the introduction of WebAssembly (wasm), which has a bytecode format that is faster to parse. Efforts to extend JavaScript with more low-level features like SIMD.js has also been suspended since 2017. asm.js remains useful primarily as a "fallback" for wasm

Re: Lapce – Fast and Powerful Code Editor written in Rust

#136

Earlier quoted context omitted.

I think above comment is about jetBrains fleet. VSCode alternative written in kotlin

I have yet to use a JVM based GUI that felt snappy. JVM based language benchmarks are always really good, but somehow that never translates well to GUIs

There is a culture of gaslighting about it (JVM and similar); point out that you observe something being slow and it will be dismissed with "first, run the code several times to warm up the JIT, then carefully select the points where you time to make it look faster". For example this "Dijkstra path finding in C# is 15x slower than C++ version"[1], the question says "the C# algorithm takes 38ms to find a path. The C++ version takes just 2ms" and the accepted and much upvoted answer begins "First of all, you should run the FindPath method a couple of times before measuring, to give the C# runtime a chance to optimize the code. [...] Doing this gets the time down to about 17ms on my machine (from 38ms initially)."

So maybe if you want a keypress that responds quickly you should press that key a few times, wait for the editor to respond, delete it, then press it again and you'll see how fast it really is. Seems to me this is tied in with the "lightning fast" claims here and the sneering dismissals in the comments "that doesn't mean ANYTHING"; it's a secret message which means "not heavyweight laggy Java". It's the Python-to-Java's-boilerplate, the Agile-to-Big-Design-Up-Front, the Go-single-binary-to-Python-virtualenv, a calling card rather than a specific performance claim.

[1] https://codereview.stackexchange.com/questions/152733/dijkst... (the answer is otherwise very detailed and interesting)

Re: Lapce – Fast and Powerful Code Editor written in Rust

#138

You can also check out Helix (Kakoune-inspired, written in Rust, built-in LSP, terminal editor). https://helix-editor.com/ There's also Amp (Vim inspired, written in Rust) although it looks as though development has stopped https://amp.rs/

What makes you say that the development of Amp has stopped? There doesn't seem to have been a release since Feb 2020, but last push to main was 17 days ago.

Re: Lapce – Fast and Powerful Code Editor written in Rust

#140
https://github.com/lapce/lapce/blob/master/docs/why-lapce.md strikes me as really nice -- the author tried really hard, with lots of code to show for it, to get what they wanted from vim, then neovim, then xi, and only after thoroughly understanding the tradeoffs each made embarked on creating their own editor.
Post reply on HN