I haven't used Rust extensively so I can't make any criticism besides that I find compilation times to be slower than C

I find with C/++ I have to compile to find warnings and errors, while with Rust I get more information automatically due to the modern type and linking systems. As a result I compile Rust significantly less times which is a massive speed increase.

Rusts tooling is hands down better than C/++ which aids to a more streamlined and efficient development experience

▲

bch 5 days ago | parent [-]

> Rusts tooling is hands down better than C/++ which aids to a more streamlined and efficient development experience

Would you expand on this? What was your C tooling/workflow that was inferior to your new Rust experience?

▲

simonask 4 days ago | parent [-]

Not the GP, but the biggest one is dependency management. Cargo is just extremely good.

As for the language tooling itself, static and runtime analyzers in C and C++ (and these are table stakes at this point) do not come close to the level of accuracy of the Rust compiler. If you care about writing unsafe code, Miri is orders of magnitude better at detecting UB than any runtime analyzer I've seen for C and C++.

▲

uecker 4 days ago | parent | next [-]

I do not think package management should be done at the level of programming languages.

	▲	adwn 3 days ago \| parent \| next [-]
		Strictly speaking, Cargo isn't part of the Rust programming language itself. Cargo is a layer on top of Rust, and you can use the Rust compiler completely independently of Cargo. I think bazel, for example, can compile and handle dependencies without Cargo.
	▲	simonask 3 days ago \| parent \| prev [-]
		I agree, it should be done at the project level - that is, if you care about portability, reproducibility, deployment, etc.

▲

johnisgood 4 days ago | parent | prev [-]

Pacman is extremely good, too, for C. :)

▲

simonask 4 days ago | parent [-]

Pacman solves a different problem. Cargo manages your project's dependencies, not system packages.

	▲	johnisgood 4 days ago \| parent [-]
		I know, but often that is all you need for C.

▲

kazinator 4 days ago | parent | prev | next [-]

The popular C compilers are seriously slow, too. Orders of magnitude compared to C compilers of yesteryear.

▲

ykonstant 5 days ago | parent | prev [-]

I also hear that Async Rust is very bad. I have no idea; if anyone knows, how does async in Rust compare to async in C++?

▲

01HNNWZ0MV43FF 4 days ago | parent | next [-]

I am yet to use async in c++, but I did work on a multi threaded c++ project for a few years

Rust is nicer for async and MT than c++ in every way. I am pretty sure.

But it's still mid. If you use Rust async aggressively you will struggle with the borrow checker and the architecture results of channel hell.

If you follow the "one control thread that does everything and never blocks" you can get far, but the language does not give you much help in doing that style neatly.

I have never used Go. I love a lot of Go projects like Forgejo and SyncThing. Maybe Go solved async. Rust did not. C++ did not even add good tagged unions yet.

	▲	eru 4 days ago \| parent \| next [-]
		Go (at least before generics) was really annoying to use. Doing anything concurrent in Go is also really annoying (be that async or with threads), because everything is mutable. Not just by default but always. So anything shared is very dangerous.
	▲	ykonstant 4 days ago \| parent \| prev [-]
		Thanks for the info!

▲

ViewTrick1002 4 days ago | parent | prev [-]

> I also hear that Async Rust is very bad.

Not sure where this is coming from.

Async rust is amazing as long as you only mix in one more hard concept. Be it traits, generics or whatever. You can confidently write and refactor heavily multithreaded code without being deathly afraid of race conditions etc. and it is extremely empowering.

The problem comes when trying to write async generic traits in a multithreaded environment.

Then just throwing stuff at the wall and hoping something sticks will quickly lead you into despair.