7 ms·

The kind of safety guarantees Rust provides are, in my opinion, insufficient justification for experienced developers to move from C or C++. Rust has other feat

• db48x 10y ago
  If only these mythical experienced developers that never shoot themselves in the foot actually existed.
  • keldaris 10y ago
    Infallible developers don't exist, but use cases where the particular class of errors eliminated by Rust's safety guarantees is insignificant certainly do.
  • sidlls 10y ago
    I'm terribly sorry you've never encountered an experienced developer who uses C or C++ before, or think we're non-existent, or that using extremes like "never" is a reasonable position instead of an incredibly terrible hasty generalization. If there were as many blown off feet as comments on HN suggested technology even as it currently is simply wouldn't function. Do you even understand how much mission and safety critical software is written in C? I think if you did you'd either have a constant panic attack (given your apparent belief that it's impossible to write "safe" C) or else have to adjust your world view a little bit.
    • empath75 10y ago
      No one has ever argued that it's impossible to write c code, but just because you haven't found those kinds of bugs in your code, doesn't mean that it isn't there. We're still finding 10+ year old bugs in Linux.
      • zerofan 10y ago
        I'd like to see if Rust is still around in 10 years and then look before we declare the winner on this.... All software has bugs.
        • steveklabnik 10y ago
          It's been around for roughly six or eight already, depending on how you count. Of course, pre-1.0 was a different thing, but still. Ten years is not that long a time. (I still agree that results at that point will be more interesting then speculating today.)
          • zerofan 10y ago
            > It's been around for roughly six or eight already, depending on how you count. I don't think you get to play on both sides of that fence. Some of your team has been working on Rust for that long, but I doubt any code with sigils compiles, and I doubt there were many large projects using it then. I started my stopwatch at May 2015. > Ten years is not that long a time. Totally agree. > I still agree that results at that point will be more interesting then speculating today. We'll see on May 2025. :-)
            • steveklabnik 10y ago
              Yeah that's why I said it depends. :) periodization is tough. 18 months, four years, six years, and 9ish years are all valid, depending on how. What I mean to say is that it's already been quite a while, and now that it's making its way into distros and required for building Firefox and all that, I think it has even more of a chance of sticking around for a long time, given that it was around for quite a while when it wasn't even a viable "real" language. I don't mean to insinuate that today's Rust is mega mature because those old Rusts exist.
      • sidlls 10y ago
        Who claimed I haven't found these kinds of bugs in my code? My response was to a commenter who, as far as I can tell, represents the mainstream Rust community's view: that it's impossible to write safe C or, worse, that infallibility is a reasonable standard to apply. The latter is especially vex-some from my point of view, because Rust is not infallible, I happen to find it (so far) much more pleasurable to use than either C or C++, and I would very much like to see it have broader adoption.
    • db48x 10y ago
      Sure, all things are possible. It is _possible_ to write perfect code, it's just not very likely. However, under commercial conditions it is so unlikely as to be implausible; you just won't have the time or budget for it. NASA can do it, most of the time, but the difference is that they take the time to find all of the bugs, not that they can write the code perfectly the first time through.
  • j1vms 10y ago
    > If only these mythical experienced developers that never shoot themselves in the foot actually existed. Rust is a great language, but people have to stop "marketing" it by saying things like: no matter how great you are with C, you're going to fuck up at some point, so that's why you should be using Rust. Like Go or whatever other language, the main grab needs to be a positive: you know what you're doing, and here's how (a, b, c... etc.) Rust will make you even better at what you do. Another point, it's safe to say C isn't going away anytime soon, it sits nicely at the next approximately natural level (in abstraction) above assembly. That was a design point in the language. Yes it can be a rough tool to use, but that's a reality when you get closer to the metal. You get tremendous flexibility and that comes at a price, as all things do.
    • chousuke 10y ago
      I don't see it as a negative, really, just realistic. It is a fact that everyone makes mistakes, and with the inherent complexity and features that are demanded of modern software, it is harder and harder to maintain a comprehensive understanding of a codebase so that you can detect these mistakes before they cause damage. This means that even if you are a perfect developer, you need to expend a lot of energy to maintain that perfection if you're using tools that don't help you. To me, modern tools like Rust are supposed to relieve part of the burden. In the common case, if I can be reasonably certain that I can't make certain classes of errors, my brainpower is freed to focus on other things and I can work with significatly less stress. Rust is interesting because it allows you worry less without actually compromising much in capability. In the cases where I would need to be able to bypass the tooling, it is explicitly possible.
• keldaris 10y ago
  I completely agree. The biggest reason I haven't seriously tried Rust yet is because, despite all the vocal pro-Rust opinions we've all been inundated lately, I struggle to name a single interesting thing about the language apart from "safety". I wish the Rust evangelists would come to terms with the fact that to many developers memory safety is not a particularly important concern (for many different and often very good reasons) and talk more about other aspects of their language. The tooling seems nice, but far from unique (D, Go and other languages are quite competitive there). It would be far more interesting to hear more about, say, traits (can it compete with C++ in compile time polymorphism?) and other technical aspects that make Rust stand apart from its competitors.
  • zerofan 10y ago
    Rust did a nice job with algebraic data types. Haxe has a very similar approach, and I've loved it since I first saw it. I think this is a very elegant way to define data structures. I listed plenty of complaints about Rust in my other comment, but this one stands out as a "single interesting thing" worthy of praise.
  • twblalock 10y ago
    > I wish the Rust evangelists would come to terms with the fact that to many developers memory safety is not a particularly important concern (for many different and often very good reasons) and talk more about other aspects of their language. Seriously. However, I've seen a lot of comments to that effect from C and C++ programmers who don't want memory safety. I come at it from a different angle: I'm a Java developer, so I already have memory safety. Pointer arithmetic, dangling pointers, and buffer overflows are not allowed, there is a garbage collector, and so on. In fact, most of the currently popular languages other than C and C++ are memory safe in similar ways. So, in terms of memory safety, Rust does not give me anything critical that I don't already have. When choosing among the memory-safe languages for a real-world project, I'm going to need a pretty compelling reason to choose Rust instead of Java, Scala, Go, Ruby, Python, etc. -- especially when it is so much easier to hire developers for more popular languages.
  • Manishearth 10y ago
    I see a lot of folks talking about this, but I live in a Rust bubble. From my POV a lot of the folks using Rust use it for primary reasons other than memory safety; many could afford to use python or something and get away with it. I suspect there are fewer blog posts about this, however. I'll take a shot at some of the advantages: Algebraic datatypes: Seriously. These are amazing. C++ has them with Boost's variant (and now std::variant), but they're awkward to use, making them somewhat a niche instead of the very central place they take in Rust programming. Till now ADTs were mostly the domain of functional languages, so I'm very happy that Swift and Rust giving them first class support and making them essential. ADTs in Rust work with the enum keyword: enum Shape { Rectangle(Point, Point), Circle(Point, u32) } let some_shape = Circle(Point::new(1, 2), 5); match some_shape { // like switch, but with pattern matching Rectangle(p1, p2) => println!("Rect from {} to {}", p1, p2), Circle(p, radius) => println!("Circle at {} with radius {}", p, r) } An enum is essentially an "or" type; i.e. "a Shape is a Rectangle (X)OR a Circle". You are forced to handle this fact when you access this data -- if you try to access the stuff inside some_shape, you must match (or use a method that does this for you), and the match must be exhaustive (cover all cases). This is how null works in Rust -- if you want to say something is nullable, you use `Option<T>` -- `Some(T)` for when it's there and `None` for when it's null. You're forced to check for the none case if you want to be able to get to the inner data. You can call `.unwrap()`, but internally that's a method that just does a match and panics in the error case. Traits: I mention this elsewhere in the thread, but Rust metaprogramming via generics cannot and will never beat C++ TMP's level of expressivity. Rust is going to get procedural macros which make it easier to fill in that gap of metaprogramming in a less hacky way, but if you just compare generics and templates then templates can do a lot more. However, that's not necessarily a good thing. The way templates are structured; they basically get "monomorphized" at something akin to parse time. This means that the error messages can be atrocious, and an API can never be self-documenting since you have to explain what kinds of types can be passed in. On the other hand, in Rust, if you get a function from a library you can pretend that it's a black box. The error messages will never mention the contents of the box. You can adequately figure out how to not make the compiler error out by looking at the type signature. The way Rust traits work is that you first define them: trait Frob { fn frob(&self, frobbee: &str); } Then you implement them: impl Frob for SomeType { fn from(&self, frobbee: &str) { println!("{} frobs {}", self, frobbee) } } Now, you can write functions (or types, or methods, or whatever) which accept these: fn frob_something_10x<T: Frob>(frobber: T, frobbee: &str) { for _ in 1..10 { frobber.frob(frobbee) } } If I did not have the `T: Frob` bound, I would not be allowed to write this method; the compiler would say that type `T` doesn't have a frob method, and I'd be forced to add a bound that gives it one. If a library user passed the wrong type to the function, the compiler will tell them that their type doesn't implement Frob, at which point they can add an implementation or use a different type or whatever. It's a very nice, clear API separation which leads to clear error messages and makes it easier to figure out what kinds of types to use. It also means that in the autogenerated docs I can just click on the trait to find out what types I can feed to the function -- in C++ many codebases have their own bespoke "trait" system using template specialization but it won't work with the docs and still lends itself to rabbit-hole-y error messages. Moving: I personally find the lack of copy/move constructors and default construction to be very nice. In Rust, uninitialized types aren't a thing; initialization is always explicit. Copies are just copies, moves are also just copies, and moving is the default (except for POD types). There's no unknown overhead to deal with when I push to a vector, for example. Move-by-default and affine types IMO make it very easy to think about the program.
• shmerl 10y ago
  > The kind of safety guarantees Rust provides are, in my opinion, insufficient justification for experienced developers to move from C or C++. Avoiding security related issues based on a whole class of problems prevented in Rust by design is a huge benefit. It's better for compiler to prevent that, than to rely on levels of experience, while anyone can make a mistake in reality.
  • rubber_duck 10y ago
    Rust only deals with half of the story at the compile time because it can't deal with stuff like cyclical refs, etc., and even without it it also makes a lot of valid code invalid because of it's borrowing rules. That's not saying that borrow checker is worthless but it does add overhead and frankly in a lot of scenarios that's just not necessary, even with all that fancy compile time checking you still need to do testing and there are many applications where "working for the stuff tested" is enough. Obviously when you're writing a browser that people will try to exploit and you need to execute third party code and load content from entrusted sources things will be different. So I get where OP is coming from, Rust safety is oversold IMO - it's nice but it's not the only thing that's interesting about Rust - just the fact that it has modules, an official build system and a package manager that's used by everyone is enough for me to consider it over C++. It's lacking IDE like tooling and meta-programming capabilities (in stable at least)
    • Odin78 10y ago
      > That's not saying that borrow checker is worthless but it does add overhead It's important to emphasize out that this is compile time overhead, not run-time overhead.
      • millstone 10y ago
        It adds runtime overhead by forcing the programmer to work around the single-ownership rules, via runtime checking (Arc, etc) and more expensive interfaces. For example, consider a simple thread-local counter. In C this would be e.g. an object in the tdata section, accessible via thread-local addressing. But in Rust, you have to use something like RefCell, which requires runtime tracking of mutable borrows. So Rust's borrow checker inflicts runtime overhead in this case.
• mmstick 10y ago
  I've seen fatal flaws from supposed experienced C and C++ developers in a large number of high profile projects, that would otherwise be nuked from existence had they used Rust. I've also encountered severe flaws in libraries written by experienced programmers working for companies like Google and Red Hat that the Rust compiler caught during translation to Rust. That's not counting the immense amount of tooling and features that make managing large projects a breeze in Rust. Managing a 100K Rust project with a large team is easier than managing a 100K C++ project with a large team. You can't guarantee that no one will ever make mistakes. I find segmentation faults to be common place in C/C++ projects from experienced developers, and it's quite difficult to debug them at times.
• jtmarmon 10y ago
  It's important for a lot of people and that's why it's marketed like that. It's also one of the most unique aspects of the language, and the primary goal of the entire project. According to steveklabnik, about 50% of Firefox's critical security bugs were due to memory safety issues (source: <https://www.youtube.com/watch?v=_-fweBvtifA&t=27m20s> https://www.youtube.com/watch?v=_-fweBvtifA&t=27m20s>) Presumably you don't think mozilla exclusively hires shitty developers.