11 ms·
Announcing Remacs: Porting Emacs to Rust
- dman 10y agoHow long before someone decides to port LLVM and jemalloc to rust? :)
- Semiapies 10y agoBold! Practical, however, I have no idea whatsoever about.
- noway421 10y agoRust 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++
- hacker_9 10y agoIf you base your insight on HN articles, then yes it would appear that way.
- sidlls 10y agoOnly 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.
- cmrdporcupine 10y agoI was programming in Python in 1996 and struggled to find anyone to pay me to work in it. Meanwhile it's now 2017 and it's only now a fully mainstream language for the last 5 years or so. It takes a while. (I lost interest in Python in early 2000s, and then it got popular. So if I lose interest in Rust it's bound to get popular.)
- i336_ 10y agoI 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 10y ago> 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_ 10y agoYou'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.
- gcp 10y agoMeanwhile, "in the wild," it's hard to find a person who does systems programming and has even heard of Rust I agree that it's hard to find people who do systems programming, but those I know have mostly heard of Rust. There isn't much else of anything happening in that space aside from C++ iterations.
- pjmlp 10y agoWhile I am a big fan of Rust, that is not quite true. Rust still needs to improve its compile times and IDE related tooling, to make it appelative to the enterprise coder used to the comfort of Java / .NET tooling + C++ for lower level stuff.
- miloshadzic 10y agoI like the language but this amount of hype can only backfire.
- moomin 10y agoThe 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__ 10y agoThat's not true. Like any old codebase it's got its sketchy corners, but it's certainly not "horrible".
- zaphar 10y agoEmacs 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.
- kahrkunne 10y agoEmacs has some design decisions that are the result of 20 years of concessions on a ton of different platforms, and some of those are questionable anno 2017. Emacs' actual codebase definitely isn't bad.
- moomin 10y agoTo clarify: I'm not saying that locally the code is bad, I'm more talking about the kind of macro issues outlined in Buttery Smooth Emacs. But it's these kind of things that will be harder to "fix" in a port.
- krallja 10y agoWhat happened in 1997? There's stuff from (GNU Emacs) 1985 / (Emacs) 1976.
- nodivbyzero 10y agoGood luck!
- gregpardo 10y agoSo it has about 10 rust files so far?
- deleted 10y ago[deleted]
- jlarocco 10y agoMeh. 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 10y agoIsn't the point of this port to work out-of-the-box with existing elisp?
- jswny 10y agoYes but the commenter that you replied to was indicating that he would only care if a rewrite was done in Common Lisp so that Common Lisp could replace ELisp.
- petecox 10y agoI thought the plan was to port emacs lisp to the Guile interpreter and, in the process, make Scheme a first-class citizen for scripting. https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs
- pandeiro 10y agoI 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-development/ http://www.wilfred.me.uk/blog/2016/07/30/example-driven-deve...
- fafner 10y agoThe example seems to be wrong https://github.com/Wilfred/remacs#porting-c-functions-to-rust-walkthrough https://github.com/Wilfred/remacs#porting-c-functions-to-rus... 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.
- jdub 10y ago> However unless GNU Emacs is willing to accept the Rust replacement code I don't think this will succeed. There are many kinds of success. :-)
- i336_ 10y ago> 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...)
- webkike 10y agoSounds like fun, I'm in.
- kahrkunne 10y agoEmacs 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.
- gkya 10y agoEmacs 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.
- lugus35 10y agoWhy 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 ?
- lisivka 10y agoBecause GPL license protects from stealing of code without contributed back. Apple chose FreeBSD as base for it OS, Google chose Linux. Look at sad state of FreeBSD now.
- kod 10y agoIf 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 10y agoYou 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.
- berry_sortoro 10y agoI have some questions: 1. I heared RMS does not like OOP and is the original author of Emacs. Is emacs written without OOP? 2. Will the rust port use OOP?
- geff82 10y agoWhat a waste of time.
- jyriand 10y agoOver the years I have see a number of posts about revamping emacs. Is there anything that actually works?
- pja 10y agoAtom 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.
- integricho 10y agoPeople 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 10y agoCounterpoint: 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!
- alfalfasprout 10y agoSeriously. Next thing you know there will be a Rust-based BLAS.
- merb 10y agoIsn't there already another project, creating a OS with rust?