[humanrebar]

Availability of C++ tooling is much, much closer to availability of C tooling (often it's the same tool!) compared to Rust. Adopting Rust isn't the same category of conversion at all.

For new side projects, pick what you want to use of course. But for existing codebases and projects that aspire to have maximum impact, I recommend fully considering tradeoffs instead of thinking in terms of "clear winners".

[insanitybit]

> Availability of C++ tooling is much, much closer to availability of C tooling (often it's the same tool!) compared to Rust. Adopting Rust isn't the same category of conversion at all.

Which tooling? Just curious, asking entirely in good faith. My recollection is that the majority of tooling I was using with C++ worked with Rust - debuggers, profilers, and sanitizers being the main tools. Although I find that I use them much less frequently since I don't find debuggers as useful for the types of bugs I have these days, and sanitizers are only useful if you have unsafe, and profilers are cool but usually I just write benchmarks using a crate and then iterate from there.

[twic]

The parent comment says "compiler tool chain", and i understand "tooling" here as meaning that. So, compiler, linker, assembler, etc.

All the major C compilers are also C++ compilers, and none are (yet) Rust compilers, so out of the gate, C++ has similar availability to C.

[epistasis]

And yet, even with that, Yann Collet credits Google's use of C++ for the compression library as a critical mistake that allowed him, an unknown, to gain traction with his own compression methods. Google later rewrote their library in C:

https://overcast.fm/+LfVPHmBTo

Even if the tool chain exists, it must be adopted, unless you can rely on binaries being available for your end users, which will never be the case for a library which is just starting our. And adding another dependency to your build process, especially one as complex and with as many breaking version changes as C++, is a lot of work to take on.

[pjmlp]

Unless we are talking about an obscure platform or some PIC CPU, a C++ compiler is available on the same box as the C compiler.

Second, extern "C" exists.

Third, in what concerns clang and MSVC, the C library is actually implemented in C++ with extern "C".

[epistasis]

My single sentence may have been too concise, there are two concepts here: 1) the tool chain may or may not exist, and 2) bringing in that tool chain to the build system.

Even if it's the "same" toolchain for compiling C++ as it is C, adding the complexity of an additional language to the build process, and the extra versioning headaches that C++ adds over C, is enough to kill library adoption.

As I said originally, providing bindings is not the challenge, it's all the other stuff.

[pjmlp]

"To Save C, We Must Save ABI"

https://thephd.dev/to-save-c-we-must-save-abi-fixing-c-funct...

[bfrog]

If you are going on proprietary tool chains... most of those are moving to llvm which rust is based on. In theory any proprietary toolchain based on llvm could provide rustc given incentives to do so.

If you are speaking to missing a rust compiler built on gcc, that seems to be an ongoing project with some momentum.

Realistically the most widely used architectures are now supported by rustc through llvm... x86, arm, riscv, and even to some extent xtensa now.

Power, arc, mips, sparc, and some others aren't too far away if someone cared enough.

If Linux can support Rust, I'd think that's a good sign most project can use Rust.

[humanrebar]

That's just the compilation toolchain. For better or worse, existing C projects have their whole workflows sitting on top of bespoke tools with the assumption that there is a C toolchain. And Rust projects assume cargo, etc. You're more or less doing a parallel rewrite in Rust to adopt Rust in an existing C project.

The Linux kernel already does extensive bespoke tooling and it's low level enough to skip cargo and such. It's rare to see that approach in Rust projects in the wild.

[insanitybit]

Are we just talking about portability then? Because "same category of conversion" seems fine - I would say that for 99.9999% of projects the difference in portability is non existent.

[pjmlp]

Basically all the libraries, IDEs, game engines, game console SDKs, HFT, HPC, OS SDKs, embedded OSes, High Integrity Computing certifications, and plenty more stuff deployed into production since C++ ARM [0] was published in 1990, 33 years ago.

[0] - The Annotated C++ Reference Manual

[junon]

That's not C++ tooling. That's tooling written in C++. Two very different things.

[pjmlp]

Word games, those are domains dominated by C++, take the meaning the way it makes you happier.

[insanitybit]

You're saying word games but you're arguing something that the poster I replied to wasn't saying.

[junon]

This is nonsense. Rust is based off of LLVM, which is what Clang is based off of. Name one modern, actually used, non-archaic system that LLVM doesn't run on. Beyond that, Cargo and all associated tooling run pretty much everywhere. So I'm not sure what outdated trope you're on about here.