7 ms·

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.

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

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

thecleaner 5y ago

Lsp support as well ? You have got to be kidding me. How did you add these feature so quickly ?

IshKebab 5y ago
It probably doesn't have support for the full LSP, which is pretty huge. I imagine just the most useful things like completion and go-to-definition.
deleted 5y ago
[deleted]

DeathArrow 5y ago

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

conradludgate 5y ago
Either the plugin needs to be written in a common language (JS for VSCode, Python for Sublime Text) or native (Terraform does this for custom providers) but need to support many architectures. WASI fits snuggly in between, being a common intermediate language
- ReleaseCandidat 5y ago
  But JS _is_ a common intermediate Language. I guess more languages compile to JS than to WASM.
  - pbronez 5y ago
    WASM actually started life as a subset of Javascript called asm.js. Code in other languages was compiled to this subset of Javascript so they could execute in the browser. Once that proved useful, they decided to skip the Javascript step and agree on a binary format that browsers could execute directly. That's WASM. From https://en.wikipedia.org/wiki/Asm.js https://en.wikipedia.org/wiki/Asm.js > asm.js consists of a strict subset of JavaScript, to which code written in statically-typed languages with manual memory management (such as C) is translated by a source-to-source compiler such as Emscripten (based on LLVM).[2] Performance is improved by limiting language features to those amenable to ahead-of-time optimization and other performance improvements. > asm.js is mostly rendered obsolete with the introduction of WebAssembly (wasm), which has a bytecode format that is faster to parse. Efforts to extend JavaScript with more low-level features like SIMD.js has also been suspended since 2017. asm.js remains useful primarily as a "fallback" for wasm
  - UtherII 5y ago
    It can used as an intermediate language, and since it was the only way to run code on the browser without plugins before WASM, it happened a lot. But nowadays WASM is much more suitable for the job. JavaScript was designed as a scripting language, not a low level intermediary language.
stefs 5y ago
not OP, but i think it makes sense. there isn't that much of a speed difference and you get free sandboxing, some memory safety, a ton of supported languages and more. i don't know anything about WASI, but it probably solves the problem of having to interface with different native compiled code ABIs.
dzhou121 5y ago
I think native compiled code is hard for plugin distributions. You'll need to target 3 main platforms Linux/macOS/Windows. You can use github actions to do it, but it would be so easier to just compile to WASI and that's it. Also, WASI is compelling to me because of the potential of writing plugins in different programming languages.
- DemocracyFTW 5y ago
  > WASI is compelling to me because of the potential of writing plugins in different programming languages I think this is the future really, I've been pining for this to become a thing for so long.
- stavros 5y ago
  I think WASI is an excellent idea. Do you know how the ABI works?
- froh 5y ago
  multiply that with the CPU ISA, like arm, x86 (and more if you are inclined to support power, sparc, ...)
the_duke 5y ago
Webassembly makes a lot of sense for plugins. * sandboxing, so plugins don't need to be as trusted * Easy cross-platform distribution with a single build artifact * plenty fast (if written in a language like Rust/C++ and paired with a good runtime)
- chrisjc 5y ago
  Apologies for lack of my lack of knowledge in this area, but... Why don't plugins "need to be as trusted"? Obviously bad-actor plugins would be less effective and capable of inflicting any sort of attack on your development OS, but surely the development environment is the perfect vector for attacking the runtime environments that run your artifacts get deployed into? Not to mention the potential for secrets-harvesting due to sloppy boot-strapping dev-env habits or other bad habits we often engage in during the early development process? Or does WASI somehow provide protection from these issues?
  - laumars 5y ago
    The clue is in the first part of the GPs sentence which you latched onto: “sandboxing”. The code is running inside a virtual machine rather than natively on the host.
    - chrisjc 5y ago
      No, I got that. I understand how the host is protected, but didn't understand how everything inside the "VM" was protected... @galgalesh answers that above.
  - galgalesh 5y ago
    It's all about reduction of surface and giving plugins access to the least amount of info. You expect a linter to only have (read) access to the code it lints. It shouldn't be able to modify files, it shouldn't have network access etc. WASI has a pluggable capability-based security system. Some advanced linters might want network access but you can show this to the user, so they can make an informed decision about whether to trust that linter and their author with this power. This isn't airtight security to protect against obviously-malicious authors. This is about creating a system that can deal with the reality that "trust" in an app store entails "a million shades of gray". I might trust a plugin enough to check for errors in my code, but not enough to actually modify my code.

syrusakbary 5y ago

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

alskdj21 5y ago

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

lnxg33k1 5y ago

Edit: Alright nevermind just saw in the repo that the UI is in Druid, have a nice day and again thank you

deleted 5y ago
[deleted]
jonpalmisc 5y ago
Care to elaborate on what's wrong with Druid?
- lnxg33k1 5y ago
  Nothing, I edited the message because in the first version of the comment I asked which UI framework they were using, then I saw that info contained in the README and said "ah okay it's using Druid" as in "I saw that" not in "Ah crap you're using Druid"
  - deleted 5y ago
    [deleted]
  - jonpalmisc 5y ago
    Ah, my bad — got thrown off by the original wording

chespinoza 5y ago

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

spyremeown 5y ago

Hi, thanks for writing some free software! I'm not a Rust person, how do you install this? Is it something like "rustc install" or something like that? Thanks!

abendstolz 5y ago
There is cargo install, yes :) https://doc.rust-lang.org/cargo/commands/cargo-install.html https://doc.rust-lang.org/cargo/commands/cargo-install.html
- spyremeown 5y ago
  Thank you!

gsliepen 5y ago

This looks very nice. However, the description mentions "lightning fast" and "powerful". Unfortunately, those things don't mean anything without further clarification. If you really want to show your editor is faster than other commonly used editors, consider posting a benchmark of cases where speed matters (like loading a large file, inserting in the middle of a large file, search/replace, latency of pressing a key and having the screen updated, and so on). It is harder to quantify "power" though.

DrBazza 5y ago
Standard rust marketing, it's a bit tedious tbh, and I don't think anyone who is honest is surprised any more. Everything is "lightning fast" by default just because it compiles to native. I thought we were past that. Never mind that you can write crap code in any language (not making any comment about the editor's author here).
- Aeolun 5y ago
  I still prefer crap lightning fast code to crap tediously slow code though. If the only thing people do is build a native application instead of a webapp and that speeds my stuff up by 80% then that'll make me very happy.
  - DrBazza 5y ago
    That reminds me of the (current) top-most comment in the `drgn` thread here: https://news.ycombinator.com/item?id=29537594 https://news.ycombinator.com/item?id=29537594 "just keep rebooting to solve the problem, rather than fix it"
  - Dylan16807 5y ago
    When "lightning fast" just means native, then it could very easily be slower than a webapp that uses a more fitting algorithm.
- IshKebab 5y ago
  It's not just marketing. Rust tools like Tokei and Ripgrep are lightning fast. It's partly because it compiles to native - that applies to C/C++ too, e.g. Git is "lightning fast" compared to Mercurial. But it's also because Rust lets you do multi-threading without going insane.

vmchale 5y ago

Damn this is really cool - thanks!