Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

It is better, definitely safer. But it's not perfect. I write rust on a daily basis. I've written a lot of C++ in the past. It's safer, but I have memory safety issues in both. It's more a matter of degree.

For a large existing code base that are well written I think it's easier to improve the safety of the existing code than rewrite it completely in a safer language.



sort by: page size:

It is not "better" it is different. Rust is "safer" although with the modern C++ along with tooling I do not really encounter any safety issues for about 3 years already. Looking at feature set C++ has way more. In my opinion Rust sits somewhere between C and C++.

This is true. Rust also provides more compile time safety (a lot more actually), but it comes at the cost of complex semantics.

Rust doesn’t stop you from writing buggy code. However I do agree that it is easier to write memory safe code in Rust compared with C/C++.

They are generally better than nothing, however. And they do generally offer better performance, better predictability, an a simpler implementation than other approaches to memory management and garbage collection.

Maybe a language like Rust will offer a safer alternative at some point, but that point surely isn't today, and probably not tomorrow, either. Maybe there are other languages that offer better safety, but they often bring along their own set of very serious drawbacks.

In terms of writing relatively safe code today, that performs relatively well, that can integrate easily with other libraries/frameworks/code, and can be readily maintained, the use of C++ with modern C++ techniques is often the only truly viable option.


I dunno, Haskell, sure, but Rust is just all around better C++... memory safety is just plainly less bugs and that's always desirable

I think you're reading into the comment too much. Rust by definition, will create a safer variant of whatever similar code you write in C or C++. This isn't really debatable, things like bounds checking on arrays, strongly typed error results, thread safe memory sharing semantics. These will absolutely guarantee that in general you will have safer code in Rust.

What I said is that it might take you longer to write it in Rust, than something similar in C/C++, but you won't have some of the guarantees you get from the Rust semantics. So the tradeoff is up to you; write code faster, or write code safer.


C++ is definitely better but it's still not memory safe. Compared to Rust, you still have little tracking which thread has access to which variable at which time. Even in modern C++, you still have to care about iterator invalidation.

Yes, banging on about memory safety sells Rust short, and drives away exactly the people who would benefit most from improved memory safety.

The language is just overwhelmingly better to code in than C, or Java, or C#, or Go. If the compiler were to be made fast -- and there is nothing like a fast compiler coded in your language to advertise its speed (and the reverse!) -- or anyway JITted, with a REPL, it could replace a great deal of scripting.

The comparison to C++ is much less compelling. Rust fans like to lump C and C++ together, but in modern C++ there are few temptations to memory unsafety. (They might be misled by crufty Mozilla code.) Meanwhile, the greater expressivity of C++ enables more powerful libraries, and each use of a good library eliminates many more than just memory bugs.


I agree that Rust is the better language because it gives you the safe tools by default.

Smart pointers are no panacea for memory safety in C++ though: even if you use them fastidiously, avoiding raw pointer access, iterator invalidation or OOB access will come for you. The minute you allocate and have to resize, you're exposed.


That's reasonable; one's threshold of "safe enough" factors in.

If one is just designing a game, or a command line tool for internal use, one needn't make it completely rock solid, and C++ has the better learning curve.

If one includes the requirement to make it safer, Rust has the better learning curve.

And then if someone actually values memory safety, they use a GC'd language and laugh at how many engineer-months and proofs it will take us to make code as safe as theirs. Sigh, such is life...


The comparison I like to make is that Rust is the safer/modern version of C++'s memory model. It's in a different class from most languages, but trying to apply all the latest lessons and techniques.

They're presumably gaining the other non-performance advantages of Rust over C++ (i.e. the borrow checker etc.) though, so safer and faster is a win. As you say though, they seem to focus on performance but that might just be the audience they see themselves talking to.

My understanding is that Rust provides memory safety with less overhead than languages that provide memory-safety via garbage collection. This comes at the price of some extra cognitive load for developers, but is appropriate for many applications where the added performance is needed.

(Not necessarily "better" overall, but a better choice for certain applications.)


Maintaining memory safety, thread safety, and avoiding UB is still much easier in Rust than C++. In C++ you have be vigilant to avoid a mistake slipping in. In Rust, you get a compile error if you make a mistake.

While they introduce constructs that significantly increase the safety of C++ written with them, they still have edge cases due to the C++ committee's commitment to backwards compatibility.

So while C++ is certainly improving, Rust has a fundamental advantage in the safety department.


I'm a fan of Rust and use it for side projects, but what in particular about this is better in Rust, other than the compile time checking? Or do you mean that because Rust is safe, you can write it faster?

Personally, I use Rust as a "better C++".

Ways in which it is better:

* A decent package manager

* "Safe by default" (you have to use 'unsafe' to turn off the safety features), unlike C++ which is "unsafe by default" (v[i] is undefined behaviour if i is out of bounds, for all of C arrays, std::arrays and std::vectors).

* Really easy to do multithreading -- I had reached the point with C and C++ where I was of the opinion it is "almost impossible" to write large thread-safe programs, and all communication should be between processes with pipes, wherever reasonable. In Rust I again feel I can safely and productively write multi-threaded code.

The things Rust doesn't let you do (throw pointers around everywhere) can get a little annoying, but I find the extra safety increases my productivity enough that it's worth the tradeoff.


In short: the type system is significantly more expressive and encourages domain modeling that tends to lead to fewer errors; "if the compiler says it's OK, it'll be OK" isn't strictly true but it's often pretty close. Rust also offers stronger guarantees around memory safety than C, as well as C++ as commonly practiced. (Which is to say, you can write very memory-safe C++, but you will work at it.)

With Rust you get safety at compile time while avoiding memory safety issues at runtime. The compile times are objectively longer compared to most other languages. But whether this trade-off is worth it for you depends a lot on your company's CI pipeline and the skill of the developers.
next

Legal | privacy