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.
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.
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?
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.
> 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.
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.
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.
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.
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.
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"
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 :)
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.
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.
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.
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.
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.
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)
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.
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 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".
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.
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.
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.
The plugin system as described in the README hasn't been implemented yet.