4 ms·

You are right. rust is lacking many many things. C++ will still be around in 30+ years. But remember, C++ has a good 10 year head start on java, and java gained

• pjmlp 10y ago
  I am all for Rust and even though I use C++ since C++ARM, I am by no means an expert and nowadays spend most of my time in JVM/.NET lands with C++ only when I need its features. However, and that is somehow what I wanted to point out, by being part of the community I am fully aware of the uphill battle that was to make C++ relevant as it is today. We used to be flamed by the C community, like like Rust, D, Go and others are nowadays, yet the C community now has their major compilers being written in C++, funny how things turn out. So, yeah Rust or other saner systems programming language might eventually replace C++ and I would like to see it happen. But bashing the efforts of the ones that try out to make C++ safer within its constraints, because not everyone of us is able to throw out our tools and move right away to Rust, is not going to help getting those developers. For example, I would rather use C# + Rust than C# + C++/CX, but I am not going to convince any customer to allow me to do that.
  • jguegant 10y ago
    The C++ community seldom "flames" the Rust one. On the other hand, I often see C++ threads on Hackernews ending with people bashing this language ("C++ hell", "dirty language", "dying soon") and bringing Rust on the table. It is pretty frustrating when you actually want to exchange on this language, far from dead, and enjoyed by some.
    • _yosefk 10y ago
      "The C++ community flames the Rust community" right in this thread. TFA didn't say there was no merit to the "safe C++ subset" [1], just that it's not here yet, it's not going to be as safe as Rust, and that it's often mentioned as if it's here and as safe as Rust, that's why TFA called it vaporware. This thread is not refuting this claim but explicitly or implicitly blames TFA and "the Rust community" for misrepresenting C++ as dead, useless and not worthy of improvement. Of course C++ is far from dead, enjoyed by some, and used by many more; TFA did not claim otherwise. Of course improving C++ helps those using it; TFA did not claim otherwise. All it claimed was that the current and potential future state of Rust relatively to C++ was misrepresented by people at the C++ side; I think you're more supporting than refuting this claim. [1] I personally, unlike TFA and some commenters here, must say that I'm not thrilled about anything having to do with unique_ptr (which as TFA demonstrated is not guaranteed to be unique at all, but is as unique as its user made it) and other such; certainly if I have to rewrite an old code base to use new smart pointers, the change will involve every corner of that code base, and I think I'd rather rewrite it in another actually safe language if safety is what worries me. But that's just me; and BTW I haven't personally looked deeply enough into Rust to advocate for it, either.
      • jguegant 10y ago
        In that case, the blog post was explicitly comparing Rust and C++. It is not surprising that the comparison goes both way. I am talking about the HN topics like "How to implement a packet tracer in C++" or "Optimize std::vector with C++14" where invariably a comment like "Who use C++ in 2016 when you have Rust?" spawns. Rust is amazing, but that doesn't make it the de-facto answer to all the projects. Some people might still want to increase their skills in their day-to-day language like C++, even if they are aware of Rust awesome features.
• amadvance 10y ago
  Is really rust not needing valgrind, and more specifically the memcheck tool ? OK for leak detection. But is it really able to detect all not initialized memory accesses ? Anyway, I suppose that rust can still benefit from other valgrind tools, like helgrind, drd, massif and so on.
  • catnaroek 10y ago
    Using uninitialized memory is impossible in safe Rust. There's a standard library function that lets you treat an uninitialized object as if it were initialized, but it's marked unsafe.
  • bjz_ 10y ago
    Rust still can benefit from Valgrind, especially if you are working on low-level libraries that require unsafe, or interface over the C ffi. The point that I think the parent is trying to make though is that Rust has made pragmatic decisions that allow it to piggyback off existing tools - it's not starting entirely from scratch.
  • dikaiosune 10y ago
    Rust doesn't tend to leak memory, but it doesn't make any firm guarantees about memory leaks as opposed to invalid accesses. For example, even in perfectly safe Rust code, you can make a cycle out of reference-counted smart pointers, and their destructors will never run. So valgrind may be useful for that, and it's common to interact with C libraries which may leak memory. But it's much less common to need than it is in the C/C++ worlds.
  • IceyEC 10y ago
    I think the parent is saying less that you don't need valgrind, more that you get it for free. I can take a program I'm writing in Rust and run it through valgrind, or other debugging / profiling tools written and designed for c / c++ because the rust binary ends up with the same debugging symbols that a gcc compiled binary could have
• pmelendez 10y ago
  >"But remember, C++ has a good 10 year head start on java, and java gained a lot of traction because of all the tools they didn't have to build" The thing is... I don't think Java took over C++ developers. Most likely they took over Pascal, Delphi, VB, Perl and other enterprise developers. Every decade there is a language that claims to kill C++ (Java in the 90's, Go in the 2000's) offering features that are not bothering C++ developers and end taking off by attracting developers from other communities (like Go with Python devs). I believe that memory safety or manual memory management is not the mainly concern for a C++ developer. On the other hand, if you give the same tools that C++ has and reduce complexity and then you might got into something, until then...
  • lmm 10y ago
    Depends what you mean by taking over. Certainly C++ developers are a much smaller proportion of developers now than they were in 1990, and much of the difference is made up by Java. Are those Java developers writing the same style of code with the same interfaces that those C++ developers were doing? No. Are business problems that used to be solved in C++ now solved in Java? Yes, often. I don't think we'll ever see a mass exodus of C++ developers to other languages - but in truth we never saw one from Pascal, Delphi, VB, Perl or Python either. What we will see is the niche where C++ is appropriate gradually shrinking, the borderlines between what's appropriate for C++ and what's appropriate for Java etc. changing, until one day we notice that there's hardly anyone writing C++ anymore. E.g. 20 years ago people would have said there was no way you could write a game except in C++ (or assembly). 10 years ago people would have said ok, you can write some games but not an FPS. Nowadays people say ok, maybe you can write a high-performance game without writing any C++ yourself but the engine you use will still be written in C++...
  • tamana 10y ago
    You are forgetting that Enterprise WAS C++ before Java. Amazon went from C++ (to Perl) to Java. Google went from C++ to C++/Java (and now Python and then Go) Microsoft went from C++ to C++/C# , C# is Microsoft flavor of Java.
    • ausjke 10y ago