Easy on the propaganda there.

* "First viable replacement for C" - C++ was invented decades before Rust.

* "Well-written C programs translate almost 1:1 to Rust" - C programs can be compiled with minimal changes as C++.

* "or didn't offer meaningful improvement in safety/concurrency/expressiveness." - C++ offers major improvements in all of those areas.

A lot of C programmers don't want to switch to C++ and they won't want to switch to Rust either, because they favor simplicity and neither Rust nor C++ are simple. They'll probably switch to golang for some stuff if anything and just stick to C for the rest.

I'm a C programmer who switched to Rust.

Rust is complex because it's powerful.

C++ is complex because it's a mashup of overlapping features from different eras.

I don't write C++, because whatever I write will crash for subtle reasons and I'll be told it's my fault, because of course you don't do this when you use that feature.

I can write Rust with all its complexity, and as long as I get it to compile, I'm confident it works more reliably than any C++ that I could have written.

On my system (2015 MBP running Ubuntu 16.04) Rust's hello world compiles to a nearly 3.5 MB executable. Compiling the equivalent C program with clang results in an executable under 9 KB. Rust may not have a GC, but its executables are certainly fat.

Note: Rust executables can be trimmed down by stripping them (not done by default, even for release builds) and using libc malloc instead of jemalloc. But even then, C wins by a lot.

Relevant blog post: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab...

> But even then, C wins by a lot.

C links dynamically to its libraries. Rust does not (by default).

This overhead is a constant overhead so it rarely matters. When it does, you can strip it down further and get it to the same level as C.

This is not evidence of a fat runtime, just a different default compilation strategy that prodces larger binary executables. jemalloc is (an optional) part of the runtime, but the rest isn't.

Sure. It's not a fair comparison. But dynamically linking rust's std isn't an option. If you are optimizing for executable size, c wins because dynamically linking libc is possible. This is even true controlling for glibc, since most rust code also dynamically links glibc too (including hello world). In fact, rust's hello world has quite a few more shared dependencies than the equivalent c anyway: it uses libdl, librt, libpthread, and libgcc_s as well.

Dynamically linking to rust std (with a specially compiled libstd dylib) is an option iirc, just that nobody does it. Lack of stable ABI makes it less useful, but if you really need to do it there's nothing stopping you.

I suspect rust hello world using those libraries is due to a lack of LTO? Hello world doesn't need any of those.

Not a particularly fair comparison though, as that C binary is loading dynamic libraries that are already in memory. Case in point: that C program needs the C standard library, but by default that library (glibc) is dynamically loaded. Rust is not offering the Rust standard library as a dynamic library, hence the larger size. Not to mention, interfacing with C functions in the kernel.

You'll get different results if you compile them with musl for truly static and fair binary size comparisons.

I am no expert, but you should compile barebone executable for comparing executable size! not "hello world", because hello world does use shitload of library (for printing and loading and stuff), and those ones in C is compiled in dynamic, but in rust those compiled inot executable itself.

if I remember correctly you should compile with --nostd flag and provide _start function for loader to load your executable!

you can do same with rust too (But I think you should provide a special flag for compiler). You can find all of it on documentation.