If C++ compiles with bugs, you're using it wrong. Use constexpr, static_assert, concepts, templates, and other compile-time features to prevent bugs from entering production. Oh, and since they're done at compile-time, runtime execution of those code blocks is free.
I hope you're joking. That isn't even true for Haskell or Rust, much less C++. All languages allow bugs and C++ is not even formally type-safe or pointer-safe.
C++'s type system: C++ (among other unsafe languages) has a type system that does many local checks of a programs's source code. However, passing these checks does not establish anything definite about a program's behaviour: many C++ programs pass all of the compiler's type checking, and yet exhibit use-after-free errors, memory corruption, and arbitrary behaviour when run.
You can claim that these people are just using C++ wrong. I can say the same of those that ship buggy Python or Visual Basic programs. It's just a No True Scotsman argument.
C++ is far from perfect. All I'm saying is, Python could never be a replacement for compiled languages, simply because it is not compiled. You're correct, I could have made the same argument about Rust. But you're missing the point if you think my claim was meant to elevate C++. My point was that the compiler is your friend, and defensive programming in compiled languages is overlooked in conversations about language choice.
All I'm saying is, Python could never be a replacement for compiled languages, simply because it is not compiled.
I don't think anyone is actually claiming it should be a replacement for lower-level languages, so you're tilting at windmills.
I mean technically one can (and some do) compile Python, so no it isn't a technological impossibility. But I don't think it would be a good idea and I haven't heard anyone suggest it should be done.
To refer back to the earlier comment regarding bugs, I'd argue that yes, Python would be buggier in general than a C++ implementation due to being an interpreted language. And to gain the kind of testability and coverage that C++, Rust, Haskell, etc would have requires a lot more runtime tests, which is more code to write and maintain. You can't ship a build that doesn't compile; there might be some runtime mistakes that slip, but many are removed outright by the compiler. You can't achieve that with an interpreted language without a lot of test overhead and boilerplate... Which kind of defeats the purpose for me.
To your latest point though, maybe I was wrong about your intent... In which case I apologize. I'm not sure I understand what you were getting at if not to make an argument in favor of python.
That's wrong and silly. Do you think the Chrome browser has no bugs in it? Or that it does because Google doesn't know how to write C++?
C++ programs ship with bugs every single day, and if that's because people are "using it wrong" then that's just tautological. Bugs are mistakes so people only ship with bugs because they use their language wrong. Equally true for all languages.
C++ is not even a particularly safe language, so it's especially silly to say it of C++.
Of course I was speaking in hyperbole. I wasn't actually saying "c++ doesn't contain bugs". It would be absurd for me to claim that over all the years I've used C++, I've never seen a bug, and I would have thought that to be obvious. If that wasn't clear, I apologize.
Again, I'd argue that C++ is safer than Python. It is not EQUALLY true of all languages. Modern C++ is safer than people give it credit for. It allows you to do some evil things, but again, you have tools at your disposal to leverage the compiler and prevent most of these things from entering production. I think Rust is even safer than C++, so this is not me claiming C++ is some super safe language in the grand scheme of things.
The point I was making is that you should be leveraging the compiler to prevent bugs from ever existing, and for obvious reasons, python generally doesn't help you there. That's it.
If you want strong protections from the compiler for very robust code, you should use Haskell or Rust.
If you want fast development, flexible dynamic behaviours and you'd rather build a robust test suite using powerful mocking tools, you should use Python.
If you want the worst of both worlds then you could use C++ or (even worse!) C.
They're all the same thing, I'm a big advocate of using the one that's most comfortable for you. That is the language that produces the fewest bugs; I'm not trying to get involved in some weird holy war about which language is better. I was merely advocating for use of a tool (compiler) to assist in safety and efficiency, which python unfortunately doesn't really give you much opportunity to use. I like rust and Haskell, and I'd love to switch most of my codebases to Haskell, but unfortunately neither Haskell nor rust have great driver support. Most embedded toolchains only support C or C++.
Yes, C++ has a lot of good compile-time safety features nowadays, but your first sentence implies that 99% of all companies that use C++ are using it wrong.
Because good luck finding any enterprise C++ software that is bug free, especially ones that are multithreaded (you can't exactly use compile-time C++ features to ensure that your code has zero race conditions).
1
u/MasterFubar May 27 '22
So long pointers, so long code blocks, hello mysterious bugs!