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.

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!

Hey! I really appreciate the built-in modal editing and remote development support. It would be good if we can have linux builds.

Why did you opt for WASI for plugins instead of native compiled code?

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.

> 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.

I think WASI is an excellent idea. Do you know how the ABI works?

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?

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.

> 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.

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.

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.

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.

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

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.

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

This is awesome! Looking forward the WebAssembly WASI integration :)

Damn this is really cool - thanks!

Hi, it looks nice! I really appreciate efforts like this, does it only supports Rust?