Live data from Hacker News

Remacs – A community-driven port of Emacs to Rust

github.com

61–70 of 181 posts

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

#61

Earlier quoted context omitted.

(I hope I'm not misunderstanding your concern), but a quick search reveals that Rust prefers to statically link, so in this case, remacs would distribute as a 'single' binary. Only the developers (of remacs) would need all the dependencies/crates.

This creates its own headaches as a fix for the next Heartbleed becomes not "upgrade this one shared library", but "upgrade these dozens of individual programs when an update becomes available".

Programs all need to update all the time anyway.

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

#62
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.

Python has/had a terrible packaging story though. As you said, dependencies weren't really documented. Rust, on the other hand, documents all dependencies in Cargo.toml. And dependencies can easily be parsed from Cargo.toml without the need to execute any code (as would be required in the case of python)

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

#63
post #28
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.

STOP/ I just think that before judging remacs everyone had to read this blogpost: http://www.wilfred.me.uk/blog/2017/04/30/remacs-talk-transcr...

gotta love this line:

"We aim to be a drop-in replacement with bug-for-bug compatibility."

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

#64
post #60

Earlier quoted context omitted.

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.

with python the rule should to be to run every deployment at least in its own venv.

That's not so practical if the application is a text editor, or some other administration tool (debugging, statistics etc).

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

#65

Some speculatively useful things that could arise out of this - It may have useful security properties over time. People use emacs for a great deal of arbitrary text reading and transform from things directly from email and the web. Elisp would largely be at fault for security bugs but perhaps this would help in areas. Perhaps a binding to use Alacritty directly for a port to Wayland? Emacs has a pretty terminal cent…

Most security holes in my setup aren't likely to go away. I trust Emacs. And I trust it to do as I say. This means coordination my identity to many servers at a time. Executing directly on the box. Even remote boxes.

I'm open to be surprised. But I really do want Emacs to have full access to my computer.

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

#66
post #56

Earlier quoted context omitted.

What a bizarre argument. 1,000+ independent people trying their hand in the business world is ultimately how a Boeing is conceived. That is the extreme diversity that benefits society.

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 doesn't have to mine bauxite, extract the aluminium from the bauxite, transport it to the place where its sold, etc...

A classic example of this ground-up view was this example given by Milton Friedman about the pencil. I don't agree with many of his views, but I think he makes a good point in this video:

https://www.youtube.com/watch?v=R5Gppi-O3a8

EDIT: Turns out the source of this example may have been Leonard Read:

https://en.wikisource.org/wiki/I,_Pencil

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

#67
Looks promising. First neovim and now this. Even if it doesn't replace emacs (which it won't) if it can enrich the community and maybe bring more users while fixing archaic code bases of hard to find errors and UBs then it is still a win. Neovim pushed vim (Vim suddenly became more active around the time neovim gained traction atleast according to github graphs and releases). So I hope this project brings new life to the core C code in emacs and fixes the problems that it never had (according to the core dev knowledge). When I tried emacs I found it to be a bit like atom at startups. Couldn't get into the keybindings coming from vim.

If it gets faster, I might give it a try again (in evil ofcourse, gotta have them keys).

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

#68
post #6
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.

It seems a bit rude to complain about volunteers for doing something they want to do rather than what you want them to do. I imagine that this, for the most part, isn't even opportunity cost: the people working on it probably wouldn't be contributing to full Emacs (or the Guile effort) anyway. And this sort of effort seems like it could be an on-boarding experience to improving the original code base, e.g. in the pro…

I see no problem in anyone willing to toy with whatever he likes. I have a problem when huge efforts are invested by huge teams on huge projects which clearly have no purpose.

I mean, if you have a lot of energy to use and give, and you want to clone something huge, clone one the proprietary tools that have no free/open source equivalent yet in your domain or one of the domains where there are the most serious lacks of FOSS; or clone a web app into a real desktop program; or reverse engineer a proper open driver for whatever device you have which request a proprietary OS, a proprietary driver or a manufacturer specific tool; rewrite a library which only exists in Python or C# into a C or C-compatible library so that every language on Earth can wrap it, etc. Don't go cloning something that is already free multiplatform software just for the purpose of cloning.

We have never had so many people writing open-source programs, taking part in open-source projects, and yet it looks like the progress of open-source over proprietary (and its new form: services) is not what it was in the 90's and 2000's, it stalled, and it regresses in some areas. There has to be a problem somewhere.

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

#69

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.

Post reply on HN