[flohofwoe]

Rust-the-language may be medium-sized. Rust-the-stdlib though?

The Rust stdlib has a lot of essential low-level types needed for adding a 'semantic layer' on top of the language so that the language user can exactly 'express intent' (types that arguably should be language features instead). Just look at all those detailed methods needed to make RefCell work, and what does 'into_inner' or 'undo_leak' even mean?

https://doc.rust-lang.org/std/cell/struct.RefCell.html

E.g. what's a single concept in C (e.g. "the pointer") easily has a dozen specialized equivalents in Rust, just because Rust needs the additional information to do its memory safety magic correctly.

The entirety of Rust and its stdlib has a huge 'semantic surface' compared to most other languages (even C++), and I think this difference in the semantic surface size to other languages is exactly the one thing that either attracts or repels people to/from Rust ;)

[khuey]

> what's a single concept in C (e.g. "the pointer") easily has a dozen specialized equivalents in Rust

That "the pointer" is a single concept in C is the root cause of absurd numbers of bugs over the history of C.

The questions of how long the memory a pointer points to lives, what threads it is safe to access from, and how it is allocated and destroyed all still exist in C. Those answers are just implicit rather than explicit like they are in Rust. It's not like Python/etc where you don't have to worry about these things.

[flohofwoe]

In general I agree, but this topic is IMHO exactly what separates the Rust lovers from the Rust haters ;) E.g. how strong is too strong when it comes to type systems. Rust afficionados generally seem to tend towards 'the stronger the better', and accepting the downside of a fairly rigid code base.

I prefer a middle ground between strong and weak typing (but yeah, C is arguably too weakly typed, but the exact sweet spot is different for every programmer).

A reasonably smart C compiler that has visibility on all code in a project could theoretically infer a lot of the same semantic details that must be manually provided in Rust by looking at how the pointer is used in the wider codebase (basically what static analyzers are doing by reconstructing control flows). Of course such an extensive analysis would result in even worse compile times than Rust ;)