6 ms·

Lapce: Fast and Powerful Code Editor Written in Rust

50 points by snprajwal 3y ago

dave4420 3y ago
Written in Rust and yet when I downloaded it — admittedly a few months ago now — it segfaulted within a minute of me opening it for the first time. 0/10, not inclined to try again.
- brabel 3y ago
  People who think the programming language magically makes bugs disappear don't know what they're talking about. Yes, Rust makes a few categories of bugs disappear, but there's a vast number of bugs that you can still easily create even using Rust with all linters you can find enabled... just saw on another thread someone complaining a Gemini (poor man's internet) server responded with a Rust panic coming from an `unwrap()` call :D
  - ParetoOptimal 3y ago
    > People who think the programming language magically makes bugs disappear don't know what they're talking about. Yes, Rust makes a few categories of bugs disappear, I think few categories undersells it. Just having Optional/Maybe in a language legitimately does make bugs disappear.
  - lumost 3y ago
    Hot Take: Rust Panic's are about as bad as Sig11s from the C world. I don't get good debug information in the typical case - and library authors get to decide when my program crashes (which I disagree with).
    - frfl 3y ago
      Definitely a "hot take".
    - threatofrain 3y ago
      On a tangent — for a numeric library, would you rather NaN or throw? I find a fair amount of division over this question, but people lean towards throw over NaN.
      - truculent 3y ago
        If the operation can fail, that should really be represented in the type, right?
        zokier 3y ago
        One of my random thoughts is that floats could be represented as enums in type system, e.g. in rust-like syntax: #[repr(f32)] enum Float32 { PositiveInfinity, NegativeInfinity, Nan(NanPayload32), Finite(FiniteFloat32), } You could also then define NonNanFloat32 etc which could be used for certain operations. Of course on machine level its all the same
        truculent 3y ago
        Yeah, I think something like this would make sense. I get why people might not like it, but this is what we’re dealing with whether we like it or not.
        brabel 3y ago
        No necessarily. Rust doesn't do that for array indexing (though bound checking is enabled at runtime and will panic if out of bounds), division by zero, numeric overflow and probably many cases where it was deemed to be just too cumbersome.
        truculent 3y ago
        True, but iirc Rust also supplies a `get` method for when you want to get elements safely.
      - pocketarc 3y ago
    - ben0x539 3y ago
      You're not supposed to be afraid of segfaults, you're supposed to be afraid of the incorrect memory accesses that don't get caught by segfaults.
      - corethree 3y ago
        Yeah, the problem is when one of these faults comes from a 3rd party library and doesn't include stack trace info.
  - foolswisdom 3y ago
    Well if you're not using unsafe, you would expect zero segfaults when using rust, no? Though I imagine it's impossible for anything with graphics to avoid unsafe code entirely.
    - omnicognate 3y ago
      > Yes, Rust makes a few categories of bugs disappear, but Segfaults are only one of many ways for software to go wrong.
      - arghwhat 3y ago
        And all software that interfaces with... Well, anything, contains unsafe code.
      - KMag 3y ago
        The GP and GGGP were specifically talking about segfaults. The GP is reminding the GGP that the complaint is specifically about segfaults.
  - n8henrie 3y ago
    Certainly not all bugs, but in theory a segfault should be entirely avoided in safe rust, right?
    - vlovich123 3y ago
      Segfaults in safe rust cannot happen modulo compiler bugs. A true segfault (vs panic) would require unsafe Rust somewhere. But there’s bound to be unsafe code somewhere in a complex enough project.
      - n8henrie 3y ago
        Outside of FFI, is that mostly just for performance optimization? EDIT: IOW, why don't projects just eschew unsafe in order to truly leverage one of Rust's primary claims to fame?
        vlovich123 3y ago
        FFI, performance, ownership that’s impossible to express statically, 3p dependencies, direct OS calls or HW management that aren't available with safe wrappers etc. Sticking to safe rust is an ideal and it should be a goal but the primary use is to accomplish a task. If safe rust is getting in the way and there’s no way to do it easily otherwise, don’t feel bad about unsafe. The amount of unsafe should be minimized of course which reduces the surface area of issues greatly compared with c/C++ where every line is unsafe. Practical code is always >> ideological purity.
  - dave4420 3y ago
    If the makers of a software program make a big deal about the implementation language (in Lapce’s case, they mention it in the first paragraph), then I take that as a statement that they’ve taken advantage about that language’s unique features to deliver better software. In Rust’s case, I take it as a promise not to do anything memory-unsafe. Lapce did not keep this promise when I tried it.
- 3836293648 3y ago
  Did it crash or actually segfault? Segfaults shouldn't happen in Rust, but there is widespread use of `.unwrap`
  - dave4420 3y ago
    My memory is that it segfaulted, but this was months ago, so who knows?
tamimio 3y ago
I don’t see a debian package.
- flohofwoe 3y ago
  The list of available Linux packages seems to be here: https://github.com/lapce/lapce/blob/master/docs/installing-with-package-manager.md https://github.com/lapce/lapce/blob/master/docs/installing-w...
thefaux 3y ago
What exactly does lightning fast mean? Is vim not lightning fast?
- code-blooded 3y ago
  To be devil's advocate (despite being a long vim user): Lapce has a GUI, so they are not in the exact same category. Having lightening fast GUI is still a novelty, because the most popular IDEs like VSCode or JetBrains IDEs have slow downs from time to time.
  - corethree 3y ago
    It's not the GUI itself. A console application in a window is still a gui rendering console text. It's the fact that Vscode and jetbrains use a high level language/engine that makes it slow. For jetbrains it's java and for vscode it's an html rendering engine. An IDE built from vulkan or some other low level graphics API can likely be even faster then vim depending on the console it's running within.
  - hnlmorg 3y ago
    The IDE is only going to be as fast as the slowest LSP service you’re using.
    - schemescape 3y ago
      I would assume that LSPs are queried asynchronously. That's at least how it appears in VS Code.
      - hnlmorg 3y ago
        Asynchronous code doesn’t make something fast. It just prevents the application hanging when waiting for a function to return. But if that function is user facing (eg values for a context menu) and is slow, then your application is still going to feel slow in spite of those functions be asynchronous. Coincidentally this is actually a problem I faced when writing my alternative shell.
KolmogorovComp 3y ago
I don’t care in which language my editor is written in. From the user perspective, what sets it apart from the plethora of available and more mature editors?
- ParetoOptimal 3y ago
  > I don’t care in which language my editor is written in. Sure you do. If I offered you a version of your current editor in the Befunge programming language, you'd rightly decline! Programming languages aren't just all "basically the same". Programming language choice, communicates something because programming languages have values. Would you prefer a text editor written in Ruby or one written in Python? This relates to a favorite article of mine: It's not what programming languages do, it's what they shepherd you to. https://nibblestew.blogspot.com/2020/03/its-not-what-programming-languages-do.html https://nibblestew.blogspot.com/2020/03/its-not-what-program... To tie in one of the article's examples: > Perl shepherds you into using regexps If you believe that regexes are hard to debug and overly complex, you might resist a text editor written in perl because it's likely that regexes are used everywhere (even when they shouldn't be).
- ithkuil 3y ago
  I agree with your sentiment. That said, I can totally see why it would matter to some people why language something is written in: you may want to study or contribute to an editor and you may prefer to focus on your preferred language
  - n8henrie 3y ago
    Exactly. I keep wanting to fall in love with Lapce or Helix because I'm very interested in Rust and like the idea of an editor that I could contribute to, but my (neo)vim muscle memory is just too strong, even minor differences drive me nuts.
- orangea 3y ago
  - Truly open source, presumably without the caveats that VS Code has such as a few "features" (extensions) being closed source and the extension marketplace being closed to de-microsofted builds - Designed from the beginning to support an extension API with a richness comparable to VS Code's (unlike Sublime, Jetbrains etc) - Presumably aiming to put performance as a higher priority than is usual
corethree 3y ago
>VSCode Remote Development VSCode does this feature the best. No other IDE comes close. I'm a jetbrains guy and I would've given up on vscode completely if it were not for this feature. This thing is extremely important for embedded systems and development on the edge and only vscode really does it well enough to be useable. Glad to see Lapce has it to. Going to try it out.
- ParetoOptimal 3y ago
  > VSCode does this feature the best. No other IDE comes close. I'm a jetbrains guy and I would've given up on vscode completely if it were not for this feature. It is really good, I'm sure a lot of people feel like they have to use VSCode because of it. How convenient it's not open source huh?
ingenieroariel 3y ago
I tried it last month and loved having Alacritty there. It built easily and ran well on both OSX and Fedora Asahi Linux. That said, it does not seem yet ready to be a daily driver, small rough edges in the terminal behavior or the editor when using Vim mode were too distracting to do a long programming session. Kudos to the authors, looking forward to giving it a spin again the future.
dang 3y ago
Related: Lapce Editor 0.3 - https://news.ycombinator.com/item?id=38262775 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 https://news.ycombinator.com/item?id=38100570 - Nov 2023 (2 comments) Lapce Editor, Release v0.2.0 - https://news.ycombinator.com/item?id=32714191 https://news.ycombinator.com/item?id=32714191 - Sept 2022 (40 comments) Lapce – Fast open-source code editor - https://news.ycombinator.com/item?id=30708505 https://news.ycombinator.com/item?id=30708505 - March 2022 (224 comments) Lapce – Fast and Powerful Code Editor written in Rust - https://news.ycombinator.com/item?id=29549173 https://news.ycombinator.com/item?id=29549173 - Dec 2021 (145 comments)
godisdad 3y ago
Glad Zed has competition and validation of the approach
brundolf 3y ago
Screenshots look nice and feature list looks impressive, curious to hear anecdotes about real-world practicality
nocsi 3y ago
I’ve been soul searching for a new editor for about 2 years now. This checks the box for being native, modal/vim. So I’d probably adopt this like I did with alacrity when I dumped iterm.
sspiff 3y ago
I love Rust, but I don't really care what language my editor is built in. That said, I'll give this a shot because: - no funky telemetry - the stack used (wgpu etc) means this might be sufficiently low level to be much more resource efficient than alternatives - it sounds like the plugin architecture will allow for a vibrant extension ecosystem if this gets some adoption

50 points by snprajwal 3y ago

Written in Rust and yet when I downloaded it — admittedly a few months ago now — it segfaulted within a minute of me opening it for the first time. 0/10, not inclined to try again.

brabel 3y ago
People who think the programming language magically makes bugs disappear don't know what they're talking about. Yes, Rust makes a few categories of bugs disappear, but there's a vast number of bugs that you can still easily create even using Rust with all linters you can find enabled... just saw on another thread someone complaining a Gemini (poor man's internet) server responded with a Rust panic coming from an `unwrap()` call :D
- ParetoOptimal 3y ago
  > People who think the programming language magically makes bugs disappear don't know what they're talking about. Yes, Rust makes a few categories of bugs disappear, I think few categories undersells it. Just having Optional/Maybe in a language legitimately does make bugs disappear.
- lumost 3y ago
  Hot Take: Rust Panic's are about as bad as Sig11s from the C world. I don't get good debug information in the typical case - and library authors get to decide when my program crashes (which I disagree with).
  - frfl 3y ago
    Definitely a "hot take".
  - threatofrain 3y ago
    On a tangent — for a numeric library, would you rather NaN or throw? I find a fair amount of division over this question, but people lean towards throw over NaN.
    - truculent 3y ago
      If the operation can fail, that should really be represented in the type, right?
      - zokier 3y ago
        One of my random thoughts is that floats could be represented as enums in type system, e.g. in rust-like syntax: #[repr(f32)] enum Float32 { PositiveInfinity, NegativeInfinity, Nan(NanPayload32), Finite(FiniteFloat32), } You could also then define NonNanFloat32 etc which could be used for certain operations. Of course on machine level its all the same
        truculent 3y ago
        Yeah, I think something like this would make sense. I get why people might not like it, but this is what we’re dealing with whether we like it or not.
      - brabel 3y ago
        No necessarily. Rust doesn't do that for array indexing (though bound checking is enabled at runtime and will panic if out of bounds), division by zero, numeric overflow and probably many cases where it was deemed to be just too cumbersome.
        truculent 3y ago
        True, but iirc Rust also supplies a `get` method for when you want to get elements safely.
    - pocketarc 3y ago
  - ben0x539 3y ago
    You're not supposed to be afraid of segfaults, you're supposed to be afraid of the incorrect memory accesses that don't get caught by segfaults.
    - corethree 3y ago
      Yeah, the problem is when one of these faults comes from a 3rd party library and doesn't include stack trace info.
- foolswisdom 3y ago
  Well if you're not using unsafe, you would expect zero segfaults when using rust, no? Though I imagine it's impossible for anything with graphics to avoid unsafe code entirely.
  - omnicognate 3y ago
    > Yes, Rust makes a few categories of bugs disappear, but Segfaults are only one of many ways for software to go wrong.
    - arghwhat 3y ago
      And all software that interfaces with... Well, anything, contains unsafe code.
    - KMag 3y ago
      The GP and GGGP were specifically talking about segfaults. The GP is reminding the GGP that the complaint is specifically about segfaults.
- n8henrie 3y ago
  Certainly not all bugs, but in theory a segfault should be entirely avoided in safe rust, right?
  - vlovich123 3y ago
    Segfaults in safe rust cannot happen modulo compiler bugs. A true segfault (vs panic) would require unsafe Rust somewhere. But there’s bound to be unsafe code somewhere in a complex enough project.
    - n8henrie 3y ago
      Outside of FFI, is that mostly just for performance optimization? EDIT: IOW, why don't projects just eschew unsafe in order to truly leverage one of Rust's primary claims to fame?
      - vlovich123 3y ago
        FFI, performance, ownership that’s impossible to express statically, 3p dependencies, direct OS calls or HW management that aren't available with safe wrappers etc. Sticking to safe rust is an ideal and it should be a goal but the primary use is to accomplish a task. If safe rust is getting in the way and there’s no way to do it easily otherwise, don’t feel bad about unsafe. The amount of unsafe should be minimized of course which reduces the surface area of issues greatly compared with c/C++ where every line is unsafe. Practical code is always >> ideological purity.
- dave4420 3y ago
  If the makers of a software program make a big deal about the implementation language (in Lapce’s case, they mention it in the first paragraph), then I take that as a statement that they’ve taken advantage about that language’s unique features to deliver better software. In Rust’s case, I take it as a promise not to do anything memory-unsafe. Lapce did not keep this promise when I tried it.
3836293648 3y ago
Did it crash or actually segfault? Segfaults shouldn't happen in Rust, but there is widespread use of `.unwrap`
- dave4420 3y ago
  My memory is that it segfaulted, but this was months ago, so who knows?

tamimio 3y ago

I don’t see a debian package.

flohofwoe 3y ago
The list of available Linux packages seems to be here: https://github.com/lapce/lapce/blob/master/docs/installing-with-package-manager.md https://github.com/lapce/lapce/blob/master/docs/installing-w...

thefaux 3y ago

What exactly does lightning fast mean? Is vim not lightning fast?

code-blooded 3y ago
To be devil's advocate (despite being a long vim user): Lapce has a GUI, so they are not in the exact same category. Having lightening fast GUI is still a novelty, because the most popular IDEs like VSCode or JetBrains IDEs have slow downs from time to time.
- corethree 3y ago
  It's not the GUI itself. A console application in a window is still a gui rendering console text. It's the fact that Vscode and jetbrains use a high level language/engine that makes it slow. For jetbrains it's java and for vscode it's an html rendering engine. An IDE built from vulkan or some other low level graphics API can likely be even faster then vim depending on the console it's running within.
- hnlmorg 3y ago
  The IDE is only going to be as fast as the slowest LSP service you’re using.
  - schemescape 3y ago
    I would assume that LSPs are queried asynchronously. That's at least how it appears in VS Code.
    - hnlmorg 3y ago
      Asynchronous code doesn’t make something fast. It just prevents the application hanging when waiting for a function to return. But if that function is user facing (eg values for a context menu) and is slow, then your application is still going to feel slow in spite of those functions be asynchronous. Coincidentally this is actually a problem I faced when writing my alternative shell.

KolmogorovComp 3y ago

I don’t care in which language my editor is written in. From the user perspective, what sets it apart from the plethora of available and more mature editors?

ParetoOptimal 3y ago
> I don’t care in which language my editor is written in. Sure you do. If I offered you a version of your current editor in the Befunge programming language, you'd rightly decline! Programming languages aren't just all "basically the same". Programming language choice, communicates something because programming languages have values. Would you prefer a text editor written in Ruby or one written in Python? This relates to a favorite article of mine: It's not what programming languages do, it's what they shepherd you to. https://nibblestew.blogspot.com/2020/03/its-not-what-programming-languages-do.html https://nibblestew.blogspot.com/2020/03/its-not-what-program... To tie in one of the article's examples: > Perl shepherds you into using regexps If you believe that regexes are hard to debug and overly complex, you might resist a text editor written in perl because it's likely that regexes are used everywhere (even when they shouldn't be).
ithkuil 3y ago
I agree with your sentiment. That said, I can totally see why it would matter to some people why language something is written in: you may want to study or contribute to an editor and you may prefer to focus on your preferred language
- n8henrie 3y ago
  Exactly. I keep wanting to fall in love with Lapce or Helix because I'm very interested in Rust and like the idea of an editor that I could contribute to, but my (neo)vim muscle memory is just too strong, even minor differences drive me nuts.
orangea 3y ago
- Truly open source, presumably without the caveats that VS Code has such as a few "features" (extensions) being closed source and the extension marketplace being closed to de-microsofted builds - Designed from the beginning to support an extension API with a richness comparable to VS Code's (unlike Sublime, Jetbrains etc) - Presumably aiming to put performance as a higher priority than is usual

corethree 3y ago

>VSCode Remote Development VSCode does this feature the best. No other IDE comes close. I'm a jetbrains guy and I would've given up on vscode completely if it were not for this feature. This thing is extremely important for embedded systems and development on the edge and only vscode really does it well enough to be useable. Glad to see Lapce has it to. Going to try it out.

ParetoOptimal 3y ago
> VSCode does this feature the best. No other IDE comes close. I'm a jetbrains guy and I would've given up on vscode completely if it were not for this feature. It is really good, I'm sure a lot of people feel like they have to use VSCode because of it. How convenient it's not open source huh?

ingenieroariel 3y ago

I tried it last month and loved having Alacritty there. It built easily and ran well on both OSX and Fedora Asahi Linux. That said, it does not seem yet ready to be a daily driver, small rough edges in the terminal behavior or the editor when using Vim mode were too distracting to do a long programming session. Kudos to the authors, looking forward to giving it a spin again the future.

dang 3y ago

Related: Lapce Editor 0.3 - https://news.ycombinator.com/item?id=38262775 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 https://news.ycombinator.com/item?id=38100570 - Nov 2023 (2 comments) Lapce Editor, Release v0.2.0 - https://news.ycombinator.com/item?id=32714191 https://news.ycombinator.com/item?id=32714191 - Sept 2022 (40 comments) Lapce – Fast open-source code editor - https://news.ycombinator.com/item?id=30708505 https://news.ycombinator.com/item?id=30708505 - March 2022 (224 comments) Lapce – Fast and Powerful Code Editor written in Rust - https://news.ycombinator.com/item?id=29549173 https://news.ycombinator.com/item?id=29549173 - Dec 2021 (145 comments)

godisdad 3y ago

Glad Zed has competition and validation of the approach

brundolf 3y ago

Screenshots look nice and feature list looks impressive, curious to hear anecdotes about real-world practicality

nocsi 3y ago

I’ve been soul searching for a new editor for about 2 years now. This checks the box for being native, modal/vim. So I’d probably adopt this like I did with alacrity when I dumped iterm.

sspiff 3y ago

I love Rust, but I don't really care what language my editor is built in. That said, I'll give this a shot because: - no funky telemetry - the stack used (wgpu etc) means this might be sufficiently low level to be much more resource efficient than alternatives - it sounds like the plugin architecture will allow for a vibrant extension ecosystem if this gets some adoption