loading...

Discussion on: What Does C++ Do That Rust Doesn't?

lietux profile image
Janne "Lietu" Enberg

Even if the language was easy to understand, without any gotchas anywhere, without any obscure syntax, undefined behavior, and so on, relying on code reviews is a bad idea.

Code review is performed by .. people. People are flawed. People wrote the original broken code, and people will review it and nod thinking it looks good.

When a language is well designed it can help people notice things that they should pay more careful attention to, or specifically signal "this bit is going to break the safety rules a bit" so you can focus triple effort on reviewing those 2 lines or something.

With C/C++ you're always guessing where the next gotcha comes from.

Thread Thread
codemouse92 profile image
Jason C. McDonald

A lot of people complain about C and C++ being inherently "unsafe", but they forget all too often that their own favorite languages have gotchas too...they're just harder to spot, and far more unexpected to encounter. C and C++ don't pretend to be error-free. Given a proper understanding of the language, one can write production-quality code that has the stability of those "safer" languages, especially if one uses the newer memory safety features of C++14, C++17, and C++20.

...relying on code reviews is a bad idea.

Remember Linus's Law: "Given enough eyeballs, all bugs are shallow."

Writing code is an inherently human process. If you're looking for something fool-proof, it doesn't exist, since every language, tool, and algorithm was created by a human.

There are bad ways to do code reviews, but it's a poor workman who blames his tools. The greater danger is in not having code reviews at all.

When a language is well designed it can help people notice things that they should pay more careful attention to, or specifically signal "this bit is going to break the safety rules a bit" so you can focus triple effort on reviewing those 2 lines or something.

To some degree, you are right. There are "sharp edges" in C and C++ that are mitigated in some languages.

Of course, any serious C or C++ development team is going to have a slew of static and dynamic analyzers at their disposal that do exactly that.

With C/C++ you're always guessing where the next gotcha comes from.

Again, that "safety" that other languages promise is an illusion. C++ doesn't pretend not to have gotchas. In contrast, Python and Java developers (for example) love to proclaim that their language doesn't have any "undefined behavior", yet that is altogether untrue. UB may show up less often in those languages, and is usually billed under another name, but it is there.

Every language has undefined and unexpected behavior because machine code has undefined and unexpected behavior. And the less "UB" a language has, the nastier the remaining instances tend to be.

So if you like Rust, or whatever "safe" language you prefer, by all means, use it. But don't buy into the fallacy that it's somehow impossible to write deeply flaws code in $LANGUAGE.

Thread Thread
deciduously profile image
Ben Lovy Author

But don't buy into the fallacy that it's somehow impossible to write deeply flaws code in $LANGUAGE

I'm not sure that was the assertion - heck I'm writing Rust, you'd better believe there will be some deeply flawed code out there. The benefit of Rust specifically here is that it tags code sections known to be problematic, so you can punt some of that static analysis work currently necessary in a C++ codebase to the basic compiler, and then know where to focus your human-review efforts. To me this allows you to re-focus people time on jobs for people, and better leverage computer time for jobs computers couldn't previously do. While this won't prevent bad code, to me it does seem like it would isolate it somewhat. Wouldn't this property lead to a generally more focused development workflow over time?

Thread Thread
codemouse92 profile image
Jason C. McDonald

Yeah, probably. That said, LLVM Clang has many of that same sort of static analysis baked into the compiler, if you just turn the flags on for it. (-Wall -Wextra -Werror).

It's also pretty trivial to hook cppcheck into your automatic workflow and/or IDE to handle all the stuff the compiler doesn't complain about.

Thread Thread
deciduously profile image
Ben Lovy Author

cppcheck

TIL, thanks! I don't know that I've ever compiled C++ without that set of flags, I'm a little scared to.

Thread Thread
codemouse92 profile image
Jason C. McDonald

Just in case I wasn't clear, cppcheck is an external static analyser, but it's quite a good one!

Yeah, I never work without -Wall -Wextra -Werror. I ususally throw -Wpedantic in there too, for good measure.

Thread Thread
juzzlin profile image
Jussi Lind

Also, Qt Creator IDE has an amazing static analyzer working out-of-the box.

lietux profile image
Janne "Lietu" Enberg

Sounds like you have a fundamental misunderstanding of the argument and a knee-jerk reaction to someone not liking the languages you like.

  1. It's possible to write bad code and bugs in every language

  2. Not RELYING on code reviews to spot all your bugs is not the same as not having code review - there's a certain class of problems for which code reviews are the best tool available, spotting obscure bugs in your code is not really one of those

  3. The issue here is that while you might find other additional tools that do some additional static checks, and there's warnings you can enable - since they are obviously possible they should be a part of the language, enabled by default, and not easy to bypass to create obviously broken code .. they shouldn't be optional warnings, they should be compiler errors that may occasionally be explicitly and individually suppressed.

Other languages have their own issues, but quite a few have evolved to say "hey, maybe we should try to stop the programmer from doing anything stupid at least without clearly acknowledging that they know it's probably stupid".

There is no such thing as a perfect language out there, I like writing Go a fair bit, but I still need external tools to check that I'm not ignoring errors and other things regularly. I think most of them should just be a part of the compiler. But hey, at least there's no #include and other such massively outdated bad concepts from C/C++ to worry about.

Elm's Maybe and case are amazingly helpful tools to avoid bugs where you, a human being, just forgot something, and a typical static analyzer sees nothing obviously wrong with the code. Elm forces you to at least clearly acknowledge that in this bit, you're ignoring some potential states. Zig has a similar concept to Maybe with their optional types.

Overall we should be using languages that are better designed, that come with "batteries included" in terms of the tools that try to ensure that you're writing good quality code, that try to help you avoid significant mistakes, that help your code review to focus on those bits where it's likely that you'll have critical errors in, and so on.

Another small point on this:

Of course, any serious C or C++ development team ...

Maybe that team just got started and they don't know of these tools, and maybe their project gets published and included in another project that just sees lots of GitHub stars and doesn't have the time to verify every line of code themselves. Maybe they just have one new team member, and their CI system had a bad day and just let all the bad code pass without any complaint.

Yes, it's possible to write good code in C/C++, it's possible to write decent (I wouldn't go as far as saying good) software in PHP. Just because it's possible with enough effort or luck, doesn't make the languages any good, or in any way invalidate the complaints about the languages.

Thread Thread
lietux profile image
Janne "Lietu" Enberg

On a small tangent - Python is one of my most favorite things to write in nowadays. It's the best performance enhancing drug a programmer can have in my view, as most things you need to accomplish are significantly easier to accomplish in it.

Unfortunately while Python has a lot of great things going for it, there's still a lot where it's failing. One such things is that I need to depend on a large number of external tools to make it possible for me to write good code.

I need poetry or pipenv to manage my dependencies, I need black to format my code properly, I need bandit to tell me about common security issues, I need pytest to help me write decent unit tests, and so on.

It'd be nice to see these also become a part of the official Python, but in case of Python, I'm quite hopeful vs. C/C++, as there's a long and clear history of pretty significant improvements having been made in the language without excessive fear about breaking things: python.org/dev/peps/

Thread Thread
codemouse92 profile image
Jason C. McDonald

Just because it's possible with enough effort or luck, doesn't make the languages any good, or in any way invalidate the complaints about the languages.

And see, that shows the attitude I have a concern with. Just because you dislike C and C++ doesn't mean it "isn't any good." It just means, at best, that it isn't right for your projects. Every language is right for some type of use case. As someone who does a significant amount of work in C and C++, specializing in memory management and debugging undefined behavior, I probably know more about the inherent flaws and drawbacks of the languages than three quarters of the people on DEV.

But, truth is, only one of us is throwing about arguments devaluing the inherent usefulness of major programming languages, and as you'll note, that person is not me. Hand-waving dismissal of the validity or merit of tools that hundreds or thousands of other developers successfully use shows an overvaluing of one's own biases and opinions. It's often a sign of immaturity.

Case-in-point, just because I personally detest Javascript does not mean that Javascript has no value. I'm not going to write a long rant on why someone shouldn't use it, just because I personally dislike it! In fact, if someone were to launch a railing attack on the viability of Javascript, I'll be one of the first in line to remind everyone: every language has its use case, and none are without significant flaws.

So really, the one with the knee-jerk reaction here is you.

Thread Thread
lietux profile image
Janne "Lietu" Enberg

JavaScript is a terrible language and it should be replaced. So is PHP, so is C, and so is C++. They only have a "use" because decisions have been made that force those languages on us: JavaScript because it's the only one supported by browsers (this is changing with WASM at least and some languages compiling into JavaScript give some hope), PHP because people who started programming with it started some projects with it and executives keep hearing PHP programmers are cheap to hire, C/C++ because of history and lack of competition in the relevant area - this has also changed now and they will hopefully start fading away.

Yes, C/C++ has a use TODAY, because they're the only languages it's possible to do certain things in yet, for example Zig and Rust don't have a mature toolchain to build code for Arduinos. I'm just going to be glad when the day comes and there is no longer a single case where you need C/C++ other than the maintenance of old software, like COBOL today. I also know JavaScript pretty well because I need it, that doesn't mean I need to like it.

You're the one turning an argument about languages to a personal attack, and thus you lose. πŸ˜„

This really isn't moving anywhere, goodbye, merry christmas, and all that.

Thread Thread
deciduously profile image
Ben Lovy Author

I think you've both made good points, and both made personal attacks and talked passed each other somewhat. I agree, this thread is pretty thoroughly explored, thanks for the discussion!

Thread Thread
codemouse92 profile image
Jason C. McDonald

I'll just leave this here.

Hating On Languages You Don't Use

Thread Thread
lietux profile image
Thread Thread
codemouse92 profile image
Jason C. McDonald

Do you mean like this?

Sounds like you have a fundamental misunderstanding of the argument and a knee-jerk reaction to someone not liking the languages you like.

I apologize that I don't share your viewpoint, but this really needs to stop here. This could have stayed as a constructive discussion, and I tried to keep it that way. I expressed concern over your shift in tone, wherein you stepped over the line of the Code of Conduct (see above quote):

  • Being respectful of differing viewpoints and experiences
  • Trolling, insulting/derogatory comments, and personal or political attacks
  • Other conduct which could reasonably be considered inappropriate in a professional setting

As I said repeatedly, there is a tremendous difference between disliking a language and devaluing it altogether: declaring a language as being absolutely 'no good' (which you did multiple times) is a slap in the face of everyone who uses it. You know first hand what this is like, when you became angry at someone a few months back because they said Python was "poorly designed". It's not a "knee-jerk reaction," as you accused me of β€” rather, it is offense at having your professional knowledge and skill denigrated to irrelevance. Such denigration is rude, inappropriate, and below the bar of conduct for DEV.

In case you're concerned about my own statement earlier:

Hand-waving dismissal of the validity or merit of tools that hundreds or thousands of other developers successfully use shows an overvaluing of one's own biases and opinions. It's often a sign of immaturity.

Whether it's a sign of your immaturity is something you will have to decide for yourself; that's why I stated it as a correlation, but not a declaration about you. I want you to be aware of how you come across to others when you post railing declarations such as you did. Your knowledge, like mine, is a mere drop in the ocean, far too insufficient to declare something like C or Rust or Python or PHP as "no good". For one to believe they can, therefore, does require one to overvalue their own bias. Take it as a constructive criticism and move on.

We don't have to agree on whether C or C++ are great languages. You don't have to like them. You can even describe what you dislike about them, and where you believe other languages shine. But you do need to have enough respect for others not to denigrate the tools they successfully use as absolutely "no good" because of your own bias. Your words do matter.

Please let this be the last post in this thread, learn from it, and let's move on.

Thread Thread
lietux profile image
Janne "Lietu" Enberg

You really have a funny way of thinking. I say that you seem to have misunderstood my argument, you take it as a personal attack and call me immature. You assert your superior knowledge, and declare your opinion thus supreme and everyone else's point of view invalid, post memes to make fun of me, and then continue to complain about how I'm not respectful of your viewpoints πŸ˜„

It's a pretty poor attempt to compare my comments here to someone saying Python’s actual coding structure relies on white spaces in itself is "poor design". Also not really sure how any other discussion anywhere else proves your point regarding this one.

There's a difference between actively offending people, and saying things people find offensive. You might not like that I don't like C/C++, and I really don't care if you do or not, I also don't really care about "how I come off to others". That doesn't mean I'm "slapping" anyone, I'm just explaining my point of view.

If you don't like me calling something "no good", well that's a you -problem. Deal with it how you wish. I will continue to call things I dislike "no good" when I feel it's appropriate.

Thread Thread
deciduously profile image
Ben Lovy Author

No minds are being changed, nobody will get a satisfying "last word", this is not productive and has little to do with the original post.

Thread Thread
lietux profile image
Janne "Lietu" Enberg

You are very right.