I think there would be still space for systems programming language with a constraint from day zero that it would 1:1 compatible with plain C”s binary layout and memory model:

1. Roughly just .text, .bss, .rodata and ,data.
2. No symbol mangling at all.

All the memory safety etc. fancy features would be then designed within exactly those constraints.

#Rust is essentially a derivative of C++ when compiled to binary, which does not really make it a strong competitor for plain #C. It can substitute C in many cases for sure, just like C++ did, but there’s always need for minimal systems programming language, which also looks elegant in binary, not just in source code.

A compiled C program can be quite easily understood with a binary with no debug symbols at all if you understand the CPU architecture well enough. That is, and will be a strong asset for C.

#cplusplus #rustlang

@jarkko I'd say you probably still need relocations, and it would be interesting to extend something like annobin (though not in the relocation section wtf) to annotate error checking proofs for memory safety.

@vathpela Yes, that was a rough cut, skipped relocations, GOT, PLT etc. ;-)

@vathpela It might be.too radicalized thinking but sometimes I feel that maybe Linux should simply fork Rust and remove unnecessary stuff. We in any case do not want external dependencies for vmlinux so it would be for the most part just stripping of features. By removing e.g. namespaces we could simplify the equation of getting rid of name mangling. Also then there would not be a problem of having incompatible atomic, which applies actually both C and Rust.

And right, then the language could only have fallible allocations, not just as an additional feature but instead as an enforced pattern.

Not my decision but I do have right for an opinion at least. Let's call this fantasy language as Lust ;-)

@vathpela You could even ironically say that it would be Rust way of approaching open source: fork anything in existence and make Rust version out of it. Like even coreboot has a version called "oreboot"

@vathpela There's only like 50-60 Rust files in total in the mainline so it would not be even tremendous job to initiate. Not whole a lot of legacy, and all of it is experimental features (e.g. given the lack of gccrs support cannot be turned on in arch defconfig).

@vathpela And yeah C and Rust would be by definition bridged then. And language would be still familiar enough that knowledge of Rust would help to cope with it.

@vathpela Oh, and then we could run the development of language spec and the compiler frontends in total three mailing lists (e.g. lust-lang@vger.kernel.org, lust-gcc@vger.kernel.org and lust-llvm@vger.kernel.org).

Github makes following the language development with easy ways to backtrack years old discussons almost impossible or you really have to put effort to it vs. just going to lore and grabbing a mbox.gz of a relevant discussion.

I really wish I would live in this nice and lusty alternate reality instead of this crappy and rusty reality ;-)

@jarkko Safety is like a thread you start to pull, and pulls more and more stuff. You need collections for bound checks and robust realloc, but void* casts complicate verification, so you need generics for collections. To reduce bounds checks, you need iterators. Safe unions require sum types. Unsafe free() can be replaced with destructors, which need owned+borrowed pointers. You need thread safety too, etc.
There isn't much that can be removed from Rust without creating holes in the safety.

@kornel well for kernel we need only fallible allocations, namespaces could be taken away (and causes need for symbol mangling), no use for external crates, we don’t use cargo because vmlinux is self-contained, we don’t use rust’s atomic type. There’s alot of harmful features in Rust for kernel. Just randomly picked a few.

@kornel We could keep the features from Rust that make sense ofc and remove those that don’t and get a tighter language spec which is less prone to often ignored compiler bugs when discussing about safety properties. By freezing the language with a fork of Rust, it would be also easier to keep ”lustc” and ”gccls” in sync (if the fork was called ”lust” for the sake of example).

@kornel Traits and generics would still need some mangling but limiting their features we could possibly get the symbols in the ELF binary have names that would be more familiar and meaningful and more C alike instead of following C++ convention like Rust does. Right and I think unwrap() should not exist as any default behavior is harmful, especially panic. So yeah there would be lot of stuff that could be simply wiped away and get a better language for kernel dev.

@jarkko

I realize I’m intruding, forgive me.

#Zig is quite nice. It isn’t mature yet but I wonder if it occupies a local optimum such that a lot of systems languages just end up converging there.

@jarkko @vathpela
Does namespaces even need name mangling?

Name mangling is done because the linker only handles names, i.e. strings, right? So why can't system.string just be named "system.string" from a linker point of view?

All the other things, like overloaded parameters, those need some kind of name mangling, but even they could maybe be more readable, something akin to .NETs Type.FullName.

And if the answer is that thd linker only handles short names, maybe fix the linker?

@leeloo @vathpela

Yes all that crap piles up to put short. Read about binary analysis, compilers, linkers, ELF ABI specs etc. and you should get a grip.

@lorddimwit Nothing against Zig but we apparently chose Rust.

I still think we should fork Rust and strip it down like hell. Then it would not be compatible with Rust but more like relative. I don’t see any problem in that I mean even C is not at least formally a subset of C++, they have some differences in semantics

I don’t care about languages (except little bit of C which is lingua franca for ABI) but I’m more like worried:

1. Experienced maintainers in file systems, mm etc. with no time at hands are not able to do proper analysis on Rust. So we are going to the unknown without “shared consensus” being on the steering wheel.
2. It has tons of “never use this in kernel” crap, which we IMHO should just remove from it. Who care if we end up something NOT Rust but still relative or similar to Rust.
3. Language spec is out of control… and in Github ;-)
4. Compiler bugs are a disease. That huge ever growing language spec maintains their steady flow.
5. It will be tedious job to maintain correspondence with gccrs and rustc. Even if you think that LLVM should be everywhere (which is no-go for linux but just for the sake of example), how do you do ever detect all those nasty compiler bugs?

We need something more compact that does not change often so that also compiler’s implementation can be matured, bugs fixed etc. So yeah, to sort out this madness I really do personally (this is my voice only, not korg as org) think that we should stop this madness and just do a fork and control all that in kernel mailing lists. Linux would deserve language of its own, relative to Rust but not always compatible…

@leeloo @vathpela Here's at least an example https://doc.rust-lang.org/rustc/symbol-mangling/index.html

@leeloo @vathpela Oh no, even mangling is not sealed but has versions: "Mangling versions'. For unmangled symbols you can even script some binary analysis tasks. Rust's language team takes apparently care that binary analysis is not only more complicated but also any automation on that will also break over time.

@jarkko Rust is more of an ML-family language. It only adopted a C++-like skin to avoid looking weird to systems programmers.

Optimized compiled Rust code can look like C, especially if you use fallible functions instead of panicking ones.

Why is mangling such a big issue? Name collisions or ABI mismatch during linking can cause bugs. Debug tooling should be able to demangle for you.

@kornel that could be feasible in constraints if they did not break ABI purposely. They’ve documented that even as a feature. Changing symbol mangling is ABI annihilation. Should have never touched that.