Skip Navigation

Allowing to add functionalities in Rust

crosspostato da: https://lemmy.world/post/1578379

Hi, I Just started working on a Emacs-inspired text editor in Rust.

Being insipred by Emacs, the most important part Is the possibiliy to implement new components.

My ideas were:

  • Rust-based scripting language, like Rhai
  • RustPython (slower, but more compatible and lots of people know Python)
  • PyO3 (Bigger executable and not that fast)
  • Wasm/Wasi (Cross-platform, but I don't know if the compatibility with Rust's hosted functions and structs is good)
  • Other binded language, like V8, Lua or SpiderMonkey
  • Compiled plugins, like .so or .DLL (Fast, but not compatible; there should be Rust plugin frameworks for implementing this, but I don't remember the name)

The elements to analyze are: speednees (consider it's a text editor, so...), easy-to-develop and Cross-platform (if possible, not that important), but the possibility to execute functions in the host Rust program is EXTREMELY important.

Thoughts?

Thanks in Advance.

4

You're viewing a single thread.

4 comments
  • I have been working on something similar, not in Rust but the general consensus of what I found still should be helpful.

    interpreted languages are easy however typically not as efficient as what you would want especially because you know people will take the language and run to the moon with it.

    Jit Compiled language with a good Jit these are fast enough especially for a text editor or other utilities that you normally wont need a fully compiled language and when you do then you can use bindings which should be a rare occurrence which is nice.

    Binded languages are pretty good they typically have been around for a while people know them and its a safe bet, something like Lua with its Jit is quite fast, or javascripts Jit .

    Fully compiled my concern I had with this approach is people would need the compiler tool chain just to do basic edits which for developers that just want to use the editor and not configure it will be very annoying or borderline impossible. the specific scenario I had trouble with was a config file generator I made for work I make a lot of these and I sent the code a long with it however they needed to download the compiler to use the script which meant I basically had to re run it every time myself. with a text editor you may not think this will be necessary until someone shares the editor with a friend. of course if you pack the compiler into the editor this would work.

    another concern is compile times, I think users when changing their config could get annoyed if they need to compile something every time, they want to test a new setup.

    the big benefit with fully compiled is hopefully your users will be using the same language as yourself, and this makes it a lot easier to debug user level code. of course this should be the case with any of these options if you primarily use the same language as your users however going fully compiled makes the separation between dev and user much smaller. and the second being speed that will make the editor quite fast.

    I would make a numbered list of the best to worst option however it really depends on if you want to keep the project completely in Rust or not, for my project I wanted to use one language so I went with the fully compiled approach , with a language that contains a runtime eval, so it depends on what you want out of the editor.

    personally I prefer the fully compiled approach I think it makes a lot more sense, next would be a language implemented in Rust.

    "sense" as in my mental model of the project. ^

    For users I find they tend to prefer a language that they are already familiar with, such as lua, javascript, or python however I tend to find the usefulness to be surface level helps the very beginners but I think it makes it harder for people who really want to make something useful.

    in quite a few games/programs/editors I use, scripting languages tend to not be very well documented because the devs rarely see the scripting language when developing, however when the "scripting language" is the same as the main dev language the users can use the main dev documentation also for scripting in a lot of cases. thus why I think Neovim and Emacs work so well, doesn't need to be the same language as long as devs use the scripting language enough to get irritated at its flaws.

    "main dev language" in terms of time spent by the developers in the language ^

    hopefully this helps and makes sense.