diff options
Diffstat (limited to '2024/talks/rust.md')
| -rw-r--r-- | 2024/talks/rust.md | 115 |
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"]] |