add gypsum, rust Q&A

1 files changed, 115 insertions, 0 deletions

diff --git a/2024/talks/rust.md b/2024/talks/rust.md
index e994d28f..ce72ffa2 100644
--- a/2024/talks/rust.md
+++ b/2024/talks/rust.md
@@ -26,6 +26,121 @@ 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){rel="noreferrer noopener"}
+-   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){rel="noreferrer noopener"}
+    -   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){rel="noreferrer noopener"}
+-   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/){rel="noreferrer noopener"}
+    (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"]]