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:
.text
, .bss
, .rodata
and ,data
.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.
@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.
@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.
@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?
@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:
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…
@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.