Comment by threatofrain
10 months ago
Perhaps C is here to stay and that is the way Linux should live and naturally die. That's what's being proposed here by the guy who opposes multi-language projects.
10 months ago
Perhaps C is here to stay and that is the way Linux should live and naturally die. That's what's being proposed here by the guy who opposes multi-language projects.
That's my overall point of view too. Regardless of infinite technical discussions about one or another, if Alice and Bob can't live together than just don't get married.
Why spend all this energy on conflict and drama to no end? If one language/technology/group is so much better then just fork the thing and follow their own path.
I'm actually not defending the C guys, I just want to leave them alone and let "Nature" take his course, if they die on obsolescence, then they die. who cares..
I concur. Personally, I'd love to see all the Linux Rust effort being redirected at Redox OS.
If the Asahi team focused their efforts on Redox, with all the genius talent they they have, we could see an actually practical, usable implementation of Redox on real hardware; a potential daily-driver which would catapult the development of whole ecosystem - and that can only be a good thing.
Redox has stayed drama free so far.
I am sure most people involved with the Linux rust effort are also not problematic; these would be very welcome there.
OTOH, please don't let Redox be taken over by problematic people.
1 reply →
"In 2010, after twenty years under development, Stallman said that he was "not very optimistic about the GNU Hurd. It makes some progress, but to be really superior it would require solving a lot of deep problems" - https://en.wikipedia.org/wiki/GNU_Hurd
Most UNIX systems that were not implemented in C, and thus lacked the symbiotic relationship, never survived in the market, sadly.
There have been UNIX systems implemented, Pascal, Ada, Modula-2, Modula-3, as the most relevant ones.
All gone.
Also note that POSIX/UNIX certification requires a C compiler presence.
I don't think you can conclude anything from that since a ton of UNIX systems implemented in C are also dead.
C was created to rewrite UNIX from its original Assembly implementation, naturally it is a symbiotic relationship not shared by other languages.
Note that many folks even forget that C++ was equally developed on the same Bell Labs group, and is probably one of the first examples of guest languages, making their best to fit into the platform, taking advantage of the ecosystem with almost zero friction, but never being able to control where the platform goes.
7 replies →
Market failures of the other Unices aren't necessarily related to the technical advantages or disadvantages or symbiosis with C or being implemented in C. However, making C programmers' life easier was crucial.
Linux was at the correct place at the correct time. It was the only free version of Unix-like OSes that didn't have legal bullshit to deal with. IBM and Intel's support also made GNU/Linux ecosystem successful, without them it would stay as an academic project. Being free meant that it had an advantage where price sensitivity mattered and dotcom boom and VC explosion is very sensitive to cheaping out and preffers suffering with less-than-ideal software. So Linux stayed popular while other ones died slowly.
C had a huge following and all OSes had to support it. Simplicity made it popular when average hardware at the hands of many academics and young professionals was very weak. Being written in C may have made things marginally easier but neglecting it for Ada or Pascal was a terminal mistake. Windows isn't Unix at all but it also had to support C well.
Free beer OS with source tapes and the Lions book made the huge following of academics and young professionals.
Had AT&T been able to sell UNIX, and naturally C, at the same price points as VMS, System 360, and many other contemporary OSes, and none of us would be talking about them today, other than history curiosities.
Instead we are left with UNIX haters handbook, and still trying to fix the security issues across the industry caused by C's adoption, the JavaScript and PHP of systems programming languages, both in adoption scale, and code quality.
OSX would like to disagree with you.
First of all I mentioned most, not all.
Second, while OS X, and NeXTSTEP before it, are technically UNIX, they aren't seen as such by either NeXT, nor Apple.
The focus of the whole userspace experience is on Objective-C frameworks, nowadays also a mix of Swift and C++.
Steve Jobs was famously against UNIX culture, there was even a famous attendance of him at USENIX.
NeXTSTEP was based on UNIX, because Steve Job wanted to win the workstation market against Sun, using UNIX compatibility as EEE, bringing folks into NeXTSTEP and keeping them there with Objective-C development experience, Lotus Improv, Renderman and such.
2 replies →
Is the OSX kernel not written in C?
1 reply →
Linux kernel is also one of the few that do not use C ABI as entry point for user programs at all.
As for C compiler presence in POSIX, only existence of C-accessible APIs with specific structure are mandated, C compiler is optional just like Fortran runtime and compiler are.
Are you sure?
https://pubs.opengroup.org/onlinepubs/9799919799/nframe.html
https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...
https://pubs.opengroup.org/onlinepubs/015967575/toc.htm
And copying this from UNIX 03, the most widespread certification,
"A single configuration of the system shall meet all of the conformance requirements defined in the following mandatory Product Standards:
The product must be registered as conformant to the Product Standards prior to, or concurrent with, the UNIX 03 Product Standard registration."
3 replies →
Yes, perhaps a C-only Linux would do that and die, and perhaps it would continue its customization of C flavor and runtime it uses (e.g., the various static and dynamic memory limitations and checkers) and closes the gap with Rust to a point where the incremental benefit of using it is not significant enough that it makes a Rust based competitor an inevitability. We may already be beyond that point, even.
The changes required to bring C to a Rust level of safety would make it an entirely different language, even when restricted to the kernel's domain. Also, if you're already doing codebase-specific patches to the language itself, many of the arguments around codebase portability that justify the use of C fall apart.
Aside from that, there are other benefits to Rust than safety: it's better at modelling data and states, as the now-infamous filesystem talk [0] outlined.
[0]: https://lwn.net/Articles/978738/
> The changes required to bring C to a Rust level of safety would make it an entirely different language, even when restricted to the kernel's domain.
Maybe. 1. It may not have to be "Rust-level of safety" to be good enough to make Rust benefit less compelling. 2. Linux C is already a different languag than C, continued incremental changes might be a better way to get there than adding Rust even if it does become very different in the end.
> Also, if you're already doing codebase-specific patches to the language itself, many of the arguments around codebase portability that justify the use of C fall apart.
Sure, but Linux never had a "codebase portability" argument. It always had to be GCC C. It eventually made some relatively small changes to allow clang to compile it, the far bulk of that work being changing of clang to behave like GCC.
> Aside from that, there are other benefits to Rust than safety: it's better at modelling data and states, as the now-infamous filesystem talk [0] outlined.
Yeah, it's not only safety improvements that are in Linux-C.
> The changes required to bring C to a Rust level of safety
cough* Cargo cough* /s
You cannot have safety or security when you download your code from the internet and this code is a moving target.
2 replies →
Or may be Zig might be more acceptable to the Kernal team, once it becomes mature enough?
This is inevitable: Rust is proposed as a safe language, but there is no way to have a "half-secure" kernel. The only option for people who believe in Rust is to have its own kernel, and Linux should have no part on this.
> there is no way to have a "half-secure" kernel.
There is, and this is how Rust naturally works. If you look at its standard library, you will see a lot of unsafe code or libc calls hidden away under safe interfaces.
In fact, this is how all memory safe languages work, including Java, Python, etc: A small trusted base written in an unsafe language that exposes a safe interface (i.e. the interpreter, the JVM, etc), with the large majority of the code written over that safe interface (i.e. the Java/Python code).
Rust is used to make kernel drivers secure by providing a safe interface for them to use.
Keeping the project single language doesn't mean that the project can't change. The C used today is not the same C used when when the project was started. Changing language is also possible. Using two different languages long-term however means that everyone effectively needs to be proficient in both languages and a lot of work is duplicated.