[koakuma-chan]

Rust is much easier to learn due to C/C++ books all being paid (even cmake wants you to buy their book) whereas Rust documentation is free. I bet more and more people are choosing to learn Rust over C/C++ for this reason, and the number of C/C++ devs will be decreasing.

[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/

[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?

[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.

[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.

[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?

[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.

[imtringued]

That applies to your distro package manager too.

[uecker]

Probably not. Many people prefer C/C++ to Rust, which has its own fair share of problems.

[koakuma-chan]

Two people is many people. The general trend I see is that Rust is exploding in adoption.

[icedchai]

The last I checked various stats (GitHub Language stats, TIOBE, etc.), Rust wasn't even in the top 10. I'm sure its adoption is increasing. However, other languages like Go seem to be doing much better. Neither will replace C++ or C anytime soon.

[koakuma-chan]

C/C++ will be replaced incrementally and it’s already happening. Cloudflare recently replaced nginx with their own alternative written in Rust for example.

[icedchai]

That's nice, but a couple of Rust rewrites are not proof of a general trend.

I've been working with C for over 30 years, both professionally and a hobbyist. I have experimented with Rust but not done anything professionally with it. My gut feel is Rust is too syntactically and conceptually complex to be a practical C replacement. C++ is also has language complexity issues, however it can be adopted piecemeal and applied to most existing C code.

[koakuma-chan]

> My gut feel is Rust is too syntactically and conceptually complex to be a practical C replacement.

That would depend on what you use C for. But I sure can imagine people complain that Rust gets in the way of their prototyping while their C code is filled with UB and friends.

[koakuma-chan]

> That's nice, but a couple of Rust rewrites are not proof of a general trend.

It’s not just a couple. We’ve seen virtually all JS tooling migrate to Rust, and there is many more things but I can’t remember by name.

[uecker]

It is, but it is still tiny compared to C/C++. And many people also do not like it.

[koakuma-chan]

There are two categories of people who don’t like Rust:

1. C/C++ developers who are used to C/C++ and don’t want to learn Rust.

2. Go developers who claim Rust is too difficult and unreadable.

Which one is you?

[uecker]

I think the "don't want to learn" is a very poor argument. I learn stuff every day, but I want want to decide myself what I learn to solve my problems, not because Rust folks think everybody has to learn Rust now. I learned a bit of Rust out of curiosity, but not so much I could do a lot with it. I do not want to learn more, because I think the language has severe flaws and and much less suitable than C for my use cases.

[ryao]

I know a guy who used to love Rust and his cannot stand it. The hype wore off in his case.

[koakuma-chan]

Does he prefer fighting libtool, make, cmake, configure, automake, autoconf and autoreconf just to add a couple libraries into his project? When I tried to use C, I wrote 10 lines of code and spent hours trying to make all that shit work. It makes me laugh when people say Rust is complicated.

[ryao]

Autocorrect seems to have made a typo worse here. It was supposed to be now, not his.