Hi,

cqwrteur (euloanty.delete@this.live.com) on July 14, 2021 7:39 am wrote:
> anon (anon.delete@this.ymous.org) on July 14, 2021 3:50 am wrote:
> > cqwrteur (euloanty.delete@this.live.com) on July 14, 2021 2:38 am wrote:
> > >
> > > Let me explain again. I do not want Linux Kernel to be written in any language besides C.
> > >
> > > C++ is not an OO language. If you think C++ is an OO language
> > > and people like me who do not use OO are wrong. You are liars.
> >
> > You want the Linux kernel to be written in C. Cool.
> >
> > No one here except Linus Torvalds really has any say in how the Linux kernel
> > is written (I think). What do you want to achieve through this discussion ?
> >
> > Please also refrain from insulting people and being generally condescending
> > ("dumbass", "kids", and a couple others). Is that how you discuss research problems
> > with your advisor and peers ? If not, why is it okay to do it online ?
>
> Yes. I want linux kernel only in C.
>
> Reasons are:
> 1. Linux kernel itself is a crap. Just adding Rust as a driver does not change the fact it is still a crap.
> Rust for Linux code with unsafe abuse already proves my correctness.
> 2. Rust brings no safety in the kernel since you need to many unsafe and they are too verbose. Do not tell
> me Redox OS, it is a microkernel and still, guess what, they have memory safety security vulnerabilities.

There's no evidence of that yet. It's dishonest to compare code (in C) that had 20+ years of bug fixes to code (in Rust) that hasn't been written yet because they're still trying to deal with "bindings to existing C code" and "low level scaffolding".

Sure, there's evidence that Rust isn't perfect (and that memory safety issues in new code isn't 100% impossible), but "better" does not require "perfect".

> 3. Rust still requires a runtime, that bloats kernel binary size and further diminishes performance.
> Things like rustfmt bloat 300kb for kernel that is completely unacceptable.

For C, "freestanding" means you don't have stdio (and can't use "printf()", etc). For Rust, "freestanding" means you don't have rustfmt. It's hard to see a major difference there. Sure; you can complain the "hosted C" requires a run-time (and adds 300+ KiB of bloat) that "freestanding Rust" doesn't have, but..

> 4. The fundamental issue is that Linux lacks of competition. Unless someone writes a new kernel
> completely to compete with Linux, the situation won't change, no matter what language you are going
> to rewrite it.

Linux competes directly with FreeBSD, NetBSD, OpenBSD and OpenSolaris (all using mostly the same user-space, all open source, all "*nix based design" with mostly the same "posix" APIs, etc).

The fundamental issue is that (in general) open source has a funding problem.

Linux has the most market share because it has better hardware support, features, performance, etc; because it has the most developers; because it has the most "for profit" company support; because it has the most market share (because it has better hardware support, features, performance, etc; because it has....). It's a "nearly unbreakable" cycle that has almost nothing to do with programming language or technical merit and almost everything to do with economics and marketing.

This "nearly unbreakable" cycle is caused by Linux relying on a deceptive system of "hidden surcharges" to solve the underlying open source funding problem. You buy a new computer to run FreeBSD (or OpenSolaris, or Windows, or ...), and a lot of that $$ goes to companies like Intel who spend a small part of your $ to fund Linux; with the side effect being that your support for FreeBSD ends up being used to ensure that Linux is better than FreeBSD. You can not expect "100% fair" competition between Linux and competitors under those circumstances.

If someone writes a new kernel to compete with Linux, then it'll just take them 10+ years (mostly on device drivers) to reach the stage were they're screwed by that "nearly unbreakable" cycle (in the same way that the existing direct competitors to Linux are screwed by it now).

Any kind of success requires that you break that "nearly unbreakable" cycle (that has nothing to do with programming language). The most effective path to success would be to use "arguably more powerful anti-competitive practices" to compete against "arguably less powerful anti-competitive practices" (e.g. be the world's king of spam and funnel $$ from an existing monopoly into a new Linux competitor on smartphones).

> Just like GCC was a crap, until clang comes out and changes the situation.

Sure, just like GCC was crap until Apple managed to break GCC's "nearly unbreakable cycle" by investing a lot of $$ into a viable competitor (which also had nothing to do with the language/s GCC developers or LLVM developers chose to use to implement their products).

Of course "C vs. Rust (vs. C++ vs...)" is a very different type of competition (competing for developer's minds, and not consumer's wallets) where technical merit has a much stronger influence. For this, the inclusion of Rust in Linux source code is evidence of competition between languages (and not evidence of a lack of competition); so it's like you're claiming there should be more competition (in an irrelevant area) because you're didn't like competition (in a relevant area).

- Brendan