summaryrefslogblamecommitdiffstats
path: root/2024/talks/rust.md
blob: 0c1c676fa92081998104a764792852a96887cc55 (plain) (tree)
1
2
3
4
5
6
7
8
9








                                                                                                    
                                                                        

















                                                                                                                                                                                                                                                                       








                                                                        
                                                                                                            


























                                                                         
                                                                                                              

                                                                     
                                                                                                                                                    






























































                                                                           
                                                  









                                                                      





                                                            
[[!meta title="An Experimental Emacs Core in Rust"]]
[[!meta copyright="Copyright © 2024 Troy Hinckley"]]
[[!inline pages="internal(2024/info/rust-nav)" raw="yes"]]

<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
<!-- You can manually edit this file to update the abstract, add links, etc. --->


# An Experimental Emacs Core in Rust
Troy Hinckley - <https://coredumped.dev>, <mailto:troy@troyhinckley.com>

[[!inline pages="internal(2024/info/rust-before)" raw="yes"]]

An overview and discussion and early prototype of a new Emacs core written in Rust. The talk covers some of the interesting design choices in the GNU Emacs C core, as well as some of the trade-offs made in the Rust core. <https://github.com/CeleritasCelery/rune>

-   What is the Emacs core?
-   How has the core evolved?
-   Design trade-offs
    -   multi-threading
    -   Precise GC
-   Being bug compatible with GNU Emacs
-   Comparison

About the speaker:

Hardware Engineer with interest in low-level programming and the hardware-software boundary.


# Discussion

## Questions and answers

-   Q: Have you considered using CRDTs to share buffers between threads
    and merge any concurrent edits automatically?
    -   A: While mathematically correct, CRDT does not always produce a
        useful answer. With different packages, this will the issue: not
        a useful result.
        [https://www.moment.dev/blog/lies-i-was-told-pt-1](https://www.moment.dev/blog/lies-i-was-told-pt-1)
-   Q: Why hosted on GitHub? GitHub is nonfree. Is it possible to report
    bugs/send patches without using GitHub?
    -   A: Email patches are possible. Github is what the speaker knows.
-   Q: Do you think it\'s possible to achieve 100% compatibility with
    current emacs code? 
    -   A: Most should be compatible (since elisp package is the biggest
        emacs strength) but there might be differences on purpose.
-   Q: \<janneke\> troyhinckley: so you\'re re-implementing elisp in
    rust?  have you considered using a more modern lisp, such as scheme?
    \[11:03\]
    -   A: No actually. Only trying to reimplementing the C part of
        emacs, replacing it by rust. There are two other talks in the
        conference to use something else (guile and scheme).
-   Q:\<lounge-681\> can remacs be reused?
    -   A: Some of the code and some of the ideas (documentation, ideas
        and approach to problems) were taken. But different model: in
        remacs everything is an external type. Here, instead trying, to
        use the builtin type reimplementating the objects instead.
-   Q: \<apiraino\> hello, great talk, fascinating topic! I am a
    contributor of the compiler team of the Rust prog. language (though
    I don\'t delve in the code myself). Do you have specific features
    from the Rust compiler that are missing (or are nightly-only) that
    you would take advantage of?  10:05:38 
    -   A: Polonius: the new borrow checker. Would solve
        lifetime-tracking issues. A better tracking mechanism would be
        better.
    -   A: Enum with variant types to avoid boilerplate
        [https://github.com/rust-lang/lang-team/issues/122](https://github.com/rust-lang/lang-team/issues/122)
    -   A: Allocator API could be better (still nightly-only)
    -   A: \<apiraino\> thanks! Dont forget to fill out the survey :)
        [https://blog.rust-lang.org/2024/12/05/annual-survey-2024-launch.html](https://blog.rust-lang.org/2024/12/05/annual-survey-2024-launch.html)
-   Q: What are you thoughts on the GUI layer. Any plans on how to
    reimplement it?
    -   A: Either GTK+ or direct GUI in Rust, but no concrete plan so
        far.
-   Q: \<ramin\> (not a question) Re. the GUI layer, the Gtk project has
    automated bindings with a framework called \"GObject
    Introspection,\" which is what I am using for my \"Gypsum\" project.
    Probably Rust has a GObject Implementation which you could use.
    -   A: Problem with Rust GUIs very new and mostly demo without
        accessibility and test in all environements.
-   Q: If money could fix the problem, how much would it cost to ship
    this with feature parity before 2026?
    -   A: Probably needs a couple people and more than one year of
        work. Lots of testing required to fix all bugs.
-   Q: \<janneke\> troyhinckley: elisp is implemented in c, so if
    you\'re not implementing elisp in rust, are you using/keeping the c
    implementation of elisp?
    -   A: Idea of the project is to keep the Elisp layer and changing
        the C layer underneath that is currently called, replacing it by
        rust. Elisp does not change. Plan is to be even be bug
        compatible to emacs: Elisp should be perfectly compatible with
        both C and rust. Elisp is fixed in this approach.
-   Q: \<ramin\> sorry if you already discussed this, but will your Rust
    implementation also be able to run Emacs bytecode? Or are you
    implementing it at the Lisp level?
    -   A: Bytecode interpreter already exists (actually bytecode
        compiler and interpreter was bootstrapped first as it is
        implemented in Elisp).
    -   A: the bytecode is missing some OP-code that have not been
        encountered so far.
-   Q: Cool, so will you also provide bytecode JIT compilation via
    \"libgcc\" the way Emacs currently does?
    -   A: Eventually maybe, but a proper JIT would be better as it
        includes type information to better optimize the code.
-    Q: Is it possible to bootstrap without the interprerter?
    -   A: having only bytecode does not work, as some part are expected
        to be interpreted with macros containing functions that are not
        yet defined. You really need an interpreter for the lazy macro
        expansion.
-   Q: How would you do the native module system?  What would be
    different?  Sounded like part of an anwer about Rust Emacs modules
    got cut off.
    -   A: There is an FFI, so it should be possible to have the same
        thing. Could possibley implement FFI in elisp.
-   Q:  \<ramin\> That was me who was discussing with you about
    bootstrapping Scheme! (Not Guile, R7RS Scheme) Yes, it would be a
    whole other thing than what you have done so far. But it would be
    cool, because then you would be able to run the \"Gypsum\" editor on
    top of your Emacs engine.
    -   A: \<troyhinckley\> I still think that would be really cool to
        get working! we will have to collaberate on that more.

## Notes

-   \<Psionic\`\> Getting good vibes from this Rust work
-   \<NullNix\> (you can do the offscreen-cursor thing in current emacs
    with enough
-                       effort. see scroll-in-place.el.)
-   \<Psionic\`\> Oooooh flow images.  My last expectation was Rust
    making Dslide
-                        image animations slick
-   \<sctb\> troyhinckley: Very cool talk! 
-   \<\[\> I recommend
    [https://codeberg.org/](https://codeberg.org/)
    (as a freedom-respecting github
-           replacement)
-   \<NullNix\> one big problem with using gtk \-- there is a
    \*two-decade-old\* unfixed bug in gtk where it keeps permanent
    references to the x server etc (IIRC, its wayland support has
    similar problems). this means a gtk emacs \--daemon crashes if you
    connect to an x server and then close the x server down. this
    is\.... unfortunate



[[!inline pages="internal(2024/info/rust-after)" raw="yes"]]

[[!inline pages="internal(2024/info/rust-nav)" raw="yes"]]