Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Continued progress porting Emacs to Rust

db48x.net

Post reply on HN
Print view View original

31–40 of 60 posts

Re: Continued progress porting Emacs to Rust

#31

Post by db48x »

bjornedstrom wrote: post #7
OskarS wrote: post #3

When I first heard of this project I thought "Well, that's insane, it will never be finished, and will surely be abandoned in six months". Glad to hear that it's making good progress! I love it when I'm wrong about stuff.

Remember that most of Emacs is written in Emacs Lisp. If you take the entire source code distribution, around 15% of it is written in C. Those 15% are of course fairly complex, however it's at least less code than you may think.

Yes. The last time I looked, it was about a million lines of elisp, and only about a hundred thousand of C. We'll have it cleaned up in no time.

Re: Continued progress porting Emacs to Rust

#32

Post by db48x »

wiz21c wrote: post #25
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.

The build process of Emacs doesn't rely on any proprietary software. But it is quite complex :)

Re: Continued progress porting Emacs to Rust

#33

Post by db48x »

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?

We still use the same unexec process as normal Lisp, not because we really like it but because it's easier to make small changes. It really is a defect attractor though (I even introduced one a few months back, and had to debug it), so we do want to simplify it.

Re: Continued progress porting Emacs to Rust

#34

Post by lispm »

ealhad wrote: post #26
rauhl wrote: post #22

Earlier quoted context omitted.

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?

There are 'bad things' in any programming language.

Common Lisp is actually quite a bit more advanced out of the box than Emacs Lisp: lexical binding, excellent error handling, good support for compilation, extensive object-oriented features, it has multiple implementations with independet code bases, implementations with threading, ...

CL has been used to develop Emacs editors already.

But the thing is a non-starter. There are a few million lines of Emacs Lisp for a specific editor, which nobody will rewrite.

Re: Continued progress porting Emacs to Rust

#35

Post by lottin »

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…

> make it more appealing to young developers

In that case, they should rewrite the Lisp code in JavaScript.

Yes, I'm being sarcastic.

Re: Continued progress porting Emacs to Rust

#37

Post by danaliv »

db48x wrote: post #30
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.

It fails a NULL check, where an uninitialized value (probably) won’t. That seems like a pretty important distinction, no?

Re: Continued progress porting Emacs to Rust

#38

Post by beagle3 »

db48x wrote: post #30
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.

The C spec says zero in a pointer context is null (and the other way around)

Can you elaborate on “as good as uninitialized”?

Re: Continued progress porting Emacs to Rust

#39

Post by rauhl »

lispm wrote: post #34
ealhad wrote: post #26

Earlier quoted context omitted.

> 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?

There are 'bad things' in any programming language. Common Lisp is actually quite a bit more advanced out of the box than Emacs Lisp: lexical binding, excellent error handling, good support for compilation, extensive object-oriented features, it has multiple implementations with independet code bases, implementations with threading, ... CL has been used to develop Emacs editors already. But the thing is a non-starter…

Emacs Lisp has lexical binding these days.

I’d like to see an Emacs with a Common Lisp core, and an elisp execution engine to run all the legacy elisp code. https://github.com/blindglobe/clocc/blob/master/src/cllib/el... looks like a decent first start, although it supports an older version of elisp.

Someday if I have the free time I’d love to spend time working on such a thing. Maybe when I’m retired!

Re: Continued progress porting Emacs to Rust

#40

Post by dkarl »

rauhl wrote: post #24
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 co…

it extends the Scheme standard in incompatible ways

What does "incompatible" mean here? Incompatible with the Scheme language reports, or incompatible with other Schemes' extensions?

Post reply on HN