The example seems to be wrong <a href="https://github.com/Wilfred/remacs#porting-c-functions-to-rust-walkthrough" rel="nofollow">https://github.com/Wilfred/remacs#porting-c-functions-to-rus...</a><p>fn Fnumberp(object: LispObject) -> LispObject {
if lisp::SYMBOLP(object) {
unsafe {
Qt
}
} else {
Qnil
}
}<p>It uses SYMBOLP instead of NUMBERP. Highlighting the risk of introducing new bugs.<p>Which leads to the question, why Remacs can't just auto-wrap the lisp::* functions, which I assume are the Rust versions of the C Macros. If you look at Emacs' C code there are a lot of functions and macros that implement Elisp primitives in a C way. E.g., NUMBERP(x) will return 1 if x is a number or else 0. So you can use this function to deal with lisp objects in C code. The function that exports this primitive to elisp is Fnumberp. Rust has a better type system than C and supports meta-programming. So why not have a simple wrapper that can take a (LispObject) -> bool and turn it into a (LispObject) -> LispObject. Similar for other Elisp<->Rust types.<p>However unless GNU Emacs is willing to accept the Rust replacement code I don't think this will succeed. It is a lot of work and it takes quite some time until it actually pays off. It seems simpler to do what GCC and GDB have done and switch from C to (a strict subset of) C++ to simplify at least some of the more painful C hackeries.<p>And the reasoning given in the announcement are rather weak:<p>* "We can leverage the rapidly-growing crate ecosystem." Emacs recently added module support allowing leveraging all kinds of ecosystems<p>* "We can drop support legacy compilers and platforms (looking at you, MS-DOS)." how is that an opportunity when it effectively removes support for platforms.
Emacs needs its stuff moved into Elisp as much as possible, and its Elisp to be improved, not a port of the C stuff to some random language. Rust is not a standardised language and is mostly driven by a single entity. Totally not the right tool. Also I find it very cryptic.
Meh.<p>As a long time Emacs user, the only way I'd even consider switching off of GNU Emacs would be if there was a port written in Common Lisp that replaced ELisp with Common Lisp. Even then, I'd only switch if it had replacements for the ELisp modules I use (ERC, Slime, C++-mode, etc.).<p>As an end user, I don't see any advantages in switching to yet another Emacs rewrite in yet another low level language.
I really love the idea and style of this blog post and the project's README. I recognized the style from somewhere and then realized it was the same author as "Example Driven Development"[1], another one that showed up on HN a while back.<p>[1]: <a href="http://www.wilfred.me.uk/blog/2016/07/30/example-driven-development/" rel="nofollow">http://www.wilfred.me.uk/blog/2016/07/30/example-driven-deve...</a>
People should stop rewriting huge codebases that work quite well into the next hype-language. There's absolutely nothing wrong to develop it in C or C++. Stop the hype-train.
Rust is becoming such a huge systems development language, that's so good to hear that finally the developers are getting better deal for performant applications instead of C/C++
The problem, of course, being that Emacs has become a horrible codebase to maintain 20 years of compatibility, and rewriting is unlikely to change that.
Why use a GPL license ? This kind of port could have been the occasion to get rid of this type of license.<p>Why port Emacs to Rust ?, it adds no value to users. Why not develop a modern GUI like Intellij IDEA with a Common Lisp implementation underneath like SBCL ?
Emacs is already struggling with a lack of core developers; porting it to a relatively obscure language won't alleviate that. I'd rather people help out with Emacs proper than doing silly stuff like this.<p>I know Rust fans are passionate, but we don't <i>really</i> need "X, but in Rust" for every value of X.