Comments by "Edward Cullen" (@edwardcullen1739) on "C Is Not A Language Anymore" video.

Agreed. The author doesn't really understand the distinction between the System Call Interface and the C wrapper library that most people interact with. He does not understand that all C implementations are exactly that and they have freedom to do their own thing. This is not a failure of C or even other languages, it is the nature of the beast and he is simply unaware that people "don't bother" writing their own SysCall wrappers - they just reuse glibc or whatever. The Linux System Call Interface is fixed and Linus does a LOT to ensure it never breaks (the rants he has about this 😅...) There is nothing to stop Rust from implementing a SysCall wrapper library that bypasses glibc. They just haven't done the work.
20
@phillipsusi1791 You're suffering the same lack of understanding that the author of the article does. Whatever standard library has will provide all the same kinds of functionality as glibc, except it relies on glibc to handle syscalls. There is nothing stopping the Rust maintainers from implementing their own SysCall wrappers. Easier on Linux/Unix, not so easy on Windows... But if Rust really is "the future", Microsoft will start to implement a native Rust interface anyway... As to the question of "unstable SysCall interface"... This is answered by Linus MANY "do not break userland" rants; if this is an issue, use a better-managed OS/kernel.
8
@phillipsusi1791 Right, the article doesn't mention syscalls, because the author doesn't know what a syscall is. Because he doesn't know what a syscall is, in HIS MIND the only way to do certain things is to use C. This belief is what underpins the title "C is not a Language". I AM NOT ALONE IN DRAWING THIS CONCLUSION! The OP of this thread and many others have had this same insight. The original author also has some difficulties around appreciating the flexibility implementors have when it comes to the C language - where he's complaining about the variation in ABI between clang and GCC/glibc. Indeed, the original author betrays a lack of understanding of what an ABI even is! Application Binary Interference is not System Call Interface; he does not appreciate that incompatible ABIs between clang and GCC are normal as each C implementation defines their own ecosystem, in the same way a Java library and a python .pyc are different. Would it be better if GCC and clang had mutually compatible ABIs? Probably, but there is no requirement, because that's not how C works - because C IS a language, NOT a comprehensive ABI specification!!!
7
This is not true. The author does not understand the distinction between the System Call Interface and the glibc wrapper. There is no reason preventing Rust from implementing its own wrapper around system calls on each platform. There were many, many misunderstandings that boil down to "Yes, this shit is hard. If you want to do it properly, you need to do the work."
5
@phillipsusi1791 Correct answer. This is exactly where people fall down; they think if the language definition in terms of the implementation they're used to. There is nothing stopping an implementation where sizeof(...) char == short == int == long.
5
@an0nsaiko890 The original article author implies that he believes that the only way to access syscalls is via C functions. The OP of this thread and I both drew this same conclusion. And both myself and the OP of this thread have implied the same - that if the original author understood how syscalls worked, he would not have written the article in the same way. It seems like people have jumped into the conversation half-way through, completely ignored the context of this thread, completely ignored my previous posts and are now ascribing the same lack of knowledge/understanding of the original author to me, which is absurd.
2
@andreipangi Opinions can be objectively wrong. You can have the opinion that Pi is 3, which would be wrong. This is another example. Again, it's not the C language that is the "protocol", it's the C function call interface and the syscall interface. As this varies by OS and C implementation, your assertion that other languages/runtimes would be "wrong" to implement their own syscall interface(s) is simply a demonstration of your lack of understanding of the subject. Your assertion that it would "add a lot of bugs" is the silliest argument - all software is buggy, therefore, never write anything new, because it will have bugs. 🤦‍♂️ Breaking assumptions is precisely the point - people want to be able to write "pure Rust", rather than having to "switch to C". Inter-code communication is precisely the issue and the desire to not have to do it. Again, this is all showing confusion about the topic and a general lack of understanding of what the real problems are. C is a language specification that gives broad latitude to implementors to make their own decisions, based on their needs and the needs of the OS and hardware they're running on. Failing to understand the distinction between the C language specification, a particular C implementation and the OS syscall interface (which can be accessed directly using assembly language), is the problem the OP has.
2
I hate to say this, but there is a serious skill issue here. The author does not understand the distinction between the System Call (SysCall) Interface and the wrapper library that most people typically use to access it. The Linux SysCall Interface is defined by the kernel implementation. For convenience, C implementations usually provide a wrapper around this, because setting-up and managing the result of a SysCall is a PitA. There is absolutely nothing stopping the Rust community from implementing their own SysCall wrapper - they just haven't done the work. This would need to be done once for each OS (with some variations based on CPU arch). Yes, this is a mammoth task, especially for Windows, but it is what it is. If you want your own native SysCall wrapper, then you need to do the work. "Annoying" on Linux/Unix systems, nightmarish on Windows, yes... But you can always try to persuade MS to do some of the work...
1
@an0nsaiko890 No, the author focused on syscalls, because "the only way" to access them is via C libraries. Any other library can simply be re-implemented in Rust.
1
@an0nsaiko890 You need to re-read what I wrote and the other replies I've made in this thread and comments section. According to the article author, "the only way" to access syscalls is via C function calls. Your response is really quite embarrassing.
1