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

101–110 of 181 posts

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

#101

Post by dbaupp »

coldtea wrote: post #39
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…

> It seems a bit rude to complain about volunteers for doing something they want to do rather than what you want them to do. It is, a little, but then again it's par for the course for Open Source projects, which are both volunteer AND seeking to engage a larger community. It's not like its just some people doing what they like and keeping it to themselves or just offering it as-is. Open Source projects that want to…

There's many different sorts of open source projects, I've been involved with projects that

- are mainly driven by paid contributors, with some volunteers

- some number of paid contributors with many volunteers

- have only volunteers

And they are open source:

- in order to engage a larger community of end users

- in order to engage a larger community of developers (doing things with people is often more fun, and/or having more people poking at keyboards allows more, say, of an experiment to be accomplished)

- to serve as a portfolio, e.g., for job seeking

- as a political position (some variation of "code should be open")

- out of habit/because there's no reason to not be open source

(Or some combination of the above.)

As far as I know, remacs is driven entirely by volunteers, but I don't know where it fits into the latter category. The original author has written blog post(s) about it, so clearly they want people to know about it, but it isn't obvious to me if they care particularly about people using the result for editing text rather than, say, investigating and showing off the solutions to problems encountered along the way (portfolio) or being able to collaborate on a fun project with people (community of developers).

In any case, I agree with you about projects accepting criticism, but I think the style of criticism needs to take into account the specifics of the project: something like, there should be less "this is a waste of effort"/"I think you should do something else" and more of the pure technical stuff ("algorithm ABC might be more efficient than the XYZ currently used, as ABC is O(n log n)", or something) as one moves further down either list.

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

#102

Post by nine_k »

e12e wrote: post #85
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.

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] htt…

Because you want a core written in a safe, statically checked language?

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

#103

Post by dbaupp »

e12e wrote: post #85
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.

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] htt…

It's touched on elsewhere in this thread, but one of the benefits of doing the port in the style of remacs is that one has a completely functional editor the whole time: things can get rewritten one small piece at a time because Rust and C have similar binary models. It's easy and fast to call from one language to the other, so one can rewrite a a single C function to Rust and have the rest of the C code call it, and that function call into the rest of the C code (and without any pervasive per-call-site expense).

I have no idea how feasible this is in any implementation of common lisp, but the mere fact the language (AFAIK) requires a runtime beyond the C runtime (garbage collector, etc.) suggests it may not be as easy as with Rust. If it's possible, maybe someone else could start a project attempting that, if they thought they'd enjoy it.

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

#104

Post by nine_k »

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.

Labor has negative utility. You have to compensate if you want people do labor.

In a business setting, you pay people.

In a hobby setting like that, people compensate by having fun.

Either approach is compatible with producing open-source software; I suspect most LOC of open-source projects are written by salaried contributors at large corporations.

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

#105

Post by dbaupp »

achikin wrote: post #17
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…

>the people working on it probably wouldn't be contributing to full Emacs >in the process of porting, someone notices a bug and so submits a patch upstream I find it a little bit controversial.

These aren't in opposition: it's what I meant by "on-boarding".

If remacs didn't exist the hypothetical developer wouldn't be contributing to full Emacs (it never crossed their mind, or it's too intimidating, or whatever other reason), but through their work on remacs, they've also contributed to the original emacs. The point is that the latter contribution would never have happened without remacs.

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

#106

Post by bluejekyll »

chongli wrote: post #91
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.

language specific repositories worrying What is the alternative? Every major Linux distro has its own repository, as do all the BSDs. The picture on Windows and macOS is even more convoluted. Are developers in all these languages supposed to support the packaging of their software in half a dozen different repositories? Maybe all programmers should get together and build "one repository to rule them all"? I have no i…

FPM is at least a step in the right direction to reduce the overhead of creating all of these.

At a minimum, Linux should have a common packaging system; though there may never be agreement. It's hard to see macOS and windows endingnup with a common one.

But maybe we could do a third party option that is independent of each OS? Those rarely work out well though.

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

#107

Post by FullyFunctional »

Philipp__ wrote: post #14
BeetleB wrote: post #3

Not intended to be a port, but I occasionally search for an editor that is customizable in Python to the extent Emacs is. Leo Editor ( http://leoeditor.com ) fits that bill. It's been around since the 90's (and the web page looks like it's from the 90's). Even though it has many users, the documentation is quite poor. If I had another life to live, I would learn it well and improve the docs - and then port over every…

That looks interesting thanks for sharing. Too bad it wasn't meant to be run on macOS.

According to http://www.wilfred.me.uk/blog/2017/07/15/these-weeks-in-rema... it's running on 32-bit macOS. I don't know if Remacs is 32-bit-only on all platforms.

This is an interesting project and I wish them well. I have no opinion on Rust at the moment, but I do see this as part of a general trend towards safer languages.

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

#108

Post by dbaupp »

coherentpony wrote: post #90
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.

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.

> In most linux contexts, there's really no need for it since linux distributions come with package managers

This single sentences hints at least major two reasons for language-specific package managers:

- non-Linux platforms

- there's many different Linux package managers (apt, rpm, pacman, nix, portage, ...)

A language-specific package manager means developers (i.e. the ones writing the packages) only have do to packaging work once, instead of for every platform they might want to support, including ones that they have no way to test on (and a lot of code, especially in the modern wave of languages like Rust, often works on all platforms with no particular effort from the developer).

From an asymptotic perspective, using the platform package managers results in something like O(# libraries * # platforms) work and likely a lot of code not being packaged for some platforms, whereas language-specific package managers is something closer to O(# languages + # libraries) work (or maybe O(# languages * # platforms + # libraries). Looking at this decision purely in terms of developer effort, the latter seems like the better choice.

(There's also things like fpm that are designed to be more like O(# platforms + # libraries) work, which is nicer than either of the above!)

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

#109

Post by tonyarkles »

Symbiote wrote: post #64
baq wrote: post #60

Earlier quoted context omitted.

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

I recently came across this: https://github.com/spotify/dh-virtualenv

For a system utility, you can still use virtualenvs. The launcher script just needs to use a shebang like:

    #!/usr/share/spiffyapp/venv/bin/python

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

#110

Post by [deleted] »

mixedCase wrote: post #58
eklitzke wrote: post #44

Earlier quoted context omitted.

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…

I don't see how it is any more incremental than what Remacs is trying to do. They're doing a parasitic rewrite of GNU Emacs, it's not a from-scratch implementation.

[deleted]
Post reply on HN