Live data from Hacker News

It's time to halt starting any new projects in C/C++

twitter.com

711–720 of 929 posts

Re: It's time to halt starting any new projects in C/C++

#711
It's a good thing I got my latest one started before this was announced!

All kidding aside, as others have pointed out this is coming from someone with tremendous credibility and it is worth giving some consideration. I have a lot of respect for Rust although I've only toyed with it for personal projects. The compiler provides very helpful messages (vast majority of the time), but even so, for complex applications it can still be very difficult to reason about.

As has already been mentioned, it doesn't seem to be anywhere near prime time for GUI applications (such as those built with Qt, Gtk, Win32, etc.). I don't think it's fair to say that ALL GUI apps should be built with a managed language.

Like with go, one of the nice things is that there's just one provider of the compiler. At least you don't have to contend with different levels of support and different compiler options.

Re: It's time to halt starting any new projects in C/C++

#712
post #300

Earlier quoted context omitted.

Then you might as well talk about "C/Rust". Both go to LLVM. But nobody says it, because it would be BS in exactly the same way "C/C++" is. What matters about a language as a technology, as in the context of this Mark guy's blurb, is how it works in use. There, C and C++ share hardly anything in common: what you do writing good code in one is nothing at all like what you do with the other. You might get a C program c…

LLVM is not a compiler frontend. It’s the middle- and back-ends; Clang is the frontend. Neither Rust nor C is inextricably linked to LLVM either, as I’m sure you’re aware. And the former doesn’t align with the abstract machine assumed by the latter in important regards, like forward progress. The rest of this is just a screed. I’m not here to defend his honor, and you shouldn’t waste your time posting about it on ran…

You asked, I answered. I will not waste any more.

Re: It's time to halt starting any new projects in C/C++

#713
post #534

Earlier quoted context omitted.

Wut? Makes no sense to me.

Here's an example of C++ code written intentionally with all the latest C++ features: https://gist.github.com/caiorss/c7db87df674326793431a14006aa... It looks pretty much nothing like a C program doing the same job. A lot of those features were made to make C++ a safer language to use. Eg, with a construction like: for(const auto& it : ast){ You can't accidentally walk past the end of the array by going one item too…

Sure, but it’s not enough.

You can forget the virtual destructor. Maybe the language is excused because it’s only a leak.

You could mess up the what() functions. (It’s not locally obvious that it’s correct in this code.) std::exception is fundamentally dangerous. Rust can get away with safely returning references like that because the lifetime is part of the function’s signature. C++, even modern C++, can’t.

Even the iterative example is only a bit safe. You can’t walk off the end by going one too far, but you can certainly mess up by invalidating the iterator in the loop body.

Re: It's time to halt starting any new projects in C/C++

#714

Earlier quoted context omitted.

Here's an example of C++ code written intentionally with all the latest C++ features: https://gist.github.com/caiorss/c7db87df674326793431a14006aa... It looks pretty much nothing like a C program doing the same job. A lot of those features were made to make C++ a safer language to use. Eg, with a construction like: for(const auto& it : ast){ You can't accidentally walk past the end of the array by going one item too…

Why are spaces randomly omitted for language constructs like if and for, and reference type &s left aligned?!

In other words, you are not aware of anything wrong with this code.

Re: It's time to halt starting any new projects in C/C++

#715
post #534

Earlier quoted context omitted.

Wut? Makes no sense to me.

They’re claiming the CTO of Azure doesn’t know enough about modern C++ to make the statement that we’re discussing. Bold claim.

All kinds of CTOs are not very technical in many ways.

They usually have not been in the trenches for a good while at least (could even be like 20+ years since they've done any development), and they take the ultimate decisions for their whole company for all kinds of languages and environments they have had no experience with... (like a CTO that used to do C back 20 years ago, now having a say in the use of Rust or Node).

Re: It's time to halt starting any new projects in C/C++

#716
post #551

Earlier quoted context omitted.

I find it hard to imagine the CTO of Azure has done enough C++ programming in the last few years to be fluent in C++20. Maybe as a hobby I suppose; it doesn't match my understanding of what a CTO of a big organisation does otherwise.

He doesn’t need to be fluent in every language to set technical direction as a CTO. You don’t question a general’s war strategy simply because they aren’t accurate with a rifle.

>He doesn’t need to be fluent in every language to set technical direction as a CTO.

No, but he does need to "know enough about modern C++ to make the statement that we’re discussing".

Re: It's time to halt starting any new projects in C/C++

#717

Earlier quoted context omitted.

Cargo is the number one feature of Rust that makes it easier for a newbie to use. New users of C++ struggle the most with building and linking projects together. Cargo makes that newbie proof. Source: I teach C++ and Rust to new programmers, and they almost universally get further, faster with Rust than C++.

Meson has improved the build situation in C++ significantly.

Kind of, but it also exacerbates one of the problems with C++ build systems which is there are so many and none of them are the build system. On one hand this is desirable from the perspective that it avoids monoculture. But it's a bad thing from the perspective of a new programmer in that it causes a lot of confusion and a form of "choice paralysis", where programmers become overwhelmed by options and choose nothing out of a fear of making the wrong choice.

Re: It's time to halt starting any new projects in C/C++

#718

Earlier quoted context omitted.

The advantage w.r.t references is that with Slotmap, you can express cyclical data structures, whereas with references you can't. The advantage w.r.t plain Vec and juggling integer indices is that unlike integers, Slotmap keeps track of the "identity" of the stored object; the keys are unique to that object, and you can't accidentally refer to a wrong object with them. > errors risk being silent references to wrong o…

I meant counted references that were mentioned as an alternative in the GP comment. A generation count indeed could mitigate "use after free" style bugs, but may have a high false negative ratio if many/most objects have same generation. But a glance at slotmap docs didn't yield any hits for a generation I'd being used, do you have a specific link?

> I meant counted references that were mentioned as an alternative in the GP comment.

The main problem with reference counted pointers is detecting cycles. Rust doesn't have a cycle detector, but only a concept of "weak" pointers that don't prevent the object they're pointing at from being destroyed, just detect if it has been. This works fine if you have a tree with parent pointers, you make the parent pointers weak and everything works. It doesn't work so well if you don't have a clear tree structure though, because then you can't really tell which pointers should be strong and which should be weak.

> but may have a high false negative ratio if many/most objects have same generation. But a glance at slotmap docs didn't yield any hits for a generation I'd being used, do you have a specific link?

Apart from wrapping around after 2^32 frees of a specific slot, I don't believe any false positives are possible. The trade off is that there's more overhead than I think you're imagining.

https://docs.rs/slotmap/1.0.6/slotmap/#performance-character...

Re: It's time to halt starting any new projects in C/C++

#719
post #382

Earlier quoted context omitted.

Yes but everything is versioned so it's not like this will break any existing applications unless the user/owner explicitly upgrades (but then they should be ready for breakages). The absence of versioning hell with Rust is one of the many things I love about Rust.

On the other hand it means you don't automatically get security fixes and have to manually set up CVE monitoring and rebuild your application every time a CVE appears. Of course if it appears in an old version the author won't bother to backport the fix so you will have to bump the dependency to the latest, doing all the API changes that you didn't want to do.

Are we still talking about Rust or have we moved on to general grumbling about life?

Re: It's time to halt starting any new projects in C/C++

#720

Earlier quoted context omitted.

They have played us for absolute fools

Can you please elaborate?

I was being sarcastic. I find the assertion that modern C++ is a scam hilarious. It doesn't make any sense. Who benefits from this scam? Who are the victims?

The sentence is indeed from a meme template[1], but I thought that my comment would stand on its own.

https://knowyourmeme.com/memes/stop-doing-math

Post reply on HN