Re: Consideration for Rust contributions in Emacs

[Troy Hinckley <comms@dabrev.com>]

[-- Attachment #1: Type: text/plain, Size: 4060 bytes --]

Thanks Sean!

I should have been clearer in my question that I don’t have any Rust code that I want to contribute to GNU Emacs, and I don’t know anyone who does. This is a hypothetical.

I don’t think Rust should be added to the Emacs core. The core is well tested and battle hardened C and Rust would not add much value.

I guess a clearer question would be: are there any fundamental/ideological reasons Rust could not be part of GNU Emacs? Ignoring technical trade offs and complexity etc.

Po Lu already provided one; Emacs needs to support old platforms like MS-DOS. So that rules out LLVM.

Are there others? I am particularly interested in issues surrounding licensing, such as the question I posed above about libraries.

On Jan 22, 2023 at 7:30 PM -0700, Sean Allred <allred.sean@gmail.com>, wrote:
> 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

[-- Attachment #2: Type: text/html, Size: 4849 bytes --]