Continued progress porting Emacs to Rust • Hacker News Board

Re: Continued progress porting Emacs to Rust

#21

Post by badcede » Wed, Oct 10, 2018, 1:30 PM UTC

ealhad wrote: post #4

To anyone wondering why this might be a good idea, there are some interesting comments in a GitHub issue ( https://github.com/Wilfred/remacs/issues/305 ): > For users, I hope Remacs will be faster (it's easier to optimise), more robust (we have stronger type checks and the ability to add unit tests), better documented (see #262) and somewhat more featureful (we have some ideas for solving the dumper problem that woul…

An even better chance is that this project will turn those young developers into old ones.

Re: Continued progress porting Emacs to Rust

#22

Post by rauhl » Wed, Oct 10, 2018, 1:36 PM UTC

mrec wrote: post #12

Not an Emacs user, so forgive me if I'm being dense, but is this (from the README) really true? Emacs will change how you think about programming. Emacs is an incremental programming environment. There's no edit-compile-run cycle. There isn't even an edit-run cycle. You can execute snippets of code and gradually turn them into a finished project. There's no distinction between your editor and your interpreter. I'm as…

Yes, it’s true — and it’s not just true of elisp (which is a decent language) but also of Common Lisp, Python, Scheme and others. It’s probably most true of elisp, because the editor itself is written in elisp, but one gets something of the same tight edit-execute cycle in those other languages too.

Once you’ve been there, you’ll probably never want to go back. My only wish is that emacs were written in an even better language than elisp (like Common Lisp).

Re: Continued progress porting Emacs to Rust

#23

Post by serhart » Wed, Oct 10, 2018, 1:39 PM UTC

bachmeier wrote: post #13

mrec wrote: post #12

Not an Emacs user, so forgive me if I'm being dense, but is this (from the README) really true? Emacs will change how you think about programming. Emacs is an incremental programming environment. There's no edit-compile-run cycle. There isn't even an edit-run cycle. You can execute snippets of code and gradually turn them into a finished project. There's no distinction between your editor and your interpreter. I'm as…

My interpretation is that it's not a statement about writing code but running it. It's accurate IMO but probably not terribly important in the grand scheme of things. > I doubt many non-Emacs users are particularly interested in programming Emacs Lisp By definition, if you're programming Emacs Lisp, you're an Emacs user. Emacs is the interpreter.

> By definition, if you're programming Emacs Lisp, you're an Emacs user. Emacs is the interpreter.

That's not necessarily true. Guile supports Elisp as a language. You can write Elisp sans Emacs.

Re: Continued progress porting Emacs to Rust

#24

Post by rauhl » Wed, Oct 10, 2018, 1:41 PM UTC

wscott wrote: post #5

And there are related efforts to upgrade the lisp used in emacs to a more modern and standardized version. I think it is GuileEmacs I am remembering. I hope to two efforts are compatible.

Although Scheme has a standard, I wouldn’t really call Guile ‘more modern and standardised’: Guile has no standard (it extends the Scheme standard in incompatible ways), and ‘modern’ is hard to define. Emacs Lisp added lexical scope in the past couple of years, probably more recently than Guile added a new language (as opposed to library) feature — is that modern enough?

I wouldn’t imagine that the two efforts are compatible, because they are both efforts to rewrite the Emacs Lisp engine in another language, one in Rust & one in Guile Scheme. It’s possible that one might be able to call over to the other, through its CFFI.

I’d like to see Emacs rewritten in Common Lisp, and so I’d prefer a Rust engine to a Guile engine: Rust is a static language, and a Rust engine is unlikely to lead to Rust-extensible Emacs code, while a Guile engine is likelier to lead to Guile-extensible Emacs code, which is completely the wrong direction IMHO.

Re: Continued progress porting Emacs to Rust

#25

Post by wiz21c » Wed, Oct 10, 2018, 2:03 PM UTC

ams6110 wrote: post #19

Emacs rather famously has a build process that involves first compiling a minimal elisp environment (written in C and maybe some assembly) that then loads all the editing routines (which are written in elisp) and then dumps itself out as a binary (to save the load time, which is substantial, on subsequent start-ups). I assume the Rust-based emacs would do the same thing?

not sure, but I guess that process is to make sure Emacs can be built from scratch, ie without relying on proprietary software.

Re: Continued progress porting Emacs to Rust

#26

Post by ealhad » Wed, Oct 10, 2018, 2:14 PM UTC

rauhl wrote: post #22

mrec wrote: post #12

Not an Emacs user, so forgive me if I'm being dense, but is this (from the README) really true? Emacs will change how you think about programming. Emacs is an incremental programming environment. There's no edit-compile-run cycle. There isn't even an edit-run cycle. You can execute snippets of code and gradually turn them into a finished project. There's no distinction between your editor and your interpreter. I'm as…

Yes, it’s true — and it’s not just true of elisp (which is a decent language) but also of Common Lisp, Python, Scheme and others. It’s probably most true of elisp, because the editor itself is written in elisp, but one gets something of the same tight edit-execute cycle in those other languages too. Once you’ve been there, you’ll probably never want to go back. My only wish is that emacs were written in an even bette…

> My only wish is that emacs were written in an even better language than elisp (like Common Lisp)

There are a lot of bad things in CL too, unfortunately. I wonder if a Lisp will become really popular in the near future. Maybe Racket?

Re: Continued progress porting Emacs to Rust

#27

Post by pulisse » Wed, Oct 10, 2018, 2:14 PM UTC

flurrything wrote: post #9

ealhad wrote: post #4

To anyone wondering why this might be a good idea, there are some interesting comments in a GitHub issue ( https://github.com/Wilfred/remacs/issues/305 ): > For users, I hope Remacs will be faster (it's easier to optimise), more robust (we have stronger type checks and the ability to add unit tests), better documented (see #262) and somewhat more featureful (we have some ideas for solving the dumper problem that woul…

> For users, I hope Remacs will be faster The main reason my emacs is painfully slow is that most elisp code blocks. Stuff like hitting tab for auto-completion might perform a blocking query from a language server hanging emacs for multiple seconds. Opening a file tries to start a language server and blocks the editor in the process. Etc. Making emacs itself faster won't make the experience of working with emacs any…

> The main reason my emacs is painfully slow is that most elisp code blocks.

Note that multithreading is now in Emacs master, and some core packages (e.g., Tramp, which used to block when opening a remote file) have already been updated to make use of it, so starting with the next major release things will be improving on this front.

Re: Continued progress porting Emacs to Rust

#28

Post by justinhj » Wed, Oct 10, 2018, 2:18 PM UTC

wscott wrote: post #5

And there are related efforts to upgrade the lisp used in emacs to a more modern and standardized version. I think it is GuileEmacs I am remembering. I hope to two efforts are compatible.

It’s a mistake to replace emacs lisp. For a start everyone’s custom code and configurations would have to be modified or scrapped. Package libraries would have to be ported. Much better to just improve it in a backwards compatible way or with libraries. Both of which are happening.

Re: Continued progress porting Emacs to Rust

#29

Post by db48x » Wed, Oct 10, 2018, 2:19 PM UTC

ams6110 wrote: post #15

flurrything wrote: post #9

Earlier quoted context omitted.

> For users, I hope Remacs will be faster The main reason my emacs is painfully slow is that most elisp code blocks. Stuff like hitting tab for auto-completion might perform a blocking query from a language server hanging emacs for multiple seconds. Opening a file tries to start a language server and blocks the editor in the process. Etc. Making emacs itself faster won't make the experience of working with emacs any…

Emacs does block on many operations, but I've never had it be really noticeable on tab-completion type stuff. Though I only use auto-complete on emacs commands, so maybe I've just missed it.

It depends quite a lot on what kind of autocompletion you're using, for which language. It's a mixed bag.

Re: Continued progress porting Emacs to Rust

#30

Post by db48x » Wed, Oct 10, 2018, 2:21 PM UTC

tom_mellior wrote: post #20

The author misunderstands some parts of the C language, in particular related to static variables. "In fact, these aren't just file globals accessible to only one translation unit, these are static variables that are accessible across the whole program." gets the meaning of C's static exactly backwards: C file-scope static variables are only accessible (by name) in their translation unit; all other file-scope variabl…

You are entirely correct, and I should perhaps have been more precise. However, because Lisp_Objfwd is basically a pointer, zero-initialized is pretty much as good as uninitialized. It's not a useful value.