6 ms·

"As clean and direct as any other modern language ..." LOL Honestly I needed to read the C++98 code to understand the modern one. Yes, C++ has advanced but th

• adamnemecek 11y ago
  > Honestly I needed to read the C++98 code to understand the modern one. Was that your first time reading C++14? If so are you surprised that there was some learning curve? > Do other modern languages still operate with pointers? As much as I'm rooting for Rust to succeed, C++ will be around for quite a while longer so it might be a good idea to make it a bit friendlier.
  • progman 11y ago
    The problem with modern C++ is that people stick to their programming styles. Many will use some of the new good features but they will also use the old ones (pointers!) because it's so easy to use them. Rust however forces people to accept new programming styles because the legacy ones (pointers!) are not appreciated.
    • pmlnr 11y ago
      Pointers are great for resource saving, eg. embedded. Don't underestimate them.
      • progman 11y ago
        In embedded systems pointers make some sense but not in usual applications. This is the way how Rust can work: http://mainisusuallyafunction.blogspot.de/2015/01/151-byte-static-linux-binary-in-rust.html http://mainisusuallyafunction.blogspot.de/2015/01/151-byte-s...
• okamiueru 11y ago
  What do you mean by having to "read the C++98 code to understand the modern one"? Isn't this how "here is the new way of doing it"-examples work? Until you don't know it, of course you will need to read whatever version you do know. The point is that once you do learn it, you can use it. And "inherited waste is obvious"? If you mean to say that it carries a lot of historic luggage, and you feel encumbered by it, then geez, the document in question was almost tailored for you. C, D, Go also have pointers available. And, to be honest, thinking that pointers are "obsolete" suggests lack of understanding. You know what, all your points seem to be against C++. A typical language evangelist.
  • progman 11y ago
    > And, to be honest, thinking that pointers are "obsolete" suggests lack of understanding. Who has lack of understanding? Rust proves that pointers are not actually necessary anymore. > You know what, all your points seem to be against C++. A typical language evangelist. What is wrong about C++ criticism? I was a professional C++ developer for a long time but now I am really glad that I don't need to maintain any C++ anymore. At the beginning C++ was real joy of programming but now it has grown to something which I don't like anymore. There are other really modern languages much more clean and almost as performant as C++. Rust and Nim for instance. In Nim I am much more productive than in C++.
    • kevinnk 11y ago
      Rust has pointers all over the place - one of the core features is memory safety with pointers.
    • arcticbull 11y ago
      Pointers aren't the problem, null pointers are. Nullity (or the guaranteed lack thereof) should be baked into your type and you should be forced to handle as necessary when accessing a resource. That said, C++ is moving in that direction, too. For me the difficulty is that to maintain backwards compatibility the compiler can't force you to go with the language, and you can defeat the protections simply by not using them or by casting them away. It's the accrued years of cruft and never telling people to stop doing things they way they have been that encumber C++. IMO I'd favor a clean break. C++next should just drop support for all the old, un-safe ways of doing things and provide clean break. If you want to keep doing things the old way, stick to C++17. Moving forward there should only be one way to do things -- the safe way.
• arcticbull 11y ago
  I think what makes C++ so challenging for me isn't C++98, C++11, C++14 or whatever comes next. The challenge for me is that I need to know the superset of all the features (and past 'features') at the same time, doubly so to interoperate with existing code or libraries. The more gets layered on without taking anything away the more difficult it is to reason about your code let alone that of anyone else. And without taking anything away, all the cool new features can't defend you at all, they're just more rope. The challenge for me is just how much context C++ forces me to hold in my head at any given time. And thanks to operator overloading, I can't trust anything I see -- when you can change the meaning of the comma operator, any piece of code can do literally anything other than what it looks like. Ultimately, I stopped developing in C++ because there's just too much cognitive load for me. In a professional setting you're not coding for yourself, you're coding for you 6 months from now, and that guy has know idea what kind of tricks you were playing back in the day.
  • pjmlp 11y ago
    > And thanks to operator overloading, I can't trust anything I see -- when you can change the meaning of the comma operator, any piece of code can do literally anything other than what it looks like. I always laugh at this complaint specifically against C++. Except for Go and Java, all other mainstream languages allow for either operator overloading, or symbolic names for functions/Methods. Even JavaScript ES7 might get them, http://51elliot.blogspot.de/2015/01/fluent-talk-summary-brendan-eich.html http://51elliot.blogspot.de/2015/01/fluent-talk-summary-bren...
    • Gankro 11y ago
      There's a difference between overloading `+`, `-`, `<<`, (which must obviously run custom code when applied to custom types), and overloading `,`, copying, assignment, moving, and tons of other "already works on everything" operations. Both can cause problems when used inappropriately, but the latter is just chaos.
      • jawilson2 11y ago
        How would you handle deep vs. shallow copying and assignment for classes without overriding those operators?
• rcurry 11y ago
  C++ is the monkey's paw of programming languages. Sure, it'll grant your wishes, but you'll end up paying some terrible price for it in the end.
  • nosnos 11y ago
    How is this different with every other language? At least C++ is being maintained gracefully so one could update it with newer ways of doing the same thing and still work versus a language that is dead and you're stuck leaving it or reimplementing the program completely in something else. Or you're using a language that is new and version 0.6 completely breaks 0.5 so you can't ever upgrade without rewriting parts of it and yeah, you should upgrade because 0.5 has some horrible security vulnerability.
• lhecker 11y ago
  In your blind love for Rust you seem to forget that it in fact operates with pointers - everywhere. The thing is that Rust either tracks the lifetime of a naked pointer (similiar to std::unique_ptr), or you wrap pointers in objects which facilitate reference counting to track the lifetime (similiar to std::shared_ptr). In the end both kinds operate on generic, unsafe raw pointers - safe only thanks to ownership tracking and "boxing". The only difference here is that Rust thankfully made it opt-out while C++ unfortunately needs to use opt-in. But yeah... I'm eager to hear your explaination how Rust doesn't use those stupid pointers. Maybe you can create a new computer architecture too? I mean since x86 uses pointers and stuff. Maybe we should use garbage collected languages for that, huh?
  • progman 11y ago
    > In your blind love for Rust you seem to forget that it in fact operates with pointers - everywhere. I don't use Rust at all :-) I favor Nim, Haskell and Lisp. I am just pointing to Rust as a better alternative to cc14. > I'm eager to hear your explaination how Rust doesn't use those stupid pointers. Only in embedded systems where direct hardware access, memory and performance are issues pointers makes sense. In all other cases pointers are bad programming style. http://words.steveklabnik.com/pointers-in-rust-a-guide http://words.steveklabnik.com/pointers-in-rust-a-guide
    • AlexeyBrin 11y ago
      I don't use Rust at all :-) I favor Nim, Haskell and Lisp. I am just pointing to Rust as a better alternative to cc14. This is some quality trolling. How can you recommend something that you don't use ?
      • progman 11y ago
        I used Rust for a while. _Now_ I don't use it because I discovered other languages that work better for my current applications.
  • jerf 11y ago
    In the end everything is "unsafe" assembler. "It's all unsafe if we penetrate the abstractions!" is basically "Everybody's naked under their clothes!" Yes, true, but profoundly irrelevant. Safety is added by the higher layers. If Rust has pointers that are ownership tracked, then it is incorrect to think of them as raw pointers; they are safer than that. Safety is attained by creating compilers/runtimes/interpreters that can not be convinced to execute certain patterns of assembler code, or perhaps require rather explicit labeling.
• flohofwoe 11y ago
  You can just as well write large pieces of C++ without using pointers or heap allocations at all. In fact this is considered 'good style'. As soon as you have stuff living on the heap, Rust also needs (smart) pointers to track these heap objects, and the compiler is clever enough to guarantee compile-time safety (although I guess this is the main reason why compilation in Rust is so slow), while in C++ these checks are done at run-time (of course compile time checks would be better).
  • kibwen 11y ago
    Tracking ownership doesn't make the Rust compiler slow. Compiling Rust is already faster in general than compiling C++ (where the lack of a module system and code explosion from templates is absolutely killer), with the caveat that the Rust compiler hasn't yet implemented incremental recompilation and so subsequent compilations can be slower than subsequent compilations in C++ if your C++ build system is reusing artifacts intelligently. Incremental compilation in Rust is slated for after the middle-end overhaul which is currently ongoing.
    • flohofwoe 11y ago
      Hmm ok, this has probably increased a lot since I last dabbled with Rust. This was about a year ago, and the speed reminded me of a C++ static analyzer, which kinda made sense to me :) Even in C++ land there are massive differences in compiler speed Clang on Linux/OSX is easily 10x faster than the Visual Studio compiler without advanced tweaks (however, for some reason, clang on Windows is also very slow).
      • kibwen 11y ago
        Yes, when I talk about C++ compiler speed I generally mean Clang, since it's a widely-available high-quality implementation with compiler speed as an explicit priority. In the context of Rust it's doubly relevant since they both use LLVM. Compiler speed wasn't an explicit priority for the Rust developers in the run-up to 1.0, but these days it's essentially top priority (hence the aforementioned middle end overhaul, though it has more benefits than just incremental recompilation), and the speed of the compiler has already more than doubled since 1.0.
• steveklabnik 11y ago
  Hi. Please note that that blog post has a very prominent "Rust versions 0.8 - 0.9" on the top. Almost nothing in that post is accurate at this point, even the stuff that is has different terms now. Also, if you don't use Rust, and do use nim, please use nim in these examples in the future rather than Rust, please. Otherwise, you make inaccurate comparisons, like you do here.