Re: Consideration for Rust contributions in Emacs

[Sean Allred <allred.sean@gmail.com>]

Hi Troy!

Thanks for raising the topic. I think this is my first time posting on
the list, but this is a topic that means quite a bit to me (and is
something I've had some experience with in other projects).

Using Rust in Emacs is an exciting prospect that draws on the general
buzz that Rust has been generating. I personally enjoy using Rust for
personal and professional projects alike. As you've noticed, though, its
use in Emacs is not without its concerns.

Troy Hinckley <comms@dabrev.com> writes:
> I've had a discussion with several people recently about future
> possibilities of Rust in GNU Emacs core. I could not find an answer to
> this on the archives, so if it has been resolved previously please
> point me to that thread.
>
> Let assume for the sake of this discussion that there was a some Rust
> code that someone wanted to contribute and the maintainers wanted the
> functionality it provided. What would be the consideration/objections?

I would add to your list of considerations that Rust is designed for an
almost singular purpose that it performs very well: memory-safety. I
don't pay *that* much attention to this list, but I also haven't seen
many bug reports concerning memory mismanagement -- and I certainly
haven't experienced any such bugs myself. I suspect this is due to the
relatively small C core that provides a memory-safe runtime for the
elisp that comprises the rest of emacs. Assuming memory-safety isn't a
demonstrated problem that emacs development struggles with,
incorporating Rust into its dev pipeline is going to be a very hard
sell:

    Does Rust actually solve a problem emacs has?

I don't know that the answer is 'no'. Frankly, I don't think I'm
qualified to offer an opinion here. More importantly to your goals, I
don't see where you've shown why you believe the answer is 'yes'.

In general (and this certainly doesn't apply to just emacs), to
introduce a new technology into a stable system, you'll need to be able
to demonstrate concrete gains that *measurably* outweigh the costs.
Introducing a new technology will inherently destablize any affected
components of the system -- this is very difficult to justify in any
large project. Feel-good syntax isn't usually a compelling reason --
especially in a project that's developed a lisp runtime where syntax is
already cheap to develop.

The last significant endeavor in this direction that I'm aware of was
Remacs -- but it appears development has petered out for one reason or
another. I don't think it's a lost cause in the grand scheme of things,
but this clearly is not a ship that can/would/should change course very
easily.

--

If it is something you are comfortable using and they meet your goals,
I'd like to point out the recent support for dynamic modules. Rust has
pretty solid FFI support in my experience. If needed, you may(?) have
better luck submitting patches to hook into / advise core functions in
lisp -- and then using those hooks in a dynamic module implemented in
the language of your choice.

-Sean

--
Sean Allred