diff options
Diffstat (limited to '')
| -rw-r--r-- | 2024/talks/rust.md | 126 |
1 files changed, 126 insertions, 0 deletions
diff --git a/2024/talks/rust.md b/2024/talks/rust.md index e994d28f..29567813 100644 --- a/2024/talks/rust.md +++ b/2024/talks/rust.md @@ -26,6 +26,132 @@ 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) + - This question answer about CRDT's is by itself showing a lot of problem awareness +- 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: 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: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: 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: 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: (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: 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: 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: 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: I still think that would be really cool to + get working! we will have to collaborate on that more. +- Q: elisp is implemented in c, so if you're not implementing elisp in rust, are you using/keeping the c implementation of elisp? + - IRC: of course they are implementing elisp in rust (?), what else could they mean? + - I think they misunderstood your question + - (not yet answered)? + +## Notes + +- Getting good vibes from this Rust work +- (you can do the offscreen-cursor thing in current emacs + with enough effort. see scroll-in-place.el.) +- Oooooh flow images. My last expectation was Rust + making Dslide image animations slick +- troyhinckley: Very cool talk! +- I recommend + [https://codeberg.org/](https://codeberg.org/) + (as a freedom-respecting github replacement) +- 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 +- I had not thought about the fact that we could just mutate functions on the fly just like data. Neat! +- really good talk! +- Getting good vibes from this Rust work +- I'm spending half this talk going OOH and wishing we had this in current emacs +- Very cool talk! +- So looking forward to a faster multi-threaded Emacs :D +- Well, it does sound like we need some scale to turn this from a multi-year idea to a next-year idea +- ruby shows one advantage here -- they're reimplementing bits of the ruby C core in ruby, and *speeding it up* because their new jitter then sees the insides of it and can optimize the hell out of it. ruby is, of course, famously slow... but not as slow as elisp :) + - one wonders if emacs could benefit similarly... +- 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 +- yeah "of course" all new emacs efforts should be able to run elisp code; but it would be awesome if new lispy code could be written in scheme +- YouTube comment: Really interesting approach. I like the humility in the beginning, the likes of "this is to try new approaches". [[!inline pages="internal(2024/info/rust-after)" raw="yes"]] |