[lionkor]

While I agree, I also have to say that Rust does a lot more than just solve some specific C and C++ issues. It doesnt solve all of them (e.g. logic errors, so if thats 90% of your issues you wont benefit too much), it repeats some design issues of C++ (massive complexity from the start, many ways to do the same thing), and implements a C-like unsafe{} language anyways.

If Rust was just C but with strong typing, a borrow checker and what would basically be suoer strong static analysis of pairing malloc() and free(), people would likely switch immediately.

But it isnt - its a whole different beast which by far is not perfect and repeats many issues it didnt need to repeat (e.g. terrible async like python).

Its just so good at having a compiler that tells you whats wrong that most of the other things are not that bad, and switching to Rust is likely good for 80%+ of C projects.

[flohofwoe]

> If Rust was just C but with strong typing, a borrow checker and what would basically be super strong static analysis of pairing malloc() and free(), people would likely switch immediately.

This is in a nutshell why I haven't switched to Rust. All I actually want is a small language like C, Go or Zig, but with compile time memory safety guarantees. Even if it means that a lot of 'dangerous' flexibility is removed or in an unsafe{} block (essentially a Rust--).

IMHO one problem with Rust is that it is moving too quickly into too many different directions, and as a result becoming a 'kitchen-sink language' in the tradition of C++.

[oconnor663]

> just C but with strong typing, a borrow checker and what would basically be super strong static analysis of pairing malloc() and free()

Most of Rust's features interact in ways that aren't obvious. For example to get the basic memory safety guarantees that the borrow checker provides, you also need:

- the "no mutable aliasing" rule

- destructive move semantics and the Copy trait

- generic containers like Mutex and (probably?) generic enums like Option and Result

- thread safety traits like Send and Sync

- closures, and closure traits like FnOnce

Of course yes, you can have "safe C" without async, and Rust 1.0 shipped without async. But I think it's notable that The Book doesn't teach async. Most of the things The Book teaches are actually necessary for memory safety to work.

[lionkor]

It doesnt matter what The Book teaches - for example a majority of Rusts web-facing ecosystem uses some async, which means

1) tokio, which uses unsafe{}, and/or

2) async functions requiring all calling functions to also be async

So, really, you can't avoid it. The ecosystem is built on the idea of NIH, which is fine, if it wasnt for so many rust features you can abuse so heavily (e.g. macros to make your own language that I then have to learn).

There are a lot of issues with the complexity Rust brings.

[flohofwoe]

IMHO a 'rusty C' wouldn't need to cover the entire memory safety feature set that Rust provides, it just needs to be 'close enough' and otherwise warn in areas where the compiler isn't entirely sure. It can also do some checks at runtime at the cost of a slight performance hit (but again, in old C tradition this should be controllable by compile options).

[Ygg2]

> But it isnt - its a whole different beast which by far is not perfect and repeats many issues it didnt need to repeat (e.g. terrible async like python).

Not gonna lie, I don't see too much value in async, but that said, I can see where they (the Rust devs) are coming from. It was an oft requested feature, and it was in the pipeline for ages, leading to Rust dev burnout.

That said Rust team is working on making it fully usable, albeit the space of efficient, zero-cost abstraction closures that work with lifetimes is a set of one language - Rust.

[Ygg2]

Not closures - async runtime.