On 03/03/14 08:36 PM, Lindsey Kuper wrote: >> On Mon, Mar 3, 2014 at 10:19 PM, Steve Klabnik <st...@steveklabnik.com> >> wrote: >>> >>> Part of the issue with that statement is that you may or may not >>> program in this way. Yes, people choose certain subsets of C++ that >>> are more or less safe, but the language can't help you with that. > > On Mon, Mar 3, 2014 at 6:22 PM, Fernando Pelliccioni > <fpellicci...@gmail.com> wrote: >> Then, you could show this in the article, using the "good" subset of C++. >> Then people can choose. > > I think Steve's point is that, with Rust, you get a language-level > guarantee. With C++, you can avoid the unsafe parts, but to do so you > have to be especially vigilant; it's easy to accidentally get into > unsafe territory. With Rust, you always know when you're stepping > into unsafe territory. At least, that's the goal.
It's no harder to avoid direct usage of `malloc` in C++ than it is in Rust. Rust doesn't make this more explicit anyway, and `malloc` technically shouldn't be considered unsafe at all because we do not consider memory leaks unsafe. There are ways Rust improves on safety like lifetimes and preventing use-after-move... but this isn't one. As a C++ programmer, comparisons like this would stop me from looking into Rust if I wasn't already familiar with it. It makes it seem like the language is just a "me too" attempt at fixing problems that are not broken in C++. No one stops you from writing your entire Rust program with `unsafe` functions just as no on stops you from using `malloc` everywhere in C++. Neither takes more vigilance to avoid.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
