[cynical_german]

what a weird take to me... C has DECADES of high quality teaching material in form of books, university courses, plenty of which is freely available with a bit of searching.

And, if we discount the fact that "buying" a book is such a big hurdle, even more high quality academic text books and papers to boost; anything from embedded on the weirdest platforms, basic parsing, writing compilers, language design, high performance computing, teaching of algorithms, data structures, distributed systems, whatever!

edit: I even forgot to name operating system design plus game programming ; and of course accompanying libraries, compilers & build systems to cover all of those areas and use cases! edit2: networking, signal processing, automotive, learning about industry protocols and devices of any sort... if you explore computer science using C as your main language you are in the biggest candy store in the world with regards to what it is you want to learn about or do or implement...

[koakuma-chan]

> C has DECADES of high quality teaching material in form of books, university courses, plenty of which is freely available with a bit of searching.

Which means all that high quality teaching material is DECADES old. Rust development is centralised and therefore the docs are always up-to-date, unlike C/C++ which is a big big mess.

[ryao]

Being decades old does not make it out of date. Until a few years ago, the Linux kernel was written using C89. While it has switched to C11, the changes are fairly small such that a book on C89 is still useful. Many projects still write code against older C versions, and the C compiler supports specifying older C versions.

This is very different than Rust where every new version is abandonware after 6 weeks and the compiler does not let you specify that your code is from a specific version.

[koakuma-chan]

> This is very different than Rust where every new version is abandonware after 6 weeks and the compiler does not let you specify that your code is from a specific version.

Do you have any specific evidence? Rust ecosystem is known for libraries that sit on crates.io for years with no updates but they are still perfectly usable (backward-compatible) and popular. Projects usually specify their MSRV (minimum supported Rust version) in the README.

[ryao]

https://endoflife.date/rust

[koakuma-chan]

Are you asking for LTS releases? https://ferrocene.dev/en/

[ryao]

I was not asking for that. I was answering your question. You asked for evidence of rust releases being abandonware. I gave it to you. Someone else trying to ameliorate Rust releases does not change this reality.

[koakuma-chan]

> Being decades old does not make it out of date.

Right, the docs never get out of date if the thing they document never changes. Can you say the same about C++ though? I’ve heard they release new versions every now and then. My robotics teacher didn’t know ‘auto’ is a thing for example.

[ryao]

Both C and C++ release new versions. The compilers continue to support the old versions and people continue using the old versions (less so in the case of C++). Rust’s compiler drops the old version every time it has a new release.

There is no `-std=1.85` in rust 1.86. You do get `-std=c++98` in both g++ and clang++. A book on C or C++ is still useful even decades later since the version of C or C++ described does not become abandonware at some well defined point after release, unlike Rust releases.

[koakuma-chan]

I'm confused. Rust uses semantic versioning:

Given a version number MAJOR.MINOR.PATCH, increment the:

    MAJOR version when you make incompatible API changes
    MINOR version when you add functionality in a backward compatible manner
    PATCH version when you make backward compatible bug fixes

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

What kind of versioning scheme does C/C++ use?

[ryao]

C and C++ are two different languages. They are versioned by years. Rust technically does not have versions. The rust tools have versions. Basically all versions of C are binary compatible with each other. I suggest you actually learn and use C rather than asking questions since you are never going to ask the right things to understand how it works without having firsthand experience.

[jpc0]

Auto as it is now has been in C++ since C++11, thats more than a decade ago...

If your argument was C then sure thats a C23 feature (well the type inference type of auto ) and is reasonably new.

This is much more a reflection on youe professor than the language. C++11 was a fundamental change to the language, anyone teaching or using C++ in 2025 should have an understanding of how to to program well in a 14 year old version of said language...

[koakuma-chan]

> Auto as it is now has been in C++ since C++11, thats more than a decade ago...

> anyone teaching or using C++ in 2025 should have an understanding of how to to program well in a 14 year old version of said language...

If the current year is 2025 then 14 years ago is 2011 which is not that long ago.

> If your argument was C then sure thats a C23 feature (well the type inference type of auto ) and is reasonably new.

Grandparent comment is arguing that Linux was written in C89 until a few days ago so decades old books on C aren't actually outdated.

[jpc0]

Decades ols books in C most certainly is even useful in modern C++23 because you need to interact with other libraries written in C89.

When a lot of modern CS concepts wwre first discovered and studied in the 70s, there's no point arguing that old books are useless. Honestly there may be sections of old books that are useless but in the whole they are still useful.

[nickpsecurity]

A long time ago, Victor Yodaiken told me the best way to learn C was the old, K&R book. The explanations, examples, and even pitfalls were all explained well. My code worked without much fuss. That's probably because C hasn't changed much.

I ended up switching to Python for job requirements after getting through half the book. If I re-learn C, I'll go back to it. If it were C++, that would be a totally, different story since they kept piling features on over time.

[cynical_german]

Oh my... Are you serious? I'm almost triggered by this. A book about algorithms or data structures from 20 years ago has nothing more to teach? 3D game engine design from 20 years ago has nothing more to teach? No point in looking at the source code of Quake, reading k&r, and Knuth's TAOCP Volume 1 was published in 1968 so it's obviously irrelevant garbage!

I could spurr into an essay of what kind of lack of understanding you just portrayed about the world, but I won't.... I won't...

[koakuma-chan]

We’re talking about C/C++, not algorithms or data structures.

[jpc0]

How you implement algorithms and data structures in C++/rust is semantics at best. The imperative shell of those languages are identical semantically right down to the memory model.

[koakuma-chan]

Right, that's why a 20 year old book on algorithms and data structures is not necessarily outdated, but a 20 year old book on C/C++ most certainly is.

[ryao]

My copy of The C++ Programming Language for C++98 is still useful today, as is copy of The C Programming Language for C89. The idea that these books are no longer useful is absurd. Modern compilers still support those versions and the new versions are largely extensions of the old (although C++11 changed some standard library definitions). The only way you could think this is if you have zero knowledge of these languages.

[koakuma-chan]

> edit2: networking, signal processing, automotive, learning about industry protocols and devices of any sort...

I admit there is many great products that are written in C that aren’t going anywhere any time soon, notably SQLite, but there is no reason to write new software in C or C++.

[ryao]

I wrote a new daemon in C the other day. Plenty of people will continue to write software in C. Some will even write it in C++. There is nothing you can write that will convince the world to stop writing software in these languages. We went through this once with Java. We are going through it with Rust. We will go through it with Zig or whatever it is that people say everyone should adopt next instead of Rust and all else that came before it.

[nickpsecurity]

There's tools that can prove the absence of runtime errors in industrially-useful subsets of C. Frama-C, RV-Match, and Meta's Infer come to mind. That code is then usable in about anything because so much of it is written in or can call C. Until Rust has that combo, there's still a reason to use C.

Personally, I'd use both Rust and C with equivalent code. The Rust types and borrow checker give some extra assurance that C might not have. The C tooling gives extra assurance Rust doesn't have. Win, win. If I want, I can also do a certified compile or cross-compile of the Rust-equivalent, C code.

[ryao]

Astree claims to be able to prove the absence of runtime errors in both C and C++, without requiring the use of subsets:

https://www.absint.com/astree/index.htm

By the way, C has a formally verified C compiler:

https://compcert.org/compcert-C.html

[nickpsecurity]

Yeah, CompCert will certify a binary for those willing to buy it or use a GPL license. Empirical testing showed it had no bugs in its middle end, unlike other compiler.

On Astree, I couldn't believe it supported all language constructs. I found this on your link:

"and is subject to the same restrictions as Astrée for C.

The high-level abstraction features and template library of C++ facilitate the design of very complex and dynamic software. Extensive use of these features may violate the established principles of safety-critical embedded software development and lead to unsatis­fac­tory analysis times and results. The Astrée manual gives recommendations on the use of C++ features to ensure that the code can be well analyzed. For less constrained (less critical) C++ code, we recommend using the standalone RuleChecker."

So, it still does require a language subset that reduces complexity to benefit from the full analysis. They have greatly expanded what errors they catch since I first read about them. So, thanks for the link.

[koakuma-chan]

I researched and discovered kani https://github.com/model-checking/kani, it's pretty cool.

```rust

#[kani::proof]

fn main() {

    let mut array: [i32; 10] = kani::any();

    array.sort_unstable();

    let index: usize = kani::any_where(|i| *i > 0 && *i < array.len());

    assert!(array[index] >= array[index - 1]);

} ```

[cynical_german]

I do, and will, the industry does and will, for at least a few more decades. And I even enjoy doing so (with C; C++ is more forced upon me, but that'll be the case for some time to come)

[koakuma-chan]

That’s what I’m saying. By a few decades you and most of those alleged 7 million C/C++ developers will retire and there won’t be anyone to replace them because everyone will be using Rust or Zig or Go.

[quibono]

Very strong statement, one I don't really believe

[koakuma-chan]

That’s what happened to COBOL, right?

[ryao]

In COBOL’s case, nobody really wanted to write software in it in the first place. People used assembly or FORTRAN at the time. MBAs wanted a language corporate secretaries could use, so they made COBOL. It failed at its main purpose, but since IBM pushed it for business processing, people were coerced into writing software with it since if they did not use it, they would not have a job. As the industry developed, they stopped finding new people that they could coerce into using it and the old people started retiring/dying. Unlike COBOL adoption, C and C++ adoption occurred because software engineers wanted to use them due to merit.

[koakuma-chan]

> anything from embedded on the weirdest platforms, basic parsing, writing compilers, language design, high performance computing, teaching of algorithms, data structures, distributed systems, whatever

All that is language-agnostic and doesn’t necessarily have anything to do with C.

[cynical_german]

Yes, but there is material covering all of those aspects with implementations in C plus libraries plus ecosystem support! From teaching material to real world reference implementations to look at and modify and learn from.

And C maps so directly to so many concepts; it's easy to pick up any of those topics with C; and it being so loose makes it even perfect to explore many of those areas to begin with, since very quickly you're not fighting the language to let you do things.

[koakuma-chan]

People may learn from material that uses C for illustration purposes, but that won’t prompt them to write their own C. And don’t even mention ecosystem support in C/C++ where developers are notorious for reimplementing everything on their own because there is no package manager.

[cynical_german]

"rust import csv-parser" "you've installed 89 packages"

why is my executable 20 mb, not as performant as a 50 kb C file & doesn't build a year later if I try to build with 89 new versions of those packages

obligatory xkcd reference: https://imgs.xkcd.com/comics/dependency_2x.png this is what package managers lead to

[kstrauser]

Conversely, "why does my hand-written CSV parser only support one of the 423 known variants of CSV, and it isn't the one our customer sent us yesterday?"

You kind of have a point behind dependency hell, but the flip side is that one needn't become an expert on universal CSV parsing just to have a prayer of opening them successfully.

[koakuma-chan]

You are greatly exaggerating the numbers, and Rust and its ecosystem are known for being stable. Are you saying everyone should write their own csv parser? Also it’s highly likely that an existing CSV library would be optimized, unlike whatever you wrote ad-hoc, so your performance argument doesn’t hold.

[cynical_german]

I'm saying package managers automate dependency hell and software is and will be less stable & more bloated as a consequence. And one should know how to write a csv parser and yes, even consider writing one if there are obvious custom restraints and it's an important part of one's project.

(and yes, numbers were exaggerated; I picked something trivial like a csv parser pulling in 89 packages for effect; the underlying principle sadly holds true)

[imtringued]

That applies to your distro package manager too.