
Announcing Remacs: Porting Emacs to Rust - smg
http://www.wilfred.me.uk/blog/2017/01/11/announcing-remacs-porting-emacs-to-rust/
======
fafner
The example seems to be wrong [https://github.com/Wilfred/remacs#porting-c-
functions-to-rus...](https://github.com/Wilfred/remacs#porting-c-functions-to-
rust-walkthrough)

fn Fnumberp(object: LispObject) -> LispObject { if lisp::SYMBOLP(object) {
unsafe { Qt } } else { Qnil } }

It uses SYMBOLP instead of NUMBERP. Highlighting the risk of introducing new
bugs.

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.

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.

And the reasoning given in the announcement are rather weak:

* "We can leverage the rapidly-growing crate ecosystem." Emacs recently added module support allowing leveraging all kinds of ecosystems

* "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.

~~~
i336_
> _GCC and GDB have ... switch[ed] from C to (a strict subset of) C++ to
> simplify at least some of the more painful C hackeries._

Interesting! Where can I read more about this? Is it true that gcc compiles
using g++? That's rather amusing. :)

> " _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._

Supporting MS-DOS is something of a challenge now. I've not done any research
but I have vague notions that GCC ports aren't really being maintained
anymore. Besides that, many platforms (for example BeOS) are stuck on GCC
2.95.3, a rather famous last version using a particular ABI. A lot of stuff is
stuck on that GCC version. (I don't know many details, although I'm very
interested to learn more if anyone else has any insight.)

With the above said, I do disagree with wholesale willingness to summarily
sweep legacy platforms off the table. Rust has saved itself some maintenance
nightmares because it doesn't support DOS, but it means quite a large number
of people are still stuck on C for industrial control system tooling.
(Granted, I can't deny that I'm talking about a _really_ tiny niche here...)

~~~
pjmlp
Yes it is true, all major C compilers are now written in C++.

You can find everything related to GCC's C++ transition here:

[https://gcc.gnu.org/wiki/gcc-in-cxx](https://gcc.gnu.org/wiki/gcc-in-cxx)

On Windows even the C runtime, MSVCRT.dll got re-written in C++ and the C
functions are actually _extern "C"_ ones.

[https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-
great...](https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great-c-
runtime-crt-refactoring/)

So a kind of small victory for us on the C++ side of the fence on the endless
C vs C++ discussions.

Now the joke "my compiler compiles yours" has been reversed.

~~~
i336_
Wow, that's a surprise.

I'm really considering learning C++ now... I'm just hugely put off by the long
compile times :( (I have 10+ year old hardware)

~~~
adrianN
The compile times are not that long unless your program is very big. I also
have 10 year old hardware.

~~~
i336_
I'd edit this into the original comment if I could; here seems to be a good
spot to put it.

I think I should add a bit of context about what I mean by slow compile times:
I feel comfortable if I can hit CTRL+S* and have my code rerun or restart
within about half a second. At one second, it should either be executing or
have output something and finished, and if it takes more than about 10 seconds
to get to whatever point I'm prototyping or making a decision on, I get
jittery.

It's partly because I have a ridiculously short feedback loop, but also
because I am (for some reason) sensitive to interactivity latency and I
prioritize responsiveness extremely highly. So long compile times tend to lean
on those buttons and make me uncomfortable.

With this in mind, the only C++ experience I've had yet was doing some
modifications to the Dillo web browser, which was the main web browser I was
running on the 800MHz AMD Duron box I used between 2012-2014 (the same one I
described in
[https://news.ycombinator.com/item?id=13344332](https://news.ycombinator.com/item?id=13344332)).

It was a lot of fun - I modified the tab bar so tabs could be dragged around,
moved between windows, etc :D - but the compile times were around 3 seconds!
This was just for the test harness I built which had an absolute minimum of
code in it; I was also using GCC precompiled headers for literally everything
(my prototype code was a ~300 line .cpp file, no headers or anything). This
was a _really_ big adjustment for someone used to tcc (~10ms compile time) or
gcc (~300ms compile time) who felt that gcc took juuuust a bit too long to do
its thing.

I've seen C and C++ code compile on friends' i3 boxes (haven't seen what an i7
can do yet) and been amazed. I think when I have a machine like that I'll
probably be able to seriously get into the language. (I actually have an i3
here but it had a memory failure several months ago, hopefully I can get some
new DIMMs for it soon and see if the motherboard actually still works.)

\--

* About ^S - I'm yet to play with Emacs which I understand has two keystrokes to save files; I mostly use Vim because it's installed everywhere. I far prefer ^S over ESC (Press)Shift ; (Release)Shift w Return i/a.

~~~
pjmlp
With the failure of Lisp Machines, Lucid pivoted into doing a Lisp like
interactive environment for C++, with compilation at function/method level.
There is an old VHS video that some uploaded to YouTube demoing it. Search for
Lucid C++.

The last version of Visual C++ (v4) used a database repository as binary
representation of C++ code, also offering an interactive experience.

The problem with both environments was that they required powerful hardware
that most people weren't wiling to pay for and consequently died.

Microsoft is now having a smarter linker with db support for VSC++ 2017.

Both Apple and Google were discussing at last LLVM conference how to add
similar capabilities, IDE friendly, to clang, partially based on the Swift
Playgrounds development experience.

~~~
i336_
I think I vaguely recall learning about database-incorporating C++ compilers
recently, and now I actually see them. This is really neat.

I'm definitely looking forward to LLVM getting these capabilities. It'll move
C++ development forward by light years, I reckon. (For example, Chrome takes
an hour to fully rebuild in CI on what I suspect is fairly modern server
hardware.)

------
gkya
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.

~~~
greenspot
Totally agree.

The part of Emacs which needs a ramp-up is the Lisp layer, not the C layer.

When I read this post I just had a big 'why' in my mind.

------
jlarocco
Meh.

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.).

As an end user, I don't see any advantages in switching to yet another Emacs
rewrite in yet another low level language.

~~~
Ar-Curunir
Isn't the point of this port to work out-of-the-box with existing elisp?

~~~
jlarocco
Right. But as an end user there's no advantage to using Remacs over normal GNU
Emacs. "Written in Rust instead of C" isn't a useful feature to me.

Using Common Lisp instead of ELisp would be useful enough that I might switch.

~~~
vvanders
Have you tried to build GNU Emacs on windows? I'd take a Rust port in a
heartbeat.

~~~
Arelius
Yes, I use it every day, at work and at home between different computers. I
have a few windows-nt specific lines in my .emacs, mostly to set paths to grep
and the like but otherwise have no problems and it is pretty indistinguishable
from using it on linux systems.

Could you perhaps elaborate on the problems you are experiencing, since
otherwise I really have no idea what you're talking about.

~~~
majewsky
He said "build", not "use".

------
pandeiro
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.

[1]: [http://www.wilfred.me.uk/blog/2016/07/30/example-driven-
deve...](http://www.wilfred.me.uk/blog/2016/07/30/example-driven-development/)

------
integricho
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.

~~~
sidlls
Counterpoint: having a solid, existing and mature codebase can serve as a
useful tool to learn where and how best to apply a new language's features. As
a bonus, perhaps some improvement in the original system will be recognized!

------
noway421
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++

~~~
sidlls
Only in the HN bubble. Meanwhile, "in the wild," it's hard to find a person
who does systems programming and has even heard of Rust, or if they have, that
has given it serious consideration.

It's too early and too immature a language for all the fawning it gets on HN.

I think if the developers do it right they can snag enough mindshare among new
developers that Rust will be a serious competitor to C and C++ in 10 years or
so. Which is great, because I think it's a better language. But it isn't there
yet.

~~~
i336_
I appreciate this sentiment; I've been very hesitant to explore Rust myself,
it seems too new, too overhyped, and lacking in foundation (or, as you said,
too immature) at this point for me to have absolute confidence in it, or at
least the same level of absolute confidence I'd have in C.

I'm definitely keeping an eye on it though, because if it keeps going at the
same rate it has the potential to be great in 10 years.

But at the same time, flurries of activity aren't universally positive: it
becomes harder to filter out the low-quality contributions that introduce
subtle bugs, and smaller/more strict teams have an easier time maintaining
stringent quality controls.

PHP and JavaScript very rarely segfault either. Sure, they use virtual
machines (PHP's is non-JITed too!); and yes, their CPU and memory usage are
comparatively astronomical. But I can only hope that Rust's memory-safety
doesn't wind up attracting the same kind of unskilled language architecture
"contributions" that PHP has, or wind up with an ecosystem as fragmented as
Node's.

~~~
pcwalton
> But I can only hope that Rust's memory-safety doesn't wind up attracting the
> same kind of unskilled language architecture "contributions" that PHP has,
> or wind up with an ecosystem as fragmented as Node's.

Going from "PHP has memory safety" to "memory safety causes the quality of
code to decrease" is _quite_ a leap.

Haskell also has memory safety.

~~~
i336_
You're right. Let me qualify.

Haskell as an excellent example of a language that, by design, filters out
probably many well-meaning individuals who don't have the requisite level of
high-level skill.

Languages like Java, BASIC, PHP, etc are easy to get started with, which means
those languages attract all types. Perl is somewhat in this class too, along
with C++ due to that language's widespread popularity.

In PHP's case, the language's lack of inherent default-to-paranoia security
settings has bitten it hard, because no real consideration was given to these
phenomena (or apparently anything else, but that's a different story).

It's a nuanced (social) issue, but solving the type safety problem does make
it generally easier not to shoot your foot when you still don't know what
you're doing. The _hope_ is that the programmer steadily advances beyond the
baby-steps/worsethanfailure.com stage - and doesn't build any large systems
that are too big to rewrite before they're decent.

Languages like Haskell, Lisp/Scheme, Erlang, C, assembly language, etc are
_generally_ difficult to do large-scale useful things with unless you've
either studied the language a lot and/or already have programming experience.

------
gregpardo
So it has about 10 rust files so far?

------
merb
Isn't there already another project, creating a OS with rust?

------
moomin
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.

~~~
__david__
That's not true. Like any old codebase it's got its sketchy corners, but it's
certainly not "horrible".

~~~
zaphar
Emacs is one of the few longstanding C codebases I know that compiles almost
entirely without warnings. Which is quite an achievement and speaks somewhat
to it's quality.

------
jyriand
Over the years I have see a number of posts about revamping emacs. Is there
anything that actually works?

~~~
pja
Atom is the “spirit” of emacs, taken into a world where your language of
choice is Javascript & the runtime is the web browser.

Otherwise, not that I’m aware of. Everyone knows that Elisp is horribly
crufty, but getting everyone to shift to a new language requires carrying all
the extensions over which is a huge task.

~~~
pjmlp
To the point that it makes users of a modern PC in 2017 feel like they have
traveled back in time and are using Emacs on a VAX/VMS system.

~~~
pja
Yeah, the size of the binary distribution alone is kind of eye-watering.
Google Chrome as a runtime is not a small dependency.

------
geff82
What a waste of time.

------
Semiapies
Bold!

Practical, however, I have no idea whatsoever about.

------
dman
How long before someone decides to port LLVM and jemalloc to rust? :)

------
lugus35
Why use a GPL license ? This kind of port could have been the occasion to get
rid of this type of license.

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
?

~~~
kod
If you changed the license you'd have to do a clean room implementation, and
even then deal with potential legal issues from the... personalities...
associated with the GPL.

~~~
belorn
You mean the author who wrote his own license to specify how his work may be
distributed?

Any person who write their own license to specify in fine details how the work
may be used and distributed is going to have a very strong (and likely legal)
issue with people who try to circumvent that license. Even a clean room
implementation would need source material as instructions, and writing such
specification without any copyrighted elements of the source would be quite a
challenge when dealing with a very large program that has compatibility to a
large ecosystem as its primary feature.

------
kahrkunne
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.

I know Rust fans are passionate, but we don't _really_ need "X, but in Rust"
for every value of X.

------
nodivbyzero
Good luck!

------
webkike
Sounds like fun, I'm in.

