Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Remacs – A community-driven port of Emacs to Rust

github.com

Post reply on HN
Print view View original

41–50 of 181 posts

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

#41

Post by always_good »

achikin wrote: post #34
pera wrote: post #33

Earlier quoted context omitted.

This is not something intrinsic in the nature of open source, but in how humans like to spend their free time. Of course we could all be much more efficient if we all had the same goals, but that's not how things work in a free society.

As a society we win big by collaboration in the first place. Not by diversity, disagreeing with other people and doing everything "your way". Imagine 1000 independent people trying to build Boeing in an opensource way.

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.

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

#42

Post by sillysaurus3 »

melling wrote: post #15
mschaef wrote: 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.

A large part of Emacs is the Lisp source. It would be great to have another interpreter written in Rust that reads the same Lisp files. What’s the breakout of C vs Elisp? Ideally more of Emacs could be rewritten in Lisp with a smaller interpreter.

349,615 lines of C

1,632,280 lines of elisp

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

#43

Post by musha68k »

mschaef wrote: 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.

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

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

#44

Post by eklitzke »

DDSDev wrote: post #22
mschaef wrote: 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.

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 eliminate dead code, etc.) landed in upstream GNU Emacs. Rewriting parts of Emacs in Rust is an interesting idea, and I applaud it as a fun project. But for people who are interested in making more incremental improvements to Emacs, there's a lot of work to be done in the existing C code base to make it smaller and more secure.

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

#45

Post by frou_dh »

coldtea wrote: post #37

I'd like to see a community-driven port of Sublime Text to Rust, with a basic ST3 like cross-platform UI, and offering a base set of UI primitives (buttons, panels, dropdown, inline styled annotations, etc) available for plugins, and first class support for JS plugins/extensions.

Doesn't port imply having access to the original sourcecode?

There are many unrelated editors that have cloned aspects of Sublime to varying degrees in the 2010s.

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

#46

Post by falcolas »

stagger87 wrote: post #36
digi_owl wrote: post #29

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.

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

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

#47

Post by coldtea »

frou_dh wrote: post #45
coldtea wrote: post #37

I'd like to see a community-driven port of Sublime Text to Rust, with a basic ST3 like cross-platform UI, and offering a base set of UI primitives (buttons, panels, dropdown, inline styled annotations, etc) available for plugins, and first class support for JS plugins/extensions.

Doesn't port imply having access to the original sourcecode? There are many unrelated editors that have cloned aspects of Sublime to varying degrees in the 2010s.

Well, cleanroom re-implementation if you prefer.

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

#48

Post by agumonkey »

achikin wrote: post #21
dbaupp wrote: post #6

Earlier quoted context omitted.

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…

This is one of the main issues of open source - people tend to work on what seems fun/interesting/rewarding. As a result a lot of people work on different implementations of the same things instead of coming up with one good solution and creating new things on top of it. Moreover, while some people work on the endless clones of the same thing, the completely different set of contributors is wasting their time cleanin…

I think it's incomplete analysis. I partly agree but what makes the Desktop Environment problem is more an issue of culture and education. People creating distro are implementing what they saw and it's often recent similar efforts. If people knew how OS2, Xerox, BeOS worked they'd have a different desires and goals.

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

#49

Post by znpy »

tangue wrote: post #28
mschaef wrote: 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...

Thanks for posting this.

This is probably the most informative comment of the whole thread.

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

#50

Post by agumonkey »

mschaef wrote: 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.

I believe remacs is already having some sort of positive impact, yet not a user visible that is true. But for decades emacs core was somehow a blackhole. Now it's been modeled in another very different language. That's very nice.

Also maybe it will help testing emacs, and even improving faster since rust typesystem is said to help refactoring tremendously.

We'll see.

Post reply on HN