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.
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.
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.
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?
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.
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.
Thanks for taking the time to explain. I guess I was pretty ignorant in thinking that a plugin basically has all access to the dev-env it's written in.
I hadn't really heard of WASI, let alone understand it, but it totally makes sense why you would want to leverage this approach, along with any IDE-specific plugin interfaces/integrations.
> 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.
That sounds absolutely amazing. Are there any desktop apps delivered like this yet? Any operating systems or some sort of runtimes (browsers?) that support them?
I want to install apps on my desktop without worrying about it too much. Sadly currently restricted to PWAs.
To be even more specific: Webassembly is an abstract stack machine. There are no binary executables. You distribute the code in either the text or binary (`.wasm`) format, which is then executed by a runtime.
The runtime can be an interpreter or a (JIT) compiler. The latter can get you relatively close to native performance.
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
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.
> 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
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"
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.
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).
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.
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.
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.
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.
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?
It could be very extensible without being written in web technologies. For example, an IDE I worked on was written in C++ with Qt and had an embedded Python interpreter to allow extensions to be written easily. It also provided a .dll/.so extension mechanism for stuff that wanted more performance than Python could give.
It used 10-20 megs of RAM and loaded in about 2 seconds on the computers of the era (about 10-15 years ago).
It wasn't very good, but that's beside the point :-) It wasn't bad because of the technology stack it was built from.
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!
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 :)
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.
>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.
>* 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".
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.
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.
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.
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?
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.
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.
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)
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.
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.
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.
Yes, but if this is standard procedure in 99.999% of cases, I doubt "good enough for them" habit of running a commercial binary that's not open source (basically how the whole planet except perhaps NSA and such works), is not also good enough for some random linux user (assuning they don't trade in ultra-sensitive data).
As I said, it is not good enough for me. Why do you feel the need to argue for closed-source software, anyway? Do you need to justify this to yourself? Rest assured, personally, I don't care what you feel comfortable using.
on a side note, banks and governments often actually audit closed-source code, as they get that worked out in their contracts. Go ahead and ask Microsoft, if you could do the same...
>Why do you feel the need to argue for closed-source software, anyway? Do you need to justify this to yourself? Rest assured, personally, I don't care what you feel comfortable using.
Why do you feel the need for ad-hominen arguments and pop-psychology BS? Do you feel personally validated because you use Open Source, compensating for other lacks in your life, perhaps not being loved enough as a kid?
See how two can play this game? Maybe stick to practical arguments?
My point was in practical use, trusting a proprietary commercial binary (from Microsoft, Oracle, whatever) is not a big issue for far more sensitive environments (banks, governents, etc) than the average user case.
Lol. I was just stating my personal preferences, then you came calling me out unreasonable. I made it very clear, that it's about how I feel about it. Not reason. I am not arguing at all.
But hey, I also gave you an actual argument, you ignored......
~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.
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.
You do you. For me, that editor is not 80 USD better than... well, there are a lot of great alternatives. It's not even like Sublime is flawless, and I am not sure I would use it, if it was FOSS (tho, then it may become flawless over time).
Also, apparently it's $100 USD now. C'mon, 100 bucks for a basic text editor?!
$100 per compared to however much you make per year using that tool is nothing if that tool makes you more productive. Personally, I haven’t found a lot of great alternatives. Picking the best text editor is like picking the best mail client: you settle for the least shitty one. I am happy to pay good developers for good tools that make me more productive. Focusing on open source at all costs is a great way to ignore the actual costs of those tools.
Also, developers are spoiled af. Imagine if you worked in industrial design or something. The standard there is something like solidworks or autocad. You’d get laughed out of the room if you tried to stumble through with some open source alternative. Just the software can be $x000/year and that’s not even considering the hardware that some might need to stay productive. You want to actually prototype something? Pony up another pile of money for a CNC or a laser cutter or whatever + the operator time (if you don’t know how to do it) + the materials.
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 :(
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.
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".
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 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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
Why did you opt for WASI for plugins instead of native compiled code?
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.
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.
I think WASI is an excellent idea. Do you know how the ABI works?
> 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.
multiply that with the CPU ISA, like arm, x86 (and more if you are inclined to support power, sparc, ...)
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)
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?
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.
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.
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.
Thanks for taking the time to explain. I guess I was pretty ignorant in thinking that a plugin basically has all access to the dev-env it's written in.
I hadn't really heard of WASI, let alone understand it, but it totally makes sense why you would want to leverage this approach, along with any IDE-specific plugin interfaces/integrations.
> 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.
That sounds absolutely amazing. Are there any desktop apps delivered like this yet? Any operating systems or some sort of runtimes (browsers?) that support them?
I want to install apps on my desktop without worrying about it too much. Sadly currently restricted to PWAs.
> Are there any desktop apps delivered like this yet? Any operating systems or some sort of runtimes (browsers?) that support them?
Ever heard of apparmor?
That's per application security profiles, distributed with any applications on many Linux distributions.
firejails on linux as well. there are others but that's the only one I'm familiar with.
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.
To be even more specific: Webassembly is an abstract stack machine. There are no binary executables. You distribute the code in either the text or binary (`.wasm`) format, which is then executed by a runtime.
The runtime can be an interpreter or a (JIT) compiler. The latter can get you relatively close to native performance.
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
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.
Lsp support as well ? You have got to be kidding me. How did you add these feature so quickly ?
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.
This is awesome! Looking forward the WebAssembly WASI integration :)
Hey! I really appreciate the built-in modal editing and remote development support. It would be good if we can have linux builds.
Edit: Alright nevermind just saw in the repo that the UI is in Druid, have a nice day and again thank you
Care to elaborate on what's wrong with Druid?
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"
Ah, my bad — got thrown off by the original wording
Hi, it looks nice! I really appreciate efforts like this, does it only supports Rust?
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!
There is cargo install, yes :)
https://doc.rust-lang.org/cargo/commands/cargo-install.html
Thank you!
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.
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).
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.
That reminds me of the (current) top-most comment in the `drgn` thread here: https://news.ycombinator.com/item?id=29537594
"just keep rebooting to solve the problem, rather than fix it"
When "lightning fast" just means native, then it could very easily be slower than a webapp that uses a more fitting algorithm.
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.
Damn this is really cool - thanks!
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/
Wow, I didn't know about those editors, they look awesome man, thanks for sharing.
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.
This feels like fresh air compared to tons of tools written in Javascript and running in a browser.
Seems like you have been picking the wrong tool for the job.
Seems like Atom and VSCode picked the wrong tool for the job.
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.
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?
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.
>If you are a professional then just buy more RAM.
That cockiness sounds familiar, and it was the reason why people moved from Java based IDE's to vscode/atom/sublime.
It could be very extensible without being written in web technologies. For example, an IDE I worked on was written in C++ with Qt and had an embedded Python interpreter to allow extensions to be written easily. It also provided a .dll/.so extension mechanism for stuff that wanted more performance than Python could give.
It used 10-20 megs of RAM and loaded in about 2 seconds on the computers of the era (about 10-15 years ago).
It wasn't very good, but that's beside the point :-) It wasn't bad because of the technology stack it was built from.
No, as a professional you just pick better software.
Sufficient extensibility does not require software to be terrible.
They just chose other-people-choosing-the-wrong-tool-for-the-job as a business model.
JetBrains recently announced Fleet. Written in Kotlin and Rust.
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!
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!
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 :)
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.
>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.
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.
>* 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".
VS Code isn't bloated if you never install any extension. You can't hold Microsoft responsible for third party bloat.
But not using a single plugin is near impossible.
Well… it‘s built on Electron. If your editor comes with its own browser, that‘s bloat.
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.
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.
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.
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?
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.
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.
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)
Emacs isn’t slow
sublime text is the best editor currently, in my view.
apart from code folding.
Yep, I'm either on Sublime or Emacs.
Only problem with sublime is the exorbitant price. It's just too much!
$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.
Not everyone on HN is on Silicon Valley wages. Or even work in international tech hubs like SV or London.
For some in tech, $100 is a hell of a lot of money.
$100 for a text editor seems quite expensive to me. I agree it is not much in comparison to many other professional tools.
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.
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...
>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)...
Honestly "big companies, banks, governments" do sound like the usual suspects for writing programs insecurely to me (I work for one of those).
Yes, but if this is standard procedure in 99.999% of cases, I doubt "good enough for them" habit of running a commercial binary that's not open source (basically how the whole planet except perhaps NSA and such works), is not also good enough for some random linux user (assuning they don't trade in ultra-sensitive data).
As I said, it is not good enough for me. Why do you feel the need to argue for closed-source software, anyway? Do you need to justify this to yourself? Rest assured, personally, I don't care what you feel comfortable using.
on a side note, banks and governments often actually audit closed-source code, as they get that worked out in their contracts. Go ahead and ask Microsoft, if you could do the same...
>Why do you feel the need to argue for closed-source software, anyway? Do you need to justify this to yourself? Rest assured, personally, I don't care what you feel comfortable using.
Why do you feel the need for ad-hominen arguments and pop-psychology BS? Do you feel personally validated because you use Open Source, compensating for other lacks in your life, perhaps not being loved enough as a kid?
See how two can play this game? Maybe stick to practical arguments?
My point was in practical use, trusting a proprietary commercial binary (from Microsoft, Oracle, whatever) is not a big issue for far more sensitive environments (banks, governents, etc) than the average user case.
Lol. I was just stating my personal preferences, then you came calling me out unreasonable. I made it very clear, that it's about how I feel about it. Not reason. I am not arguing at all.
But hey, I also gave you an actual argument, you ignored......
> 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.
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.
You do you. For me, that editor is not 80 USD better than... well, there are a lot of great alternatives. It's not even like Sublime is flawless, and I am not sure I would use it, if it was FOSS (tho, then it may become flawless over time).
Also, apparently it's $100 USD now. C'mon, 100 bucks for a basic text editor?!
$100 per compared to however much you make per year using that tool is nothing if that tool makes you more productive. Personally, I haven’t found a lot of great alternatives. Picking the best text editor is like picking the best mail client: you settle for the least shitty one. I am happy to pay good developers for good tools that make me more productive. Focusing on open source at all costs is a great way to ignore the actual costs of those tools.
Also, developers are spoiled af. Imagine if you worked in industrial design or something. The standard there is something like solidworks or autocad. You’d get laughed out of the room if you tried to stumble through with some open source alternative. Just the software can be $x000/year and that’s not even considering the hardware that some might need to stay productive. You want to actually prototype something? Pony up another pile of money for a CNC or a laser cutter or whatever + the operator time (if you don’t know how to do it) + the materials.
Unironically yes. It's so fast.
agree :) daily driver. nova.app pretty great stuff too
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.
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
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.
Any option to sponsor? I'd like to contribute with money since my time is kinda devoured.
The 0.0.1 release crashes on MacOS 12.0.1, would be nice to try it out when its more stable.
It crashes in Catalina too, unfortunately. I was looking forward to trying the build.
It crashes on Ubuntu 20.04 also with `memory allocation of 18446744073709551615 bytes failed`
It seems to crash on windows and macos based on the issues in github.
Starting issues reported:
Windows issue: https://github.com/lapce/lapce/issues/9
macOS issue: https://github.com/lapce/lapce/issues/7
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".
To attract contributors who want to learn more rust by collaborating on something they care about.
Agree, that makes sense.
> 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.
Same, + remote containers.
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 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)
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
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.
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.
Sadly can't get it to run on linux :(
Lot of garbage about loading font config from /etc/fonts/conf.d/... and then:
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?
It doesn’t violate memory safety, so it’s perfectly valid to do this in safe rust
It's not underflowing int. Actually it's a divide by 0 bug, because font handling returns 0 sometimes. See my sibling comment.
> 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.
Just need more RAM.
There is a bug and I found a possible culprit (worked on Win 10):
https://github.com/lapce/lapce/issues/9#issuecomment-9935004...
Xi, the backend that it's built on, is unfortunately in maintenance mode and it seems like it has been for a while now.
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.
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.
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.
According to readme it's not a Xi frontend, but rather it uses same algorithms for string manipulations
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.
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.
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)
> As soon as memory management issue is solved [...]
What does this refer to?
Rust memory management model ?
And what issue related to Rust's memory management is to be resolved?
The fact that it makes you think about it all the time, rather than using a garbage collector?
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.
That wouldn't be a fix, it would be a regression.
In an editor? This isn't a real time OS.
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?
Rust-analyzer is an LSP Server, so it should be supported.
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
The product crashes on MacOS Catalina, Arch, Ubuntu and Win 10. Lightning fast indeed. /s
No windows build?
Yes but not sure it works for you
what do you mean?
https://github.com/lapce/lapce/releases/tag/v0.0.1