Live data from Hacker News

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

twitter.com

151–160 of 929 posts

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

#151
post #31

The C/C++ people hate it when you call it C/C++.

That's a fairly recent thing that some people do as a kind of virtue signaling. The "C/C++ Users Journal" was a very popular publication and no one took issue with its name. Nor do people take issue with Dr. Dobbs which has a "C/C++" section with articles from highly influential members of the C/C++ community. C++ is a complex language, so people invent ways to show how dedicated they are to it, and nowadays that mea…

> That's a fairly recent thing that some people do as a kind of virtue signaling.

If by recent you mean well over 20 years ago. When I began learning C circa 2000, I used to hang out on comp.lang.c, and "C/C++" was very much frowned upon. And for good reason--people felt entitled to ask C++ questions in a C newsgroup, which was and remains a poor idea. Even if they were asking questions relevant to both, e.g. regarding pointers, it's still a much better idea to ask in a C++ newsgroup. See https://en.wikipedia.org/wiki/XY_problem

There are people (invariably young) who resist newsgroup etiquette, convinced the etiquette is pointless, or something like virtue signaling. Over the decades they eventually come around to appreciating the wisdom, even if there's never a mea culpa.

The commercial software world, and especially the Windows world, often had a much different culture than what developed online, especially in the FOSS and Unix subcultures. For the latter especially, C++ was relatively uncommon until the 21st century. C++ (with KDE, etc) and then Python had the effect of importing or creating whole new subcultures in these communities without any memory or appreciation of the pre-existing culture.

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

#152

Earlier quoted context omitted.

If we are offering absolutist opinions, I would like to offer a counterpoint. >I've got macros to do automatic bounds checking. I've got RAII and stack traces. I've got structured concurrency, which will give the same capabilities as the Rust borrow checker if you adjust your coding style. And all this in portable C11. You can do this all in C but it is an absolute nightmare. Every large C program grows some strange…

I understand you think it's awful, but I do like it. Everyone has their preference.

You can like something and still admit that it is awful. I "liked" C for a long time before there were better options...

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

#153

Earlier quoted context omitted.

My understanding (which might be wrong) is that you can rely on Rust not making incompatible ABI decisions between builds of the same optimization level on the same compiler version. In other words: you don't need to export a C ABI as long as you're able to enforce that every crate is built dynamically with the same compiler and flags. That is of course still a significant restriction!

ABI shenanigans are what killed the whole "off-the-shelf components" promise of C++ and object orientation. They really made the same mistake again?

Rust wants to fix this, but it's an extremely hard problem and other tasks received higher priority.

See "How Swift Achieved Dynamic Linking Where Rust Couldn't" for details: https://faultlore.com/blah/swift-abi/

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

#154

Earlier quoted context omitted.

If by "slip through", you mean "warns you about by default", then yes it lets it slip through. clang++ -std=c++17 test.cc a.cc:7:29: warning: object backing the pointer will be destroyed at the end of the full-expression [-Wdangling-gsl] std::string_view sv = s + "World\n"; ^~~~~~~~~~~~~ In any case, I think the philosophical differences between C++ and Rust are well understood, and the different views of the cost/be…

In a large codebase with many warnings (incl from dependencies which you might not have control over), the difference between a compiler warning and hard error is significant.

`-Wall -Werror -Wextra` is the first thing to add to any project's cpp flags. And then selectively -Wno-whatever the stuff you don't really care about or is too annoying to go fix if it's an existing codebase

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

#155

Someone else downthread: "young developers can pick up Rust quite fast, and that makes it vastly easier than trying to find talented C/C++ developers." I hope so. I have a hypothesis that the big-O for language success is "How easily can new programmers learn it?" Nothing else matter. JavaScript was slow, but everyone learned it, so it got fast. Python still had bad tooling, but everyone learned it, so it got better.…

Another option is get your existing devs to learn Rust. I think people would be more happy to do that than learn C/C++.

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

#156
post #91

The volume of existing C, C++, Objective-C, and C# code is phenomenal. Even if this strategy is generally adopted there will continue to be lots of this legacy code for many years to come. In particular there will continue to be such legacy code right up until 2038 at least.

Sure

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

#157

For systems programming, use whatever the Linux kernel uses. For everything else, there is javascript.

>> For systems programming, use whatever the Linux kernel uses. https://www.zdnet.com/article/linus-torvalds-rust-will-go-in... >> For everything else, there is javascript. Scientific / numerical computations? GPU / CUDA programming? Machine learning? Natural language processing?

> Scientific / numerical computations? GPU / CUDA programming? Machine learning? Natural language processing?

We serve CRUD here, sir.

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

#158
If only IBM can get Rust working on AIX..... we may even start using it. Rust is an able C/C++ replacement. Even Linus, who's picky about what goes into the kernel tree, is allowing/supporting it. It really shouldn't be a burden to pick up for anyone who's done C/C++, IMHO.

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

#159

Earlier quoted context omitted.

carbon, and the newly announced alpha stage efforts called cppfront, can potentially act as a "typescript" for c++, new compiler can enforce memory safety at an upper layer before they're converted to c++, maybe there is hope for c/c++ code for years to come as long as they keep fixing issues along the way.

Is anyone attempting to do the same with C though? Carbon & cppfront, if successful, would only "save" C++. C would still be left out to dry. Then again, the C committee is also pretty much phoning it in and has been for quite a while now.

Yes. Microsoft Research is working on "Checked C": https://www.microsoft.com/en-us/research/project/checked-c/

As a test, someone ported FreeBSD's networking stack to Checked C. It was easy and there was no overhead to performance and binary size.

Post reply on HN