Rust vs C

Posted Aug 13, 2024 9:17 UTC (Tue) by khim (subscriber, #9252)
In reply to: Rust vs C by eharris
Parent article: Rust Project goals for 2024

> Q2: Perhaps someone could write a RustToC program......and then we could get back to using gcc or llvm?

mrustc already exists, but it's goal is not to provide something that anyone may use for random rust projects, but solelely to make it possible to bootstrap regular rustc on a platform that doesn't have it.

> Q1: 272 vs 692 --- maybe there is a clue here?

Oh, absolutely. K&R is not even a language, it doesn't define so many things that you could write neither compiler nor working program using just K&R book, alone. Not only it leaves many important things not explains (like, e.g., how can printf or open functions exist if each function have to have fixed number of arguments), but, maybe even more importantly, today, C doesn't include even most basic building blocks like hashsets or dynamic strings (which means that every project have to grow it's own, incompatible, set).

I'm not sure if that's possible to write real program while only reading Programming Rust and nothing else (probably not), but it's definitely a step in a right direction.

Complexity have to live somewhere and if you try to make your seminal book about the programming language extra-simple then you make everything else around said book needlessly complex.

Of course it's all about trade-offs and it wouldn't be a good idea to collect all knowledge that one may need ever into one huge 1000000 pages language tutorial, but 272 pages of K&R is not an advantage but a liability.

Not all problems that C/C++ (and systems built on top of it) faces today can be trace to that attempt overuse worse is better, but just the majority of them. Most of the issues that we bitterly fight today can be traced to that fateful decision to abandon things like safety or correctness to make sure C compiler would fit into that 16KB PDP-11.

Today typical size of PC memory is not 16KB, and not even 16MB, but more like 16GB — and yet we still don't have “nice things” in C because of that fixation of throwing away all “complications” from the good language.

P.S. The saddest thing is really C++, not C. At least C had a reason to cripple the concept of high-level language. That reason may not exist anymore but it was actually valid when C was invented. C++… ugh. C++ adds insane amount of complexity yet it took decades for it to get some very basic features. Things like the ability to check if element is in a set (added in C++20) or the ability to return either error or value (added in C+23), etc. That's kinda-sorta-understandable, too: C++ was chasing the OOP dream (which turned out to be a mirage) and that's why basic necessities that C removed to fit into tiny systems are only returning now and in a very twisted fashion, but that's fundamentally different from C path: C pretty much had to remove basic necessities, or else it would have been not viable for the task that it was supposed to solve, but why have C++ added so much cruft before adding back things that C removed?

Rust vs C

Posted Aug 14, 2024 15:59 UTC (Wed) by Karellen (subscriber, #67644) [Link]

> Q1: 272 vs 692 --- maybe there is a clue here?

Not only it leaves many important things not explains (like, e.g., how can printf or open functions exist if each function have to have fixed number of arguments),

FWIW, my copy of The C Programming Language is 2nd ed, but is 272 pages long, so is (I presume) the edition under discussion.

In that edition, the part that describes printf() in detail is Section 7.2 on pp. 153, which is immediately followed on pp. 155 by Section 7.3 Variable-length Argument Lists which describes the ... declaration syntax, the va_list type and the va_start, va_arg and va_end macros, and then gives an example of how to write a cut-down minprintf() using those elements.