[nickpsecurity]

I'd like to write Rust, receive its safety benefits (esp borrow checker), compiler to equivalent C, and then use C's tooling on the result. Why use C's tooling?

In verification, C has piles of static analyzers, dynamic analyzers, test generators (eg KLEE), code generators (eg for parsing), a prover (Frama-C), and a certified compiler. If using a subset of these, C code can be made more secure than Rust code with more effort.

There's also many tools for debugging and maintenance made for C. I can also obfuscate by swapping out processor ISA's because C supports all of them. On the business end, they may be cheaper with lower watts.

I also have more skilled people I can hire or contract to do any of the above. One source estimated 7 million C/C++ developers worldwide. There's also a ton of books, online articles, and example code for anything we need. Rust is very strong in that last area for a new language but C/C++ will maintain an advantage, esp for low-level programming.

These are the reasons I'd use Rust if I wanted C or C++ for deployment. Likewise, I wish there was still a top-notch C++ to C compiler to get the same benefits I described with C's tooling.

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

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

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

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

> 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]

> 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

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

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

[uecker]

I think we will get the same safety benefits of Rust in a version of C relatively soon.

[koakuma-chan]

Borrow checker is not the only feature that makes Rust great though.

[uecker]

Yes, it also has many aspects I do not like about it. Let's not pretend everybody shares your enthusiasm for it.

[koakuma-chan]

What aspects do you not like about Rust?

[uecker]

Too much complexity, long build times, monomorphization, lack of stability / no standard, poor portability, supply chain issues, no dynamic linking, no proper standard, not enough different implementations, etc. It is a nice language though, but I do not prefer it over C.

[koakuma-chan]

> long build times, monomorphization

Monomorphization is what causes long build times, but it brings better performance than dynamic dispatch.

> lack of stability

There was another comment which also never elaborated on how Rust is not stable.

> supply chain issues

Not a language issue, you choose your dependencies.

> no proper standard, not enough different implementations

Is that a practical problem?

> no dynamic linking

There is.