11 ms·

Lapce – Fast and Powerful Code Editor written in Rust

333 points by agluszak 5y ago

dzhou121 5y ago
Author here. I didn't expect this will go on Hacker News. Although the editor has been my daily drive for almost one year now, it's really rough on the edges. The plugin system as described in the README hasn't been implemented yet.
- thecleaner 5y ago
  Lsp support as well ? You have got to be kidding me. How did you add these feature so quickly ?
  - IshKebab 5y ago
    It probably doesn't have support for the full LSP, which is pretty huge. I imagine just the most useful things like completion and go-to-definition.
  - deleted 5y ago
    [deleted]
- DeathArrow 5y ago
  Why did you opt for WASI for plugins instead of native compiled code?
  - conradludgate 5y ago
    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
    - ReleaseCandidat 5y ago
      But JS _is_ a common intermediate Language. I guess more languages compile to JS than to WASM.
      - pbronez 5y ago
        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 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
      - UtherII 5y ago
        It can used as an intermediate language, and since it was the only way to run code on the browser without plugins before WASM, it happened a lot. But nowadays WASM is much more suitable for the job. JavaScript was designed as a scripting language, not a low level intermediary language.
  - stefs 5y ago
    not OP, but i think it makes sense. there isn't that much of a speed difference and you get free sandboxing, some memory safety, a ton of supported languages and more. i don't know anything about WASI, but it probably solves the problem of having to interface with different native compiled code ABIs.
  - dzhou121 5y ago
    I think native compiled code is hard for plugin distributions. You'll need to target 3 main platforms Linux/macOS/Windows. You can use github actions to do it, but it would be so easier to just compile to WASI and that's it. Also, WASI is compelling to me because of the potential of writing plugins in different programming languages.
    - DemocracyFTW 5y ago
      > WASI is compelling to me because of the potential of writing plugins in different programming languages I think this is the future really, I've been pining for this to become a thing for so long.
    - stavros 5y ago
      I think WASI is an excellent idea. Do you know how the ABI works?
    - froh 5y ago
      multiply that with the CPU ISA, like arm, x86 (and more if you are inclined to support power, sparc, ...)
  - the_duke 5y ago
    Webassembly makes a lot of sense for plugins. * sandboxing, so plugins don't need to be as trusted * Easy cross-platform distribution with a single build artifact * plenty fast (if written in a language like Rust/C++ and paired with a good runtime)
    - chrisjc 5y ago
      Apologies for lack of my lack of knowledge in this area, but... Why don't plugins "need to be as trusted"? Obviously bad-actor plugins would be less effective and capable of inflicting any sort of attack on your development OS, but surely the development environment is the perfect vector for attacking the runtime environments that run your artifacts get deployed into? Not to mention the potential for secrets-harvesting due to sloppy boot-strapping dev-env habits or other bad habits we often engage in during the early development process? Or does WASI somehow provide protection from these issues?
      - laumars 5y ago
        The clue is in the first part of the GPs sentence which you latched onto: “sandboxing”. The code is running inside a virtual machine rather than natively on the host.
        chrisjc 5y ago
        No, I got that. I understand how the host is protected, but didn't understand how everything inside the "VM" was protected... @galgalesh answers that above.
      - galgalesh 5y ago
        It's all about reduction of surface and giving plugins access to the least amount of info. You expect a linter to only have (read) access to the code it lints. It shouldn't be able to modify files, it shouldn't have network access etc. WASI has a pluggable capability-based security system. Some advanced linters might want network access but you can show this to the user, so they can make an informed decision about whether to trust that linter and their author with this power. This isn't airtight security to protect against obviously-malicious authors. This is about creating a system that can deal with the reality that "trust" in an app store entails "a million shades of gray". I might trust a plugin enough to check for errors in my code, but not enough to actually modify my code.
- syrusakbary 5y ago
  This is awesome! Looking forward the WebAssembly WASI integration :)
- alskdj21 5y ago
  Hey! I really appreciate the built-in modal editing and remote development support. It would be good if we can have linux builds.
- lnxg33k1 5y ago
  Edit: Alright nevermind just saw in the repo that the UI is in Druid, have a nice day and again thank you
  - deleted 5y ago
    [deleted]
  - jonpalmisc 5y ago
    Care to elaborate on what's wrong with Druid?
    - lnxg33k1 5y ago
      Nothing, I edited the message because in the first version of the comment I asked which UI framework they were using, then I saw that info contained in the README and said "ah okay it's using Druid" as in "I saw that" not in "Ah crap you're using Druid"
      - deleted 5y ago
        [deleted]
      - jonpalmisc 5y ago
        Ah, my bad — got thrown off by the original wording
- chespinoza 5y ago
  Hi, it looks nice! I really appreciate efforts like this, does it only supports Rust?
- spyremeown 5y ago
  Hi, thanks for writing some free software! I'm not a Rust person, how do you install this? Is it something like "rustc install" or something like that? Thanks!
  - abendstolz 5y ago
    There is cargo install, yes :) https://doc.rust-lang.org/cargo/commands/cargo-install.html https://doc.rust-lang.org/cargo/commands/cargo-install.html
    - spyremeown 5y ago
      Thank you!
- gsliepen 5y ago
  This looks very nice. However, the description mentions "lightning fast" and "powerful". Unfortunately, those things don't mean anything without further clarification. If you really want to show your editor is faster than other commonly used editors, consider posting a benchmark of cases where speed matters (like loading a large file, inserting in the middle of a large file, search/replace, latency of pressing a key and having the screen updated, and so on). It is harder to quantify "power" though.
  - DrBazza 5y ago
    Standard rust marketing, it's a bit tedious tbh, and I don't think anyone who is honest is surprised any more. Everything is "lightning fast" by default just because it compiles to native. I thought we were past that. Never mind that you can write crap code in any language (not making any comment about the editor's author here).
    - Aeolun 5y ago
      I still prefer crap lightning fast code to crap tediously slow code though. If the only thing people do is build a native application instead of a webapp and that speeds my stuff up by 80% then that'll make me very happy.
      - DrBazza 5y ago
        That reminds me of the (current) top-most comment in the `drgn` thread here: https://news.ycombinator.com/item?id=29537594 https://news.ycombinator.com/item?id=29537594 "just keep rebooting to solve the problem, rather than fix it"
      - Dylan16807 5y ago
        When "lightning fast" just means native, then it could very easily be slower than a webapp that uses a more fitting algorithm.
    - IshKebab 5y ago
      It's not just marketing. Rust tools like Tokei and Ripgrep are lightning fast. It's partly because it compiles to native - that applies to C/C++ too, e.g. Git is "lightning fast" compared to Mercurial. But it's also because Rust lets you do multi-threading without going insane.
- vmchale 5y ago
  Damn this is really cool - thanks!
yisonPylkita 5y ago
Looks promising. Always nice to see a movement to slim-down RAM and CPU usage of our tools. Will this editor allow me to run it with rust-analyzer code completion?
- carlmr 5y ago
  Rust-analyzer is an LSP Server, so it should be supported.
forgotmyoldacc 5y ago
The 0.0.1 release crashes on MacOS 12.0.1, would be nice to try it out when its more stable.
- darkblackcorner 5y ago
  Same here. Sounds interesting though - I'll keep an eye on it!
- sharikous 5y ago
  It crashes in Catalina too, unfortunately. I was looking forward to trying the build.
- karavelov 5y ago
  It crashes on Ubuntu 20.04 also with `memory allocation of 18446744073709551615 bytes failed`
- geniium 5y ago
  It seems to crash on windows and macos based on the issues in github.
  - geniium 5y ago
    Starting issues reported: Windows issue: https://github.com/lapce/lapce/issues/9 https://github.com/lapce/lapce/issues/9 macOS issue: https://github.com/lapce/lapce/issues/7 https://github.com/lapce/lapce/issues/7
- megapoliss 5y ago
  yep, it crashes on Archlinux as well Just wonder, what is the point of promoting something as "being written in Rust", if at the end it crushed the same way as "being written in C/C++/whatever".
  - afarrell 5y ago
    To attract contributors who want to learn more rust by collaborating on something they care about.
debdut 5y ago
VS Code is so bloated af Waiting for this to be stable! Would love to contribute! Any next features doc, so I can pick a topic and submit some PRs. Awesome work :)
- hdjrudni 5y ago
  Ya...it's going downhill :-( I liked it as a lightweight editor. Now it's just another IDE. But instead I have to sift through thousands of half-baked 3rd party plugins to get the functions I need. Editors/IDEs should do one thing or the either well.
  - Philip-J-Fry 5y ago
    >But instead I have to sift through thousands of half-baked 3rd party plugins to get the functions I need That's the entire point? The functions don't exist because it's supposed to be lightweight. If you're finding that you need 20+ plugins to add features then I've got news for you, you're looking for an IDE that has all these built in by default.
    - fileeditview 5y ago
      Not OP but.. I have certainly around 20 plugins in my Vim and it runs faster than Usain Bolt. I agree with your first point but the IDE argument is wrong. I could use 100 plugins and it still would not be an IDE nor would I want one.
    - coldtea 5y ago
      >* If you're finding that you need 20+ plugins to add features then I've got news for you, you're looking for an IDE that has all these built in by default.* I also have news for you, VS Code's whole selling point was "built-your-own-IDE" and big plugin ecosystem, not "here's yet another lightweight editor".
- throw_m239339 5y ago
  VS Code isn't bloated if you never install any extension. You can't hold Microsoft responsible for third party bloat.
DeathArrow 5y ago
This feels like fresh air compared to tons of tools written in Javascript and running in a browser.
- amelius 5y ago
  Seems like you have been picking the wrong tool for the job.
  - Hendrikto 5y ago
    Seems like Atom and VSCode picked the wrong tool for the job.
    - Lhiw 5y ago
      Could have told them that 10 years ago.
    - sofixa 5y ago
      Both work fairly well, are popular and performance is satisfactory (unless you try to paste an 80k line JSON file into either of them, that doesn't work). Considering their success, wide availability and vibrant ecosystems, I'd say they picked the right tool for the job.
      - timeon 5y ago
        Not sure if eating memory like complex 3d modeling software (with model in it) for something what is at the end of the day basically just text editing is the right tool for the job. Energy with excluded externalities is cheap. So modern personal computers can bear anything. But should they?
        zarzavat 5y ago
        It's a tradeoff. Because they are written using web technologies it means that they are very extensible. If you are a professional then just buy more RAM.
buster 5y ago
My first thought was, not yet another terminal editor written for fun, but when I read druid, lsp, wasi plug-ins... That sounds very intriguing!
- runiq 5y ago
  Yeah, this reads like my bucket list of Rust technologies if I ever decided I'd want to implement a text editor. Definitely going to try this out. Thank you for bringing this to our attention, OP!
stormbrew 5y ago
> Built in remote development support (inspired by VSCode Remote Development) Well... This has me intrigued. This is basically the only thing that keeps me on vscode.
- carlmr 5y ago
  Same, + remote containers.
- mikeyjk 5y ago
  Jetbrains is trying to catch up on this, and in some cases has.
  - stormbrew 5y ago
    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.
    - akmittal 5y ago
      I think above comment is about jetBrains fleet. VSCode alternative written in kotlin
      - lordofgibbons 5y ago
        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
        akmittal 5y ago
        They have made a custom UI framework based on skia rendering engine. Skia is used by flutter, Chrome and firefox for rendering and known for great performance. https://github.com/jetbrains/compose-jb https://github.com/jetbrains/compose-jb
        5y ago
jokoon 5y ago
No windows build?
- geniium 5y ago
  Yes but not sure it works for you
  - jokoon 5y ago
    what do you mean?
- trbn 5y ago
  https://github.com/lapce/lapce/releases/tag/v0.0.1 https://github.com/lapce/lapce/releases/tag/v0.0.1
Dave3of5 5y ago
The open folder command is unbound by default on windows. Is it meant to be like that ? I literally couldn't open any folder. Also on windows by default it leaves a separate command window hanging which seems odd. Why isn't this logging done within the app terminal itself.
chrysoprace 5y ago
Xi, the backend that it's built on, is unfortunately in maintenance mode and it seems like it has been for a while now.
- rapsey 5y ago
  Druid is also in a poor state at the moment (it pulls master from git) and it's not using wgpu at all. I assume it used to use a piet wgpu branch but it is not anymore.
  - runiq 5y ago
    Do you mean lapce pulls Druid from Git and isn't using wgpu right now, or do you mean Druid itself? I'm afraid I can't quite parse your comment.
  - dzhou121 5y ago
    It uses a heavily forked version of Druid. https://github.com/lapce/druid https://github.com/lapce/druid which replaces the window management to use winit instead https://github.com/rust-windowing/winit https://github.com/rust-windowing/winit and a self-written wgpu backend hooked with druid. https://github.com/lapce/piet-wgpu https://github.com/lapce/piet-wgpu For xi, it only uses it for text manipulation.
- panzerklein 5y ago
  According to readme it's not a Xi frontend, but rather it uses same algorithms for string manipulations
cassepipe 5y ago
You can also check out Helix (Kakoune-inspired, written in Rust, built-in LSP, terminal editor). https://helix-editor.com/ https://helix-editor.com/ There's also Amp (Vim inspired, written in Rust) although it looks as though development has stopped https://amp.rs/ https://amp.rs/
- chespinoza 5y ago
  Wow, I didn't know about those editors, they look awesome man, thanks for sharing.
- depressedpanda 5y ago
  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.
Ygg2 5y ago
Any option to sponsor? I'd like to contribute with money since my time is kinda devoured.
revskill 5y ago
Why always lightning, why not sound-speed ? As soon as memory management issue is solved, i could see all future software will eventually be written in Rust (or similar language)
- adwn 5y ago
  > As soon as memory management issue is solved [...] What does this refer to?
  - revskill 5y ago
    Rust memory management model ?
    - adwn 5y ago
      And what issue related to Rust's memory management is to be resolved?
      - rwmj 5y ago
        The fact that it makes you think about it all the time, rather than using a garbage collector?
        adwn 5y ago
        The lack of a GC is a pretty fundamental aspect of Rust's design, I don't see that changing in the foreseeable future. "As soon as memory management issue is solved" makes it sound like a small bug or missing feature that can be fixed with a little work.
        krageon 5y ago
        That wouldn't be a fix, it would be a regression.
        rwmj 5y ago
cortexio 5y ago
No plugins yet, so not for me. The way i navigate through my open files and code is quit unique but also important for me.
zokier 5y ago
As always, if something is advertised as "fast" (or especially lightning-fast), it would be really nice to see some performance characterizations to explain in what way it is fast. Otherwise it feels so very meaningless label that is so often slapped on things on very weak grounds. And just because the building blocks might individually be said to be fast, it doesn't automatically mean that the conglomerate of them is still fast; performance is a fickle thing.
schrute 5y ago
The product crashes on MacOS Catalina, Arch, Ubuntu and Win 10. Lightning fast indeed. /s
slowtec 5y ago
I would love to see that the community join forces and combine all the different projects: https://github.com/flosse/text-editors-written-in-rust https://github.com/flosse/text-editors-written-in-rust
mlinksva 5y ago
https://github.com/lapce/lapce/blob/master/docs/why-lapce.md 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.

333 points by agluszak 5y ago

Author here. I didn't expect this will go on Hacker News. Although the editor has been my daily drive for almost one year now, it's really rough on the edges. The plugin system as described in the README hasn't been implemented yet.

thecleaner 5y ago
Lsp support as well ? You have got to be kidding me. How did you add these feature so quickly ?
- IshKebab 5y ago
  It probably doesn't have support for the full LSP, which is pretty huge. I imagine just the most useful things like completion and go-to-definition.
- deleted 5y ago
  [deleted]
DeathArrow 5y ago
Why did you opt for WASI for plugins instead of native compiled code?
- conradludgate 5y ago
  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
  - ReleaseCandidat 5y ago
    But JS _is_ a common intermediate Language. I guess more languages compile to JS than to WASM.
    - pbronez 5y ago
      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 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
    - UtherII 5y ago
      It can used as an intermediate language, and since it was the only way to run code on the browser without plugins before WASM, it happened a lot. But nowadays WASM is much more suitable for the job. JavaScript was designed as a scripting language, not a low level intermediary language.
- stefs 5y ago
  not OP, but i think it makes sense. there isn't that much of a speed difference and you get free sandboxing, some memory safety, a ton of supported languages and more. i don't know anything about WASI, but it probably solves the problem of having to interface with different native compiled code ABIs.
- dzhou121 5y ago
  I think native compiled code is hard for plugin distributions. You'll need to target 3 main platforms Linux/macOS/Windows. You can use github actions to do it, but it would be so easier to just compile to WASI and that's it. Also, WASI is compelling to me because of the potential of writing plugins in different programming languages.
  - DemocracyFTW 5y ago
    > WASI is compelling to me because of the potential of writing plugins in different programming languages I think this is the future really, I've been pining for this to become a thing for so long.
  - stavros 5y ago
    I think WASI is an excellent idea. Do you know how the ABI works?
  - froh 5y ago
    multiply that with the CPU ISA, like arm, x86 (and more if you are inclined to support power, sparc, ...)
- the_duke 5y ago
  Webassembly makes a lot of sense for plugins. * sandboxing, so plugins don't need to be as trusted * Easy cross-platform distribution with a single build artifact * plenty fast (if written in a language like Rust/C++ and paired with a good runtime)
  - chrisjc 5y ago
    Apologies for lack of my lack of knowledge in this area, but... Why don't plugins "need to be as trusted"? Obviously bad-actor plugins would be less effective and capable of inflicting any sort of attack on your development OS, but surely the development environment is the perfect vector for attacking the runtime environments that run your artifacts get deployed into? Not to mention the potential for secrets-harvesting due to sloppy boot-strapping dev-env habits or other bad habits we often engage in during the early development process? Or does WASI somehow provide protection from these issues?
    - laumars 5y ago
      The clue is in the first part of the GPs sentence which you latched onto: “sandboxing”. The code is running inside a virtual machine rather than natively on the host.
      - chrisjc 5y ago
        No, I got that. I understand how the host is protected, but didn't understand how everything inside the "VM" was protected... @galgalesh answers that above.
    - galgalesh 5y ago
      It's all about reduction of surface and giving plugins access to the least amount of info. You expect a linter to only have (read) access to the code it lints. It shouldn't be able to modify files, it shouldn't have network access etc. WASI has a pluggable capability-based security system. Some advanced linters might want network access but you can show this to the user, so they can make an informed decision about whether to trust that linter and their author with this power. This isn't airtight security to protect against obviously-malicious authors. This is about creating a system that can deal with the reality that "trust" in an app store entails "a million shades of gray". I might trust a plugin enough to check for errors in my code, but not enough to actually modify my code.
syrusakbary 5y ago
This is awesome! Looking forward the WebAssembly WASI integration :)
alskdj21 5y ago
Hey! I really appreciate the built-in modal editing and remote development support. It would be good if we can have linux builds.
lnxg33k1 5y ago
Edit: Alright nevermind just saw in the repo that the UI is in Druid, have a nice day and again thank you
- deleted 5y ago
  [deleted]
- jonpalmisc 5y ago
  Care to elaborate on what's wrong with Druid?
  - lnxg33k1 5y ago
    Nothing, I edited the message because in the first version of the comment I asked which UI framework they were using, then I saw that info contained in the README and said "ah okay it's using Druid" as in "I saw that" not in "Ah crap you're using Druid"
    - deleted 5y ago
      [deleted]
    - jonpalmisc 5y ago
      Ah, my bad — got thrown off by the original wording
chespinoza 5y ago
Hi, it looks nice! I really appreciate efforts like this, does it only supports Rust?
spyremeown 5y ago
Hi, thanks for writing some free software! I'm not a Rust person, how do you install this? Is it something like "rustc install" or something like that? Thanks!
- abendstolz 5y ago
  There is cargo install, yes :) https://doc.rust-lang.org/cargo/commands/cargo-install.html https://doc.rust-lang.org/cargo/commands/cargo-install.html
  - spyremeown 5y ago
    Thank you!
gsliepen 5y ago
This looks very nice. However, the description mentions "lightning fast" and "powerful". Unfortunately, those things don't mean anything without further clarification. If you really want to show your editor is faster than other commonly used editors, consider posting a benchmark of cases where speed matters (like loading a large file, inserting in the middle of a large file, search/replace, latency of pressing a key and having the screen updated, and so on). It is harder to quantify "power" though.
- DrBazza 5y ago
  Standard rust marketing, it's a bit tedious tbh, and I don't think anyone who is honest is surprised any more. Everything is "lightning fast" by default just because it compiles to native. I thought we were past that. Never mind that you can write crap code in any language (not making any comment about the editor's author here).
  - Aeolun 5y ago
    I still prefer crap lightning fast code to crap tediously slow code though. If the only thing people do is build a native application instead of a webapp and that speeds my stuff up by 80% then that'll make me very happy.
    - DrBazza 5y ago
      That reminds me of the (current) top-most comment in the `drgn` thread here: https://news.ycombinator.com/item?id=29537594 https://news.ycombinator.com/item?id=29537594 "just keep rebooting to solve the problem, rather than fix it"
    - Dylan16807 5y ago
      When "lightning fast" just means native, then it could very easily be slower than a webapp that uses a more fitting algorithm.
  - IshKebab 5y ago
    It's not just marketing. Rust tools like Tokei and Ripgrep are lightning fast. It's partly because it compiles to native - that applies to C/C++ too, e.g. Git is "lightning fast" compared to Mercurial. But it's also because Rust lets you do multi-threading without going insane.
vmchale 5y ago
Damn this is really cool - thanks!

yisonPylkita 5y ago

Looks promising. Always nice to see a movement to slim-down RAM and CPU usage of our tools. Will this editor allow me to run it with rust-analyzer code completion?

carlmr 5y ago
Rust-analyzer is an LSP Server, so it should be supported.

forgotmyoldacc 5y ago

The 0.0.1 release crashes on MacOS 12.0.1, would be nice to try it out when its more stable.

darkblackcorner 5y ago
Same here. Sounds interesting though - I'll keep an eye on it!
sharikous 5y ago
It crashes in Catalina too, unfortunately. I was looking forward to trying the build.
karavelov 5y ago
It crashes on Ubuntu 20.04 also with `memory allocation of 18446744073709551615 bytes failed`
geniium 5y ago
It seems to crash on windows and macos based on the issues in github.
- geniium 5y ago
  Starting issues reported: Windows issue: https://github.com/lapce/lapce/issues/9 https://github.com/lapce/lapce/issues/9 macOS issue: https://github.com/lapce/lapce/issues/7 https://github.com/lapce/lapce/issues/7
megapoliss 5y ago
yep, it crashes on Archlinux as well Just wonder, what is the point of promoting something as "being written in Rust", if at the end it crushed the same way as "being written in C/C++/whatever".
- afarrell 5y ago
  To attract contributors who want to learn more rust by collaborating on something they care about.

debdut 5y ago

VS Code is so bloated af Waiting for this to be stable! Would love to contribute! Any next features doc, so I can pick a topic and submit some PRs. Awesome work :)

hdjrudni 5y ago
Ya...it's going downhill :-( I liked it as a lightweight editor. Now it's just another IDE. But instead I have to sift through thousands of half-baked 3rd party plugins to get the functions I need. Editors/IDEs should do one thing or the either well.
- Philip-J-Fry 5y ago
  >But instead I have to sift through thousands of half-baked 3rd party plugins to get the functions I need That's the entire point? The functions don't exist because it's supposed to be lightweight. If you're finding that you need 20+ plugins to add features then I've got news for you, you're looking for an IDE that has all these built in by default.
  - fileeditview 5y ago
    Not OP but.. I have certainly around 20 plugins in my Vim and it runs faster than Usain Bolt. I agree with your first point but the IDE argument is wrong. I could use 100 plugins and it still would not be an IDE nor would I want one.
  - coldtea 5y ago
    >* If you're finding that you need 20+ plugins to add features then I've got news for you, you're looking for an IDE that has all these built in by default.* I also have news for you, VS Code's whole selling point was "built-your-own-IDE" and big plugin ecosystem, not "here's yet another lightweight editor".
throw_m239339 5y ago
VS Code isn't bloated if you never install any extension. You can't hold Microsoft responsible for third party bloat.

DeathArrow 5y ago

This feels like fresh air compared to tons of tools written in Javascript and running in a browser.

amelius 5y ago
Seems like you have been picking the wrong tool for the job.
- Hendrikto 5y ago
  Seems like Atom and VSCode picked the wrong tool for the job.
  - Lhiw 5y ago
    Could have told them that 10 years ago.
  - sofixa 5y ago
    Both work fairly well, are popular and performance is satisfactory (unless you try to paste an 80k line JSON file into either of them, that doesn't work). Considering their success, wide availability and vibrant ecosystems, I'd say they picked the right tool for the job.
    - timeon 5y ago
      Not sure if eating memory like complex 3d modeling software (with model in it) for something what is at the end of the day basically just text editing is the right tool for the job. Energy with excluded externalities is cheap. So modern personal computers can bear anything. But should they?
      - zarzavat 5y ago
        It's a tradeoff. Because they are written using web technologies it means that they are very extensible. If you are a professional then just buy more RAM.

buster 5y ago

My first thought was, not yet another terminal editor written for fun, but when I read druid, lsp, wasi plug-ins... That sounds very intriguing!

runiq 5y ago
Yeah, this reads like my bucket list of Rust technologies if I ever decided I'd want to implement a text editor. Definitely going to try this out. Thank you for bringing this to our attention, OP!

stormbrew 5y ago

> Built in remote development support (inspired by VSCode Remote Development) Well... This has me intrigued. This is basically the only thing that keeps me on vscode.

carlmr 5y ago
Same, + remote containers.
mikeyjk 5y ago
Jetbrains is trying to catch up on this, and in some cases has.
- stormbrew 5y ago
  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.
  - akmittal 5y ago
    I think above comment is about jetBrains fleet. VSCode alternative written in kotlin
    - lordofgibbons 5y ago
      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
      - akmittal 5y ago
        They have made a custom UI framework based on skia rendering engine. Skia is used by flutter, Chrome and firefox for rendering and known for great performance. https://github.com/jetbrains/compose-jb https://github.com/jetbrains/compose-jb
      - 5y ago

jokoon 5y ago

No windows build?

geniium 5y ago
Yes but not sure it works for you
- jokoon 5y ago
  what do you mean?
trbn 5y ago
https://github.com/lapce/lapce/releases/tag/v0.0.1 https://github.com/lapce/lapce/releases/tag/v0.0.1

Dave3of5 5y ago

The open folder command is unbound by default on windows. Is it meant to be like that ? I literally couldn't open any folder. Also on windows by default it leaves a separate command window hanging which seems odd. Why isn't this logging done within the app terminal itself.

chrysoprace 5y ago

Xi, the backend that it's built on, is unfortunately in maintenance mode and it seems like it has been for a while now.

rapsey 5y ago
Druid is also in a poor state at the moment (it pulls master from git) and it's not using wgpu at all. I assume it used to use a piet wgpu branch but it is not anymore.
- runiq 5y ago
  Do you mean lapce pulls Druid from Git and isn't using wgpu right now, or do you mean Druid itself? I'm afraid I can't quite parse your comment.
- dzhou121 5y ago
  It uses a heavily forked version of Druid. https://github.com/lapce/druid https://github.com/lapce/druid which replaces the window management to use winit instead https://github.com/rust-windowing/winit https://github.com/rust-windowing/winit and a self-written wgpu backend hooked with druid. https://github.com/lapce/piet-wgpu https://github.com/lapce/piet-wgpu For xi, it only uses it for text manipulation.
panzerklein 5y ago
According to readme it's not a Xi frontend, but rather it uses same algorithms for string manipulations

cassepipe 5y ago

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

chespinoza 5y ago
Wow, I didn't know about those editors, they look awesome man, thanks for sharing.
depressedpanda 5y ago
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.

Ygg2 5y ago

Any option to sponsor? I'd like to contribute with money since my time is kinda devoured.

revskill 5y ago

Why always lightning, why not sound-speed ? As soon as memory management issue is solved, i could see all future software will eventually be written in Rust (or similar language)

adwn 5y ago
> As soon as memory management issue is solved [...] What does this refer to?
- revskill 5y ago
  Rust memory management model ?
  - adwn 5y ago
    And what issue related to Rust's memory management is to be resolved?
    - rwmj 5y ago
      The fact that it makes you think about it all the time, rather than using a garbage collector?
      - adwn 5y ago
        The lack of a GC is a pretty fundamental aspect of Rust's design, I don't see that changing in the foreseeable future. "As soon as memory management issue is solved" makes it sound like a small bug or missing feature that can be fixed with a little work.
      - krageon 5y ago
        That wouldn't be a fix, it would be a regression.
        rwmj 5y ago

cortexio 5y ago

No plugins yet, so not for me. The way i navigate through my open files and code is quit unique but also important for me.

zokier 5y ago

As always, if something is advertised as "fast" (or especially lightning-fast), it would be really nice to see some performance characterizations to explain in what way it is fast. Otherwise it feels so very meaningless label that is so often slapped on things on very weak grounds. And just because the building blocks might individually be said to be fast, it doesn't automatically mean that the conglomerate of them is still fast; performance is a fickle thing.

schrute 5y ago

The product crashes on MacOS Catalina, Arch, Ubuntu and Win 10. Lightning fast indeed. /s

slowtec 5y ago

I would love to see that the community join forces and combine all the different projects: https://github.com/flosse/text-editors-written-in-rust https://github.com/flosse/text-editors-written-in-rust

mlinksva 5y ago

https://github.com/lapce/lapce/blob/master/docs/why-lapce.md 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.