Beginners will feel overconfident and some will even try to teach more experienced coders how to do things "right" regardless of these types of articles. We've all been there and we probably still are in some fashion. I don't see how that diminishes the value of TFA though.

Any kind of guidelines can be "abused" by taking it to the extreme without actually taking the time to consider if it actually makes sense.

Also while I do have significantly more than 10 years of experience in C I think it's silly to say that you can't criticize the language if you can't recite the K&R by heart. You don't need to know all the intricacies of C's aliasing rules to peruse the long list of CVEs caused by faulty memory handling.

The world of computing changed drastically over the past decades, for a given application maybe C or C++ was a great choice in the 90's, doesn't mean there's no better alternative now.

People telling everybody to ditch C like it never existed and rewrite everything in Rust or Go are silly and are probably the junior coders you're talking about who lack real world experience. Doesn't mean that the opposite reaction of "if it ain't completely broke don't fix it" is any more clever.

Well, I agree with you on practically everything you said.

Just for the record, I never intended to imply that somebody should not criticize their tools until they fully mastered them and I certainly don't claim to have done so. I just (tried to) say that I don't like it when others recite opinions from some blog post without even a basic understanding of the issues at hand as I find it leads to a very superficial discourse. I also didn't mean to imply that new projects should be done in C/C++ for the sake of historical reasons or something similar.

In fact, I actually recently started working on a new project, written in rust (!) in an industrial setting. Part of the reason for my original comment is that I found there was _a lot_ of cult in content related to rust, in their marketing material and on rust-related posts on HN. While I really like some parts of the language, this aspect of the rust community is really turning me off at the moment and I hope it will get better over time.

Let's say you're a fresh grad and looking at options for you future dev career:

Option 1. Spend the next 5 years learning the ins and outs of C++, where it can bite you, where it can go wrong, all the intricate edge cases, etc... and you'll come out a better C++ programmer. Hopefully after 5 years of hard concentration, you may be able to write safe code (I still haven't met a C++ programmer that hasn't been burned by segfaults in production).

Option 2. Spend a single month learning Rust. Play with it for another month or even two just to be sure. Hopefully after the 3rd month, they'll be 100% certain that their code won't break because of errors that are above their pay grade.

I've done programming for over 12 years. x86 assembly and C for the earlier years. Then I realised that higher level languages gave me the power to code confidently without causing the errors that I was constantly seeing without explanation.

After many years of HLL I wanted to go back down to the metal... after everything that I knew, "C or C++, not even once".

Rust gives me the confidence to "compile once, run safe everywhere".

>> Spend the next 5 years learning the ins and outs of C++, [..,] Spend a single month learning Rust. Play with it for another month or even two just to be sure. Hopefully after the 3rd month, they'll be 100% certain that their code won't break [...] Rust gives me the confidence to "compile once, run safe everywhere".

See, this is exactly the fallacy that I am criticizing. I think the belief that "C++ is too hard to learn but one could become a good systems programmer in rust in a few months" is - frankly - misguided. I think that in order to become a good systems programmer in rust, you _will_ have to know all of your systems basics (i.e. you should already be able to code in C for starters) and then some more. But sadly this seems to be the spin that their marketing is pushing also.

Personally, I found practical rust (that interfaces with actual system libraries - think openssl) to be more or less on par with good C++11 with RAII memory and ressource management in terms of practical memory safety. Having somebody writing rust code without a basic understanding of things like ressource management and threading is just as bad as having them writing "unsafe" C(++) code.

I hope I'm not feeding the trolls here.

Another scenario:

Option 1. Spends 5 years learning the ins and outs of systems programming, whilst using C++. Still writes unsafe code.

Option 2. Spends 5 years learning the ins and outs of systems programming, whilst using Rust. Zero unsafe code has ever been written.

If you are writing systems code, you will be writing unsafe code; it's just how it works when you are working with the underlying kernel and hardware.

The best you can do is attempt to contain it within "unsafe" blocks, but as has been proven by others in the rust community already this will not save the rest of your "safe" code from crashing if you write a bug.

There have been memory safe languages for longer than c has existed; rust is just the latest.

Again, the assertion that all code written in rust is automatically "safe" (let alone correct) is false unless you say what precisely you mean with "safe" in very specific terms. While there are some ways in which rust is "safe" while c-family languages are not, these cases are _subtle_ and you _will_ have to understand modern C++ first to see what they are.

But yes, rust could turn out to become a new widely accepted standard for systems programming some day and depending on whether you believe that or not, it might make sense to "invest" your time into it.

These cases are not subtle at all. You can understand a good number of them with barely the knowledge from an Intro to Java class- iterator invalidation, data races, etc.

There is no need to understand the particulars of C or C++ to do or appreciate safe systems programming.

I'm talking safe as in Rust's memory safety guarantees.

As far as I understand, there is no accepted formal specification or even single source of truth for what the rust community thinks are the "rust memory safety guarantees". Only a large number of people that have completely convinced each other that "it's better than C++" with little proof and without even clearly defining their own semantics. Please correct me if I'm wrong here (a blog post does not qualify as a specification).

Relevant: https://github.com/rust-lang/rfcs/issues/1447

It's a little more subtle than that: It's "safe code must be memory safe" and "unsafe code infects the whole module". The stuff you're talking about is "what exact invariants are unsafe code supposed to uphold". Because unsafe Rust is a superset of safe Rust, that being an open question does not mean that what's meant by "Safe Rust" inside of safe Rust is up for questioning.

Work on exactly what unsafe code is expected to do is ongoing.

It's nowhere near that uncertain. "Memory safety" is hardly a subtle property and it's been well-understood since we figured out how to enforce it in garbage collected languages.

The only uncertain part is which rules unsafe code has to follow to maintain it- it currently comes down to "whatever LLVM optimizations won't break," which is in practice what C and C++ programmers deal with already. Things like your link are work to improve the situation beyond C and C++.

Comments like these aren't OK on Hacker News, no matter what you're replying to.

https://news.ycombinator.com/newsguidelines.html

That assumes there will be no errors in the Rust compiler or runtime environment to deal with. If there are then those would definitely be above their pay grade.

I'd take a bug within LLVM over my own any day

Rust has basically the same amount of runtime as C; I'd say "standard libraries" here instead, personally.

As already posted in another thread for this GP, I completely disagree with the overall sentiment of this whole discussion that is throwing (modern) C++ (i.e., C++11 ff.) into the same bucket with (any version of) C.

What I can agree to, however, is that C should be your first choice if (a) you have to, or (b) because you like it and probably (c) because you are several times more likely to find a job if you know C as opposed to Rust or Go (unless living in very specific areas of this world - maybe...?). And then go learn Rust/Go/..., anyways :-).

Fact 1, the article doesn't mention Rust a single time.

Fact 2, mostly safe systems programming languages exist since ESPOL (1961), 10 years older than C, and with a great linage of attempts of safe systems programming outside AT&T walls, so plenty of alternatives are available

So as someone with more than 10 years of C and C++ experience, among other programming languages, before focusing on Java and .NET, I find these kind of articles valuable because they are the proof there isn't such thing as the 10x C developer that never does mistakes.

I feel you're missing my point. The article doesn't mention rust but my comment was phrased in the context of the current rust craze on HN.

As I said, I agree with you and the author that all of us do inevitably make mistakes. I also agree that the c-family of languages makes it somewhat more easy to shoot yourself in the foot in a bad way than others. I'm not saying innovation on safe languages is bad, or that using safe languages is bad.

My disagreement with you and the sibling is probably on the point of whether one can learn something useful about the limitations and pitfalls of c-family languages by reading a single-page all-opinion post about it. You and the sibling appear to believe so, I do not. I don't think we will come to a complete agreement on this, but I certainly understand and respect your and sibling's view.

The main issue I have found out during all these years of advocating safe practices in C and C++, specially among C developers given that the C++ community does care about type safe programming, is that they land in deaf hears.

Currently, writing blog articles re-explained what is bad and should be avoid seem a waste of effort, given that even respectable researchers like DJB get ignored.

There's a broader question of when to investigate a technology yourself versus learning from others. A new programmer could spend ten years programming in [some language] or they could learn from other people to avoid it, and possibly save themselves a lot of time. Yes, that means you're just following the bandwagon, but sometimes that's efficient.

I would share the link, though, rather than making my own assertions, and be open to other arguments from more experienced people.

There is a big difference between modern C++ (C++11 ff.) and even the most current iteration of C. The two languages might have been quite similar back in the day when "C with classes" was created, but they have diverged significantly since then. Therefore, I think it is wrong to consider C a "proper subset" of C++, as often is claimed, or even to treat them as equals.

In other words, the real fallacy of the original post is throwing C and C++ into one pot, as if it were all the same - something I consider could not be further from the truth, even back in the C++98 days. A part of that problem is that persons having a (possibly incomplete) understanding of only one of the two languages (on top) believe they can apply that understanding to the other language, too, without having to learn the correct idiomatic usage of the other [1]. And that situation is made even worse by posts that claim to only have to point out some "gotchas" you need to be aware of to understand the other language, particularly coding in C after picking up some C++. Just to name the most critical changes in C++ over C: RAII, abstractions (objects/polymorphism/templates/generics), I/O, error handling, and namespaces/encapsulation. However, not even keywords work the same (fe., `const` and `typedef`). Finally, when C code breaks, it typically is closely related to one of those features that would have tooling in C++ to avoid the issue (in particular, containers to avoid resource leakages in connection with more advanced error and I/O handling techniques).

In other words, I pretty much agree with the GP about the hyperbole of the linked blog entry, and would only let the original post "stand" if it had some kind of significant `C != C++` distinction. I can agree with anyone who thinks that coding in C is probably a Bad Idea today unless you must due to maintaining legacy code-bases, while I think that C++11 has greatly changed the issues you have to look after when coding in C++, making it a lot more safer - and IMO quite fun - to use.

[1] https://olvemaudal.com/2011/10/10/deep-c/ (note that all C++ issues in the post can be avoided by using proper modern C++, like "naked" `new` usages and such)

[minors edits after the post for spelling corrections and readability - but no semantic changes]

I kind of agree with you, back in the day during the C vs C++ flamewars, I was always in the C++ side, and still am if you follow my comment history.

However a big part of the problem, which you kind of refer to, when talking about lack of understanding between C and C++ differences is that, at least on enterprise space, many use C++ compilers for writing what is mostly C-like code.

Do you know why most MFC classes have an Afx prefix?

Microsoft created a C++ framework similar to OWL in abstraction capabilities, but the test group of early adopters said it was too high level and they just wanted a thin wrapper around Win32, hence Afx was reborn as MFC. [0]

I like modern C++ very much, and it is true that many of the "modern C++" concepts were already available on C++98, the problem is getting developers to actually use it, specially old school devs when working in companies where CI builds, static analyzers or sanitizers aren't part of the culture.

Which is the situation I see most of the time across many enterprise customers.

[0] http://cs.sookmyung.ac.kr/class/00891/C++/mfc-faq/

I completely agree with you on that take.

However, if you accept that take, I see little chances of convincing management in such a company to switch to a new, fledgling language - even if it were much safer to use. If anything, your hopes might be that you can teach their teams to use modern C++ and accordingly and slowly massage their code-bases into a more up-to-date state...

Ie., (not the least due to those vast code-bases) C++ (and Java) is (are) quite certainly going to stick around for the foreseeable future, like it or not. I don't really see any great migrations coming our way as long as those languages keep updating themselves to reflect the more significant insights from programming language research, even if those updates lag behind by years.

Hence why I mostly focus on Java, .NET and C++, and tend to comment that regardless how great Rust might be, it will take several years for any relevant uptake.

Just to show how bad it is to move those big enterprise ships, only now in 2017 has BMW moved from C to C++14, for their car platform.

https://fosdem.org/2017/schedule/event/succes_failure_autono...

> Do c/c++ for 10 years, like the author, and then you're qualified to comment about the topic. If you're new to this, try to put your time into actually learning about these topics and not just blindly repeating other peoples opinions. Please don't say things like "c/c++ is unsafe and should not be used" without understanding it first.

I don't think you need 10 years to understand enough to be qualified to comment. Like it or not people make mistakes, even the most seasoned coders do. C does its best to turn every little oversight into a potential entry in the CVE database.

> And try to consider for a moment that a humongous part of the critical software in the world is written in it. It is the industry standard for all things embedded and low level.

That is a valid excuse to use it but it doesn't mean that shouldn't be changed. What you see quite often is people defending using C less because of leveraging the existing ecosystem but because "it's so beautifully simple" and this "experienced coder can do it right" elitism.

> This is how stupid cargo cult gets made, guys. It's easy to repeat some talking points that you found on the rust homepage or another internet forum, but doing that does not make you an enlightened programmer!

> The thing is, I'm not even saying the author is wrong (I don't think he is). I'm just saying that circulating these kinds of opinion posts here and then applauding each other for being such brilliant rust fanboys is not helpful.

Nobody talks specifically about rust here, it's just a new promising language which is designed to fit inside the territories where C/C++ are prevalent and seems to have some traction. Rust is simply a non-theoretical opportunity to shift to something better.

You took my post as saying "all systems code should be written in C and that should always stay that way because people don't make mistakes". However, that is not at all what I said (also see other replies).

What I said was that one should not blindly make the opposite (false) reverse assumptions, which are that "code should not be written in C/C++ because they are 'unsafe'" or "all code written in 'safe' languages is 'safe'" (both for a hand-wavy definition of safe). The point that I tried to make was that if you do not have a good understanding of C++, you're probably not qualified to comment on the matter of some alternative being safer/better than it or not. And also that just blindly repeating other's opinions is not a path to understanding in this case.

I realize that the linked article didn't say or do that, but my comment was clearly not directed at the author of the post, but at the community of this forum (just look around in this thread to find some of the group-think I'm referring to).

The big safety wins from Rust for me are things like the type system disallowing iterator invalidation, the type system handling resource releases, iterators making bounds checks a lot more affordable, the shared immutable/unique mutable distinction, the ability to encode that something can't keep a value somewhere accidentally, type system enforced thread safety, and others in that category.

Why would I need a good understanding of C++ to consider these built-in facilities or the ones that just happen due to the type system as safer?

I don't think you need a good understanding of C++ to appreciate these features per-se. Only if you want to make a statement like "X is an improvement over C++ because of these".

For example, enforced const-ness/immutability, option types and automatic ressource management (RAII) are also already standard in modern/best-practice C++ code. In general I agree that there are a lot of nice languages features that rust currently has which would also be nice to have in the c-family languages.

> I don't think you need a good understanding of C++ to appreciate these features per-se. Only if you want to make a statement like "X is an improvement over C++ because of these".

What about "X encoding thread-safety through the type-system is an improvement over the C++ way" and similar? This is how I usually read these kinds of statements.

No, you can also learn from experiences of others instead of doing mistakes for yourself.