Get the top HN stories in your inbox every day.
dzhou121
gsliepen
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
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
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.
IshKebab
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.
spyremeown
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!
alskdj21
Hey! I really appreciate the built-in modal editing and remote development support. It would be good if we can have linux builds.
DeathArrow
Why did you opt for WASI for plugins instead of native compiled code?
dzhou121
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
> 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
I think WASI is an excellent idea. Do you know how the ABI works?
froh
multiply that with the CPU ISA, like arm, x86 (and more if you are inclined to support power, sparc, ...)
the_duke
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
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?
galgalesh
I wanted to clarify the cross-platform point:
WASM + WASI means a single binary has near-native performance, but can run on any CPU architecture and any OS.
stefs
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.
conradludgate
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
But JS _is_ a common intermediate Language. I guess more languages compile to JS than to WASM.
thecleaner
Lsp support as well ? You have got to be kidding me. How did you add these feature so quickly ?
IshKebab
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.
undefined
lnxg33k1
Edit: Alright nevermind just saw in the repo that the UI is in Druid, have a nice day and again thank you
jonpalmisc
Care to elaborate on what's wrong with Druid?
lnxg33k1
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"
undefined
syrusakbary
This is awesome! Looking forward the WebAssembly WASI integration :)
vmchale
Damn this is really cool - thanks!
cassepipe
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/
depressedpanda
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.
chespinoza
Wow, I didn't know about those editors, they look awesome man, thanks for sharing.
DeathArrow
This feels like fresh air compared to tons of tools written in Javascript and running in a browser.
manojlds
JetBrains recently announced Fleet. Written in Kotlin and Rust.
amelius
Seems like you have been picking the wrong tool for the job.
Hendrikto
Seems like Atom and VSCode picked the wrong tool for the job.
sofixa
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.
amelius
They just chose other-people-choosing-the-wrong-tool-for-the-job as a business model.
Lhiw
Could have told them that 10 years ago.
buster
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
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!
debdut
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 :)
throw_m239339
VS Code isn't bloated if you never install any extension. You can't hold Microsoft responsible for third party bloat.
IshKebab
Well, sort of. The problem is it's difficult to implement a lot of extension functionality in efficient ways, and sometimes they make it too easy to do it in really really inefficient ways. Examples:
* LSP uses JSON. Even worse, VSCode uses UTF-16 internally (because Javascript does, more or less). But JSON uses UTF-8. So for correct operation VSCode converts the UTF-16 to UTF-8, and then your language server has to convert it back to UTF-16 to figure out the row/col positions (which are in UTF-16 units).
* LSP has an "easy mode" where the entire document is sent to the language server on every keypress!
* Some functions like `provideDocumentLinks()` operate on the entire document, so on every keypress (maybe it batches them I don't know), all linkifier extensions will run a load of regexes over the whole document.
There's definitely scope for a text editor with an extension API that encourages speed.
Hendrikto
Well… it‘s built on Electron. If your editor comes with its own browser, that‘s bloat.
arghwhat
It is subjective and depends on your baseline. When you're used to fast editors ((neo)vim, sublime text back in the day, etc.), then VS Code is sluggish and bloated out of the box, and the idea of adding extensions that could make it worse is nightmare fuel.
Ygg2
But not using a single plugin is near impossible.
johnisgood
VSCodium is fine, so is emacs and vim. I use them along with IntelliJ IDEA. This "code editor" looks pretty minimal in comparison to the ones I mentioned... at least as far as the screenshot goes.
jokoon
sublime text is the best editor currently, in my view.
apart from code folding.
monopoledance
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 editor matched Sublime's intuitive `TAB` completion dynamics.
Oh, yeah, and it's fucking expensive...
coldtea
>Personally, I just don't feel comfortable working with sensitive information or proto-executables in closed-source software.
So, just how the biggest companies, banks, governments, etc. in the world work (using e.g. Excel, Word, Visual Studio, etc)...
Fnoord
> 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 Sublime and Vim, sometimes Vi, and on Citrix we got Notepad++ which is Windows-only.)
> Personally, I just don't feel comfortable working with sensitive information or proto-executables in closed-source software.
For starters, you could decide to not not hang it on a network 24/7. Or hang it in a different VLAN than the stuff on your network using Log4j.
yz1ruhzh
It was my daily driver for programming, editing.. pretty much everything text related until their latest version. Autocomplete became extremely annoying and the editor feels less snappier. After years I ended up switching to VS Code, and I keep sublime text when I quickly want to edit a text file.
zerocount
Yep, I'm either on Sublime or Emacs.
spyremeown
Unironically yes. It's so fast.
perryizgr8
Only problem with sublime is the exorbitant price. It's just too much!
preommr
$100 for what one (three?) years?
Seriously?
Forget the exorbitant tech salaries, so many other industries charge way more for essential equipment. That's chaper than a single snap-on wrench out of the hundreds that an automative shop has to buy. It's two months of adobe bundle that most graphic designers subscribe to. I think the perspective here is important.
debdut
agree :) daily driver. nova.app pretty great stuff too
sharikous
The bloating cycle should merit its own xkcd comic I guess. VS Code was specifically successful because it was perceived as much less bloated then IDEs, yet much more user friendly than most editors. Now we hear complaints that it is bloated. What will be next?
laurent123456
All "lightweight", "fast" shiny new things are so because they have plenty of missing features. But anyway is it a widespread opinion that VSCode is bloated? Because for me at least it feels fast, especially considering all its features.
agumonkey
VSCode is bloated [0]. I ran a fresh install on a 1st gen i5, it couldn't process keyboard input on an empty file above 4 char per sec. Levels of lag my brain couldn't remember (and I'm a hp48g lover.. not known for zero latency).
[0] That was last year, so maybe it was a buggy release (doubt it) or maybe they made big improvements since (possible)
vidarh
A challenge is that we tend to have roughly the same 80 percent point for things like editors, but all want different sets of features for the remaining 20. You then either end up with bloat or extensibility/plugins, or both.
GhettoComputers
Emacs isn’t slow
hdjrudni
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
>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
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
>* 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".
pjmlp
Other than having to put up with Electron, nope it isn't bloated, in fact it is still missing lots of nice IDE like features.
debdut
well the bottleneck is electron. The startup times have consistently increased since I first started using it, now it uses north of 1gig RAM for a decent size project, too much for a text editor :(
Don't get started on the popups though!
And I don't use any extension
mlinksva
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.
Ygg2
Any option to sponsor? I'd like to contribute with money since my time is kinda devoured.
forgotmyoldacc
The 0.0.1 release crashes on MacOS 12.0.1, would be nice to try it out when its more stable.
megapoliss
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
To attract contributors who want to learn more rust by collaborating on something they care about.
megapoliss
Agree, that makes sense.
karavelov
It crashes on Ubuntu 20.04 also with `memory allocation of 18446744073709551615 bytes failed`
geniium
It seems to crash on windows and macos based on the issues in github.
geniium
Starting issues reported:
Windows issue: https://github.com/lapce/lapce/issues/9
macOS issue: https://github.com/lapce/lapce/issues/7
sharikous
It crashes in Catalina too, unfortunately. I was looking forward to trying the build.
darkblackcorner
Same here. Sounds interesting though - I'll keep an eye on it!
stormbrew
> 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.
stormbrew
Sadly can't get it to run on linux :(
Lot of garbage about loading font config from /etc/fonts/conf.d/... and then:
memory allocation of 18446744073709551615 bytes failed
Aborted (core dumped)Ygg2
There is a bug and I found a possible culprit (worked on Win 10):
https://github.com/lapce/lapce/issues/9#issuecomment-9935004...
w-m
Trying to allocate memory the size of an underflowed uint64 does not seem safe. Is this possible in safe Rust code? Is there a Rust build flag that would catch this behavior?
MaulingMonkey
> Is this possible in safe Rust code?
Yes.
> Is there a Rust build flag that would catch this behavior?
Runtime overflow checks (resulting in panics on over/underflow) are enabled by default in debug builds, but can also be enabled for release builds, or disabled for debug builds: https://doc.rust-lang.org/cargo/reference/profiles.html#over...
Additionally, you can use `Wrapping<T>` or `wrapping_sub` when wrapping is intentional, or `checked_sub` and explicit edge case handling when you want checks regardless of general build settings.
EDIT: that said, that's for integer overflow. Sibling comment references https://github.com/lapce/lapce/issues/9#issuecomment-9935004... which appears to:
1. Have a floating point div by zero.
2. Truncate when casting +inf floating point to integer.
Standard library & language checks won't catch either, although it'd be easy enough to roll your own checked math floating point type wrappers / conversion methods that would, or use an existing crate (e.g. using https://docs.rs/az/latest/az/fn.checked_cast.html to go from f64 -> usize instead of the `as` keyword would've caught #2. Since `as` is truncation-bait, some people prefer using the From/Into traits (infalliable, nontruncating) or TryFrom/TryInto traits (falliable, checked) as a matter of habit, avoiding the `as` keyword. However, neither of those traits cover f32 -> usize.
Ygg2
It's not underflowing int. Actually it's a divide by 0 bug, because font handling returns 0 sometimes. See my sibling comment.
Ar-Curunir
It doesn’t violate memory safety, so it’s perfectly valid to do this in safe rust
IshKebab
Just need more RAM.
mikeyjk
Jetbrains is trying to catch up on this, and in some cases has.
stormbrew
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
I think above comment is about jetBrains fleet. VSCode alternative written in kotlin
Aeolun
I don't mind it using half my ram, but it needs to respond in less than 16ms in all instances. I don't want to type one letter only to find my editor frozen for 5 seconds.
jcranberry
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.
carlmr
Same, + remote containers.
chrysoprace
Xi, the backend that it's built on, is unfortunately in maintenance mode and it seems like it has been for a while now.
panzerklein
According to readme it's not a Xi frontend, but rather it uses same algorithms for string manipulations
rapsey
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.
dzhou121
It uses a heavily forked version of Druid. https://github.com/lapce/druid which replaces the window management to use winit instead https://github.com/rust-windowing/winit
and a self-written wgpu backend hooked with druid. https://github.com/lapce/piet-wgpu
For xi, it only uses it for text manipulation.
runiq
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.
zokier
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.
Dave3of5
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.
Get the top HN stories in your inbox every day.
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.