diff options
Diffstat (limited to '2024/talks/rust.md')
| -rw-r--r-- | 2024/talks/rust.md | 78 |
1 files changed, 44 insertions, 34 deletions
diff --git a/2024/talks/rust.md b/2024/talks/rust.md index 0c1c676f..ebbe4fc1 100644 --- a/2024/talks/rust.md +++ b/2024/talks/rust.md @@ -34,29 +34,29 @@ Hardware Engineer with interest in low-level programming and the hardware-softwa 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) + 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 +- 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 +- 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:\<lounge-681\> can remacs be reused? +- 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: \<apiraino\> hello, great talk, fascinating topic! I am a +- 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 + 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 @@ -65,15 +65,15 @@ Hardware Engineer with interest in low-level programming and the hardware-softwa - 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 :) + - 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: \<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. +- 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. @@ -81,15 +81,15 @@ Hardware Engineer with interest in low-level programming and the hardware-softwa 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 +- 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: \<ramin\> sorry if you already discussed this, but will your Rust +- 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 @@ -98,7 +98,7 @@ Hardware Engineer with interest in low-level programming and the hardware-softwa - 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? + "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? @@ -111,36 +111,46 @@ Hardware Engineer with interest in low-level programming and the hardware-softwa 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 +- 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 + 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. - + - 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 -- \<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 +- 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) -- \<NullNix\> one big problem with using gtk \-- there is a + (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 [[!inline pages="internal(2024/info/rust-after)" raw="yes"]] |