Live data from Hacker News

Remacs – A community-driven port of Emacs to Rust

github.com

81–90 of 181 posts

Re: Remacs – A community-driven port of Emacs to Rust

#81
post #22

Earlier quoted context omitted.

In response to the general critiques of "Why rewrite emacs at all!?", I believe there are hidden benefits to an incremental rewrite to Rust executed this way. First is that remacs has been able to reduce the amount of non-Elisp code in the editor needed to implement a number of different features. It was able to do this by replacing hand rolled C functionality with high quality crates from cargo, or code in the stand…

There is a huge amount of C code in Emacs that already isn't using the standard C library. As an example, the other day I noticed that Emacs has its own hand rolled implementation of mkstemp(). Unsurprisingly, the Emacs version uses a less secure implementation, so the custom implementation is of no value. A lot of people have already written about the difficulty of getting changes to fix things like this (or elimina…

If it's hard to upstream code in emacs, doesn't that improve the case for a rewrite/fork?

Re: Remacs – A community-driven port of Emacs to Rust

#82
post #5

This looks like a lot of work for what amounts to very little end-user benefit. Honestly, I'd rather see more progress on the Emacs Lisp/Guile migration than on a putative C/Rust migration. At least with the Guile switch, it's something that will have an obvious (and probably positive) impact on the people that use the editor.

Absolutely agree. Focus on porting the core Linux daemons so we can get C out of the business of parsing remotely provided data.

Re: Remacs – A community-driven port of Emacs to Rust

#83
I've made $64,000 so far this year working online and I'm a full time student. Im using an online business opportunity I heard about and I've made such great money. It's really user friendly and I'm just so happy that I found out about it. Heres what I do, •••••>>http://www.joinmate2.com

Re: Remacs – A community-driven port of Emacs to Rust

#84
post #5

This looks like a lot of work for what amounts to very little end-user benefit. Honestly, I'd rather see more progress on the Emacs Lisp/Guile migration than on a putative C/Rust migration. At least with the Guile switch, it's something that will have an obvious (and probably positive) impact on the people that use the editor.

People work on what they want to, a lot of times without much regard for the user.

Re: Remacs – A community-driven port of Emacs to Rust

#85
post #5

This looks like a lot of work for what amounts to very little end-user benefit. Honestly, I'd rather see more progress on the Emacs Lisp/Guile migration than on a putative C/Rust migration. At least with the Guile switch, it's something that will have an obvious (and probably positive) impact on the people that use the editor.

My initial thought was that if you want to rewrite emacs, why not rewrite it in common lisp? Apparently there are a few cl editors/ides - along the "original emacs" path - but like all things GNU I gather GNU Emacs is more than "just" (a) Free Emacs.

Now, there's a fairly recent (and active) project for implementing a common lisp in c++[clasp] -- perhaps making a real common lisp in rust would make sense?

[clasp] https://github.com/drmeister/clasp

Re: Remacs – A community-driven port of Emacs to Rust

#86
post #56

Earlier quoted context omitted.

I didn't quite get it. Do you mean that Boeing is built by independent people who work on whatever they want to and then a plane is assembled of that independently built parts and no one takes the responsibility of the result? Or you mean that Boeing is subcontracting particular work to independent firms serving as architect, coordinator, and sponsor and taking all the responsibility?

> "Do you mean that Boeing is built by independent people who work on whatever they want to and then a plane is assembled of that independently built parts and no one takes the responsibility of the result?" Somewhere in the middle. If you consider the work that goes into making a plane, you'll see quite a bit of it happens outside Boeing. To give one example, think of the aluminium that goes into the plane. Boeing d…

Great video, thank you! Yes, most of the work is done outside of Boeing, but it is done specially for Boeing, not that people work on whatever sort of aluminum they want but they know Boeing demand and supply them with the particular sort. On the other side Boeing pay them money so they can proceed to mine. This is what I mean under the collaboration.

Re: Remacs – A community-driven port of Emacs to Rust

#87
post #80

Earlier quoted context omitted.

I don't know if it's a priority but it would be cool to see rendering speed improved.

That's an odd expectation to have. I would think rendering speed would stay the same or increase a bit; a lot of hand optimizations are going disappear.

Considering the age of Emacs's source code, I'd imagine there would be a lot of code that used to be optimal when it was written, but isn't any more (Sort of how replacing a lot of instances of Duff's Device in Xfree86 with memcpy has sped it up).

Re: Remacs – A community-driven port of Emacs to Rust

#88
post #35
post #11

Earlier quoted context omitted.

I intended it more as a friendly suggestion or observation than anything else. Looking at the Github README, I see a lot of enthusiasm for Emacs and Rust, but not much justification for the (tremendous) effort of a port. Losing site of the value produced in the end result seems like the kind of 'software engineer mistake' I've made myself (many times) in the past. In any event, I think we would do volunteers a disser…

As an Emacs user one could see zero gain in this effort. But new languages like Rust do benefit (I believe) from this kind of projects: new libraries may be create for this port that could be useful for completely new applications. Also, it's more users/testers for Rust, which is always a good thing for their community.

Another thing is that having large-scale successful projects make Rust a more likely language for other people to choose when creating a new project themsleves.

"It's a neat language, but no one has used it to make anything that isn't a toy" is a really common mindset for the people who make such decisions.

The only way to change that mindset is for the evangelists to write software and show that yes, it is possible to write For Realsies software in that language. If that happens to be a rewrite of a successful project, fine - it's still a large project, and it'll inspire more development than someone coming out of nowhere with a project.

Re: Remacs – A community-driven port of Emacs to Rust

#89

Doesn't seem to have a copyright assignment policy in place so this can't be upstreamed as is. https://www.gnu.org/software/emacs/manual/html_node/emacs/Co... So opened - https://github.com/Wilfred/remacs/issues/238

I wish one day the FSF would actually show genuine trust in their GPL and ditch their requirement for people to provide copyright assignments. God knows how many GPLed lines of code has not been submitted back upstream to them over this minor technicality, and that's such a shame. I honestly think this is for the FSF to fix, not everyone else.

As I understand it, it's not lack of trust, but rather that if a legal dispute occurs, it's easier if only one party is the copyright holder rather than having to find hundreds of developers scattered around the world.

Re: Remacs – A community-driven port of Emacs to Rust

#90
post #22

Earlier quoted context omitted.

In response to the general critiques of "Why rewrite emacs at all!?", I believe there are hidden benefits to an incremental rewrite to Rust executed this way. First is that remacs has been able to reduce the amount of non-Elisp code in the editor needed to implement a number of different features. It was able to do this by replacing hand rolled C functionality with high quality crates from cargo, or code in the stand…

As more of an admin kind of guy, i find this explosion of language specific repositories worrying. I have already had to deal with python code that do little to no dependency documentation, that just carpet bomb my system with stuff pulled from the net at the install stage.

It really does surprise me that languages come with their own package managers. In most linux contexts, there's really no need for it since linux distributions come with package managers.

Part of me feels like a better solution is to maintain older branches to give distributions opportunity to catch up.

Post reply on HN