Hacker News Reader

Hacker News

Comment by nikolay | Hacker News Reader

Parent Full thread

nikolay

That's ridiculous!

View on HN

I saw your comment on the thread.

A. Most WebAssembly implementations are bigger than Helix itself.

B. WebAssembly is immature.

C. Lisp is perfectly fine. Even if you don't like it, it's not the end of the world if you have to use it to configure Helix.

A. It's true that Wasmer is bigger, but even my phone has 16GB of RAM and 1TB of storage space.

B. There are probably more computers running WebAssembly loads today than Lisp ones.

C. Lisp is a mature language, almost too mature. I used it extensively in the '80s and it served me well then, but that was 40 years ago. At least have the decency to use a more modern language like Lua, which is what Neovim uses.

A. Sure, but it isn't sufficiently beneficial for the cost.

B. WebAssembly is immature for developing a plugin system because of the lack of a sufficient ABI: https://github.com/WebAssembly/component-model

C. There aren't any other languages that meet the criteria. Lua was a no-go from the start. The maintainers did not like the language, and it necessitated adding more C code to Helix which could complicate building even further. https://github.com/helix-editor/helix/discussions/3806#discu...

A Lisp, a weird dialect of Lisp, is not better than Lua. Why use Rune [0]?!

[0]: https://rune-rs.github.io/

Rune is not mature and is developed by a handful of people. Please check the thread I linked, literally everything you could say has already been addressed.

Saying "X is better than Y" or "Why not Z?" is not constructive at all.

It is constructive, though - Lisp used to be fun when parsing complex language grammar was not as trivial as it is today. I loved it, and I worked with muLisp for many years... in the '80s and '90s. For AI (or, rather, "expert systems"), it was without a match... prior to the '80s, though. There were Lisp machines even... in the past.

Lua is very weak for "programming in the large". It's just a little bit better than early JavaScript. Scripts are OK, but anything that requires more code with more structure requires incredible amounts of perseverance and discipline from all contributors. You can do fairly large programs in Lua as a small team of highly skilled hackers, but the barrier to entry will be much higher than if you did it in a language that offers ready-made abstractions.

I use AwesomeWM, which is basically Emacs of Window Managers, with Lua instead of Elisp. The code is very well written and documented, yet getting into it is much more complicated than if it was written in Python - even if that Python was written poorly.

Why? The properties of lisp make it suitable for both a config file, and an extension language. It can be easily embedded into existing languages and is extremely flexible.

Turing-completeness in a config file is an anti-pattern. Write an external program to generate the config file instead.

Why? Emacs has Emacs Lisp and Neovim has Lua, it's great to be able to configure, write plugins and helper functions, in the same language.

If you're target audience are not progmmers versed in your wacky config language, it's a tremendous foot gun. Also a huge security hole.

It's possible to write declarative configuration in scheme. You can see that in Guix. Eventually someone will write a macro to create something purely declarative, like use-package in emacs.

> it's a tremendous foot gun

I've never seen this footgun in action with elisp in Emacs, lua in neovim or vimscript in vim. Is this anything more than hypothetical?

> Also a huge security hole.

If you put an editor in a position where its Turing-complete configuration is a security hole, you'll be in a lot more trouble than you imagine. Editors by definition are meant to modify stuff in a filesystem. With those privileges, it wont matter what the config language is. The plugins, even in webassembly, will cause serious issues.

It's a text editor specifically made for writing code.

So, if I use an editor config off the Internet, I need to inspect it for malware, because it's code, not configuration? Yes, there are languages for configuration - Jsonnet, Starlark, Dhall, which are execution safe - unlike Lisp and Lua!

Do you inspect all the code you run on your computer? You probably got all of it off the internet, except for the firmware blobs you couldn't even inspect if you wanted to.

And hell, even an "execution safe" configuration can contain malware if there's a parser bug.

At some point you have to choose who to trust and not to trust to write code that runs on your system, and all you can really do is try to verify that they did in fact write it, and run untrusted code in isolation from sensitive data.

I install software from credible sources. I do reuse configs from dotfiles off the Internet - just like most people do.

There are way more configs out there than there are software projects.

You already face the same threat then. Many, if not most, nontrivial programs have at least one way to escalate to arbitrary code execution from config. For example sway has exec, basically any useful editor has "on save actions", etc. No need for a Turing complete language when you can just shell out.

Why would you use an entire config off the internet?

Whenever I update my spacemacs config+packages I'm kind of doing that, there's no way you can honestly convince yourself that you thoroughly reviewed everything, but I guess the same applies to when you update your boring text editor's binary and forget to opt-out to some new feature you may not want as your old config might not mean the same thing now.

I think the real problem is around being able to trust your entire system. It'd help much more to have a better capability system so my rouge text editor can't upload my photos or credit card info from my browser profile to the internet, but today things kind of work because of tons of well intended and behaved people collaborating.

FWIW, the plugin system is supposed to have sandboxing as well.

Scheme has sandboxing in the form of environments. You can evaluate[0] / load[1] untrusted code by applying an environment specifier[2] with all of the symbols you trust the code to use. For example, if you don't want the code to be able to use IO, simply don't add (scheme read) and (scheme write) to the environment that you eval / load the code with.

[0] https://index.scheme.org/filterset/r7rs_small/%28scheme%2520...

[1] https://index.scheme.org/filterset/r7rs_small/%28scheme%2520...

[2] https://index.scheme.org/filterset/r7rs_small/%28scheme%2520...

Putting arbitrary bounds on how people use their computers is an anti-pattern.

Right, but his concern about security is not just to restrict how you use your computer, but to try to keep it safe in a manageable way.

However, the current state of guarantees around it is not at the point where Turing-completeness is the biggest issue. You can have a simple config, but the rest of the system is still unverifyiable and running unknown blobs.

I think the reasonable way out of it is through restricted capabilities. We won't get a fully verifyiable system we can inspect anytime soon. Probably not before the dark days of mandatory and somewhat provable ad impressions.

But then how do you write custom key handlers?

This is why I always only put finite memory in my computers.

Certainly less ridiculous than YAML pretending to be a declarative key-value file store

It's perfectly viable as a MVP. WebAssembly plugins for Helix had been proposed many times but without an actual implementation being worked on.

Reply on news.ycombinator.com