[1] https://en.wikipedia.org/wiki/Little_Man_Computer

[1] https://immersed.com/

[1] https://melpa.org/#/wgrep

[1] https://github.com/federicotdn/verb

[1] https://www.amazon.co.uk/Last-Lecture-Printing-Publisher-Har...

First, a bit of background: I am mainly a C++ and C# user space developer, so presumably despised by all camps involved. Secondly, I have no experience of kernel development whatsoever. Thus, take my comments with a large grain of salt.

My argument is as follows. Every decision you make on a software project is akin to an intersection on sets of programmers. When you choose C, you take a small slice on all possible programmers; when you choose kernel development, you take a slice on the set of competent C programmers, and so on. The intersection of programmers that are competent in Rust _and_ in C _and_ in kernel development - including the interaction between the two languages, at a very low-level (because kernel-space is special) - must be astonishingly small. And herein lies an important problem. Let us posit that the kernel does gain a significant amount of code in Rust; the interaction between these two languages (read: friction) will become significant. Either the Rust people will break things for the C people, or the C people will break things for the Rust people. Those who like C but not Rust - presumably a large subset of the Linux C programmers, else one would assume they would be developing a kernel in Rust - will become alienated. Similarly, those who like Rust will be forced to spend a lot of time doing non-rusty things just to get Rust to work, and they too will not enjoy the experience. Finally, many of the sweeping code clean-ups the kernel experiences periodically will apply differently to Rust, if they apply at all - meaning it will be a second class citizen, barring some major investment to compensate for this.

In the end, I do not think the problems will come from the languages involved per se but due to the complex technical and especially social interactions that this will create.

It is, however, an extremely interesting project technically and I suspect that Rust (and maybe even the kernel) will benefit from it, though not necessarily in ways one would expect. As far as research goes, it is pretty cool.

> NOTE: The BetrFS prototype currently only works on the 3.11.10 kernel.

This is a tad limiting, hopefully they will port it to latest...

[1] https://github.com/oscarlab/betrfs

a) I think its good that in this day and age where everything is market driven (for better or for worse), someone is willing to take a position purely on ethical grounds. If nothing else because we need a plurality of approaches in order to find the "right" one. Also, note that RMS is no longer involved in Emacs development, AFAIK, and hasn't been for a while. He may pop in the mailing lists frequently, but his "word" does not have to be implemented.

b) the very large Emacs community does not share the political vision in its entirety and thus is not constrained by it. As a long term Emacs user, I have never seen Emacs developing at the fast and furious pace it has today. And this is both in terms of the external code (MELPA et al.) as well as the core itself, for which we must thank the current maintainer.

In fact, I'd even go further: almost all of the historical problems I've had with Emacs have been addressed with the current work already released or in branches - e.g., LSP, DAP, native compilation, tree-sitter... I do not think Emacs' progress has been held by the political views; and even my concerns with copyright assignment as a factor that slows down development have been comprehensively proven wrong by the speed at which Emacs is developing. I noted a great step-change in Emacs velocity over the last 5 years, and if anything it seems to be accelerating.