Linux

Ladux? Linda? +Linux, pronounced "Add a Linux" -> Ada Linux? LinLace?

Anixa for the win

Adux

Forth is fun but not really suitable for large, long-lasting projects with huge developer communities. Linux isn't being bootstrapped, it's already here and has been around for decades and it's huge. And, I think bootstrapping-by-poking-around on a new architecture has stopped being important. Today, you have compiler and OS's targeted to the new architecture under simulation long before there is any hardware, with excellent debugging tools available in the simulator.

I have played with Ada but not done anything "real" with it. I think I'd be ok with using it. It seems better than C in most regards. I haven't really looked into Rust but from what I can gather, its main innovation is the borrow checker, and Ada might get something like that too (influenced by Rust).

I don't understand why Linux is so huge and complicaed anyway. At least on servers, most Linux kernels are running under hypervisors that abstract away the hardware. So what else is going on in there? Linux is at least 10x as much code as BSD kernels from back in the day (idk about now). It might be feasible to write a usable Posix kernel as a hypervisor guest in a garbage collected language. But, I haven't looked into this very much.

Here's an ok overview of Ada: http://cowlark.com/2014-04-27-ada/index.html

I don't think Ada in the kernel would get any cultural acceptance. Rust has been hard enough. C++ was vehemently rejected decades ago though the reasons made some sense at the time. Adopting C++ today would be pretty crazy. I don't see much alternative to Rust (or in a different world, Ada) in the monolithic kernel. But Rust seems like it's still in beta test, and the kernel architecture itself seems like a legacy beast. Do you know of anything else? I can't take D or Eiffel or anything like that seriously. And part of it is the crappiness of the hardware companies. Maybe it will have to be left to future generations.

TIL that version appears to be on the AUR: MicroEMACS/PK 4.0.15 customized by Linus Torvalds.

Last updated in 2014, it probably has serious cobwebs now. Even the upstream hasn't been touched in 6 years.

MicroEmacs

In testing, to settle a bet by a rabid cult-of-vi peer, I opened a given set of files in each editor, each a day apart because I couldn't be arsed to clear caches. This guy, otherwise a prince, was railing about emacs, but otherwise suffered days of waiting.

10/10 the memory usage by his precious vi was same-or-more than emacs.

There's so many shared libs pulled in by the shell that all the fuddy doomsaying about bloat is now just noise.

I avoid vi because even in 1992 it was crusty and wrong-headed. 30 years on the hard-headed cult and the app haven't changed.

I don't see how microEmacs can improve on what we have by default, and I worry that the more niche the product is the harder it will be to find answers online. But I'm willing to be swayed if anyone can pitch its virtues.

Zig is "c", but modern and safe.

Zig is safer than C, but not on a level that is comparable to Rust, so it lacks its biggest selling point. Unfortunately just being a more modern language is not enough to sell it.

So imagine if trying to fit in a C-like cousin failed

C++ was not added to Linux because Linus Torvalds thought it was an horrible language, not because it was not possible to integrate in the kernel.

Zig is a very new and immature language. It won't be kernel-ready for at l'East another 10 years.

a better syntax

That's pretty suggestive. Rust syntax is pretty good. Postfix try is just better for example.

Zig also uses special syntax for things like error and nullability instead of having them just be enums, making the language more complex and less flexible for no benefit.

Syntax is also not everything. Rust has extremely good error messages. Going through Zig's learning documentation, half the error messages are unreadable because I have to scroll to see the actual error and data because it's on the same line as the absolute path as the file were the error comes from

No hidden memory allocation

That's a library design question, not a language question. Rust for Linux uses its own data collections that don't perform hidden memory allocations instead of the ones from the standard library.

it's more readable

I don't know, Rust is one of the most readablelangueage for me.

Fast compile time

Is it still the case once you have a very large project and make use of comptime?

it's simpler to learn

Not true. Because it doesn't have the guardrails that rust has, you must build a mental model of where the guardrails should be so you don't make mistakes. Arguably this is something that C maintainers already know how to do, but it's also not something they do flawlessly from just looking at the bugs that regularly need to be fixed.

Being able to write code faster does not equate being able to write correct code faster.

Really great interop with C

Yes, because it's basically C with some syntax sugar. Rust is a Generational change.

Linux has tried to include CPP in it, and it failed.

So imagine if trying to fit in a C-like cousin failed, how far they are to fit an alien language like Rust...

But that wasn't about the syntax, but about the fastnesses, size and control, want it? Things that shouldn't be much of an issue to Rust.