As soon as I saw your question, I thought I'd bring up this Quora answer from Mario Queralt. He describes how just moving on from C++ is essentially impossible, and it is Rust that is the dead language.
I would say the question isn't really whether something will "kill" c++ in the near term. The question is whether there are alternatives that can become viable ways to do certain kinds of programming. If so, then some of these alternatives may at some point replace c++. In the meantime, it's sufficient if a community can grow around something like rust that keeps it going and evolving into the future.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
An interesting footnote to his mention of how C/C++ "killed" Fortran: the startup I work for still depends on software written in it (wgrib2, for the curious). We're hoping to replace that dependency in the new year, but "dead" is very much a relative term for programming languages.
Interesting take. I was going to say something quite similar: Rust will always lack the precedence of C++! Between C and C++, there are stable, reliable implementations of nearly every algorithm, data structure, and design pattern known to computer science. Countless libraries offer reliable means of working with hardware, graphics, sound, GUI, system...the list is practically endless.
Could Rust have that in 20 years? Sure, maybe. But until then, C++ is utterly irreplaceable. I have bigger problems to code for than to reinvent everything that exists.
It just depends on whether there are enough experienced people more interested in The Future™ instead of writing stable production code right now, and only time will tell us that.
"utterly irreplaceable" in some cases; in mine, I'm not interested in spend 10+ years to start confidently program concurrency and deal with memory drama. In many cases is irreplaceable but I'm not buying that those are all cases, ever, always, for any reason. The Mozilla team are not newbies nor Microsoft devs, and they are activelly working on Rust, I guess for them C++ is not utterly irreplaceable. That every line of C/C++ will be Rust or that C/C++ are soon to be dead is nonsense, not even COBOL is dead yet. But Python and even Ruby are alive in web dev when PHP exists. And many languages slowly started replacing Perl when everything was Perl; even Bash have lost some ground with Python. And we even have NO-SQL nowdays, who knew...
You misunderstand me. By "utterly irreplaceable", I'm referring to the entire programming landscape, not specifically to each conceivable case. C and C++ cannot be completely replaced across the entire industry.
My bad, I totally agree with that, as a side note: someone asked Linus Torvalds (the Linux kernel god) if he had plans to migrate the kernel to Rust, he answered something in the lines of "Rust seems interesting but nope, I like C", so there it is, not even C is soon to be dead.
Yes, but bindings are not the same as precedence. Your techniques may need to change with the language. It's like trying to use a StackOverflow question about the Qt5 library for C++ to answer a question about PySide2 for Python; same framework, different (official) bindings, differing techniques.
You are correct in observation. But does the change in technique make a language inferior than other? Rust comes with some totally new paradigms which may seem uncoventional but that's the same experience developers in 1980s and 90s must have gone through when they had first taste of C++, Java or Python. Over time these dialects established themselves as solid and reliable tools.
Rust has got same mettle, it just needs consolidated organisational backing and continued professional interest which has already begun. Microsoft, Facebook and others are already founding their research efforts on Rust or have production systems running on Rust's shoulders.
Unfortunately I think you're right to some extent, at least in the sense that this is what most people do think, and that it always takes time to make big shifts anyway.
There might be good algorithms for C & C++, but at the same time they are known to repeatedly fail in creating stable and safe programs .. it's not an insignificant amount of serious security flaws out there caused basically by the fact that the software was written in C/C++.
One of the biggest hurdles for languages tends to be the fact that the library ecosystem takes a long time to grow, but Rust seems to provide reasonably easy ways to use C APIs, and make libraries that can be called from C, so that's less of an issue for sure. Also Rust does bring something significantly better to the table for that safety.
Also many decisions about programming language choice are made either by executives who can just see Java and C/C++ are popular among enterprises, or by people starting their own hobby project and picking something they know.
My personal hunch is that it's just two things:
Rust's syntax is a bit hostile. It uses unfamiliar characters etc. to signify unfamiliar concepts, so someone new to Rust will not understand Rust code by looking at it, even after some basic tutorials. However the unfamiliar concepts are pretty much what makes Rust so strong so it should be worth learning.
People are flawed beings, they have biases. PHP took a long time to rise, and will unfortunately take a long time to die. PHP programmers have invested significant time and effort into learning this and they don't want to face the reality when you tell them that the design flaws in the language are not quite so common in many other options, instead falling back on propaganda style mantras about how PHP 7 is faster (was never really an issue with the language) and fixed most problems (no it really didn't)
I've been personally very excited to see several viable C/C++ killer options grow lately, and I'd like to see them learning from each other and finally take down one of the bigger class of problems the IT industry has - C/C++ programs & programmers 😄
Btw. Personally I see Zig being a more likely option as a winner in the end since it doesn't introduce radically new syntax and hurdles for developers, instead it's basically "a better C that even compiles C better". Incredibly interesting project and cool guy behind it.
Sure, OpenSSL for example has idiots writing code for them without review or any kind of controls in place. There's no issue with the fact that the code is obscure, the behavior unexpected, and that the language provides no easy tooling to ensure correctness, etc.
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.
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.
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?
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.
Sounds like you have a fundamental misunderstanding of the argument and a knee-jerk reaction to someone not liking the languages you like.
It's possible to write bad code and bugs in every language
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
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.
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/
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.
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.
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!
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.
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.
And those absolute decaration absolutely never are wrong, also those who calim that Rust is a C/C++ killer are the same that claim C/C++ are obsolete and dead languages i.e. frontend devs, webdevs, etc. I've never heard those claims from Rust dev teams or someone seriously working in Rust; in fact I've heard more about how to integrate C/C++ existing code, which by the way was the main goal from the start with Firefox, project that is now adding Rust to their existing codebase. I don't think anyone serious thinks that Rust is gonna replace them, who thinks the entire Linux kernel will be rewritten anytime soon is crazy, maybe never will, but new modules may be written in Rust in the future. Ruby and Python didn't born dead even when PHP and Perl had almost 100% of the web market; the fact that all the C/C++ codebase won't be replaced by Rust means nothing, is like saying that laptops born dead because we already had desktops or smartphones borne dead because of laptops, or electric cars are dead because of gas. To me the quora answers comes from a frustrated C/C++ programmer somehow envious of the Rust popularity and takes too serious and personal unfounded claims of the "dead of C"
As soon as I saw your question, I thought I'd bring up this Quora answer from Mario Queralt. He describes how just moving on from C++ is essentially impossible, and it is Rust that is the dead language.
quora.com/Why-is-the-Rust-programm...
I would say the question isn't really whether something will "kill" c++ in the near term. The question is whether there are alternatives that can become viable ways to do certain kinds of programming. If so, then some of these alternatives may at some point replace c++. In the meantime, it's sufficient if a community can grow around something like rust that keeps it going and evolving into the future.
An interesting footnote to his mention of how C/C++ "killed" Fortran: the startup I work for still depends on software written in it (wgrib2, for the curious). We're hoping to replace that dependency in the new year, but "dead" is very much a relative term for programming languages.
Interesting take. I was going to say something quite similar: Rust will always lack the precedence of C++! Between C and C++, there are stable, reliable implementations of nearly every algorithm, data structure, and design pattern known to computer science. Countless libraries offer reliable means of working with hardware, graphics, sound, GUI, system...the list is practically endless.
Could Rust have that in 20 years? Sure, maybe. But until then, C++ is utterly irreplaceable. I have bigger problems to code for than to reinvent everything that exists.
I suppose that's really my question.
It just depends on whether there are enough experienced people more interested in The Future™ instead of writing stable production code right now, and only time will tell us that.
"utterly irreplaceable" in some cases; in mine, I'm not interested in spend 10+ years to start confidently program concurrency and deal with memory drama. In many cases is irreplaceable but I'm not buying that those are all cases, ever, always, for any reason. The Mozilla team are not newbies nor Microsoft devs, and they are activelly working on Rust, I guess for them C++ is not utterly irreplaceable. That every line of C/C++ will be Rust or that C/C++ are soon to be dead is nonsense, not even COBOL is dead yet. But Python and even Ruby are alive in web dev when PHP exists. And many languages slowly started replacing Perl when everything was Perl; even Bash have lost some ground with Python. And we even have NO-SQL nowdays, who knew...
You misunderstand me. By "utterly irreplaceable", I'm referring to the entire programming landscape, not specifically to each conceivable case. C and C++ cannot be completely replaced across the entire industry.
My bad, I totally agree with that, as a side note: someone asked Linus Torvalds (the Linux kernel god) if he had plans to migrate the kernel to Rust, he answered something in the lines of "Rust seems interesting but nope, I like C", so there it is, not even C is soon to be dead.
In Rust, bindings for existing C and C++ libraries can be leveraged for that use case. People are doing such things in production.
Yes, but bindings are not the same as precedence. Your techniques may need to change with the language. It's like trying to use a StackOverflow question about the Qt5 library for C++ to answer a question about PySide2 for Python; same framework, different (official) bindings, differing techniques.
You are correct in observation. But does the change in technique make a language inferior than other? Rust comes with some totally new paradigms which may seem uncoventional but that's the same experience developers in 1980s and 90s must have gone through when they had first taste of C++, Java or Python. Over time these dialects established themselves as solid and reliable tools.
Rust has got same mettle, it just needs consolidated organisational backing and continued professional interest which has already begun. Microsoft, Facebook and others are already founding their research efforts on Rust or have production systems running on Rust's shoulders.
Unfortunately I think you're right to some extent, at least in the sense that this is what most people do think, and that it always takes time to make big shifts anyway.
There might be good algorithms for C & C++, but at the same time they are known to repeatedly fail in creating stable and safe programs .. it's not an insignificant amount of serious security flaws out there caused basically by the fact that the software was written in C/C++.
One of the biggest hurdles for languages tends to be the fact that the library ecosystem takes a long time to grow, but Rust seems to provide reasonably easy ways to use C APIs, and make libraries that can be called from C, so that's less of an issue for sure. Also Rust does bring something significantly better to the table for that safety.
Also many decisions about programming language choice are made either by executives who can just see Java and C/C++ are popular among enterprises, or by people starting their own hobby project and picking something they know.
My personal hunch is that it's just two things:
I've been personally very excited to see several viable C/C++ killer options grow lately, and I'd like to see them learning from each other and finally take down one of the bigger class of problems the IT industry has - C/C++ programs & programmers 😄
Btw. Personally I see Zig being a more likely option as a winner in the end since it doesn't introduce radically new syntax and hurdles for developers, instead it's basically "a better C that even compiles C better". Incredibly interesting project and cool guy behind it.
The Zig page is a phenomenal read. Might be time to install the compiler.
The security flaws you refer to are not a failure of C or C++. They are a failure of idiots using well made tools.
So what's the remedy for idiots?
Code reviews.
Sure, OpenSSL for example has idiots writing code for them without review or any kind of controls in place. There's no issue with the fact that the code is obscure, the behavior unexpected, and that the language provides no easy tooling to ensure correctness, etc.
Nothing wrong with C/C++ 😄
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.
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.
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.
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.
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.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?
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
cppcheckinto your automatic workflow and/or IDE to handle all the stuff the compiler doesn't complain about.TIL, thanks! I don't know that I've ever compiled C++ without that set of flags, I'm a little scared to.
Just in case I wasn't clear,
cppcheckis an external static analyser, but it's quite a good one!Yeah, I never work without
-Wall -Wextra -Werror. I ususally throw-Wpedanticin there too, for good measure.Also, Qt Creator IDE has an amazing static analyzer working out-of-the box.
Sounds like you have a fundamental misunderstanding of the argument and a knee-jerk reaction to someone not liking the languages you like.
It's possible to write bad code and bugs in every language
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
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
#includeand other such massively outdated bad concepts from C/C++ to worry about.Elm's
Maybeandcaseare 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 toMaybewith 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:
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.
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
poetryorpipenvto manage my dependencies, I needblackto format my code properly, I needbanditto tell me about common security issues, I needpytestto 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/
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.
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.
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!
I'll just leave this here.
yourlogicalfallacyis.com/ad-hominem
Do you mean like this?
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):
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:
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.
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.
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.
You are very right.
And those absolute decaration absolutely never are wrong, also those who calim that Rust is a C/C++ killer are the same that claim C/C++ are obsolete and dead languages i.e. frontend devs, webdevs, etc. I've never heard those claims from Rust dev teams or someone seriously working in Rust; in fact I've heard more about how to integrate C/C++ existing code, which by the way was the main goal from the start with Firefox, project that is now adding Rust to their existing codebase. I don't think anyone serious thinks that Rust is gonna replace them, who thinks the entire Linux kernel will be rewritten anytime soon is crazy, maybe never will, but new modules may be written in Rust in the future. Ruby and Python didn't born dead even when PHP and Perl had almost 100% of the web market; the fact that all the C/C++ codebase won't be replaced by Rust means nothing, is like saying that laptops born dead because we already had desktops or smartphones borne dead because of laptops, or electric cars are dead because of gas. To me the quora answers comes from a frustrated C/C++ programmer somehow envious of the Rust popularity and takes too serious and personal unfounded claims of the "dead of C"
That is an opinion not a fact. You may like to consider this unbiased view from the architect of D programming language. qr.ae/pN212s
This was expressed in 2015, things have changed since then and Rust is much more powerful and capable now.