Live data from Hacker News

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

twitter.com

351–360 of 929 posts

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

#351

Earlier quoted context omitted.

So he is just complaining without proposing any real solutions then?

> he is just complaining Um, he is who? > without proposing any real solutions If he is Mr. Russinovich, he is saying, "For the sake of security and reliability. the industry should declare those languages as deprecated." Sounds like a proposal to me?

Not without recommending adequate alternatives.

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

#352

There are new programs being written daily in COBOL and Fortran, and I'm fairly certain that I see new PL/I floating around occasionally. C and C++ aren't going anywhere anytime soon. Love them, hate them, want to burn them with fire, they're here for a long, long time. Leaving that aside, I was still hitting Rust "oh look the developer of this crate on which the entire universe depends still assumes that everything…

> Get a build system that's easily workable without an Internet connection and recent TLS support. I'll say typing `cargo build --offline` can qualify as "easily workable".

How do you vendor to local, without the recent TLS support?

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

#354

Earlier quoted context omitted.

Why not just hire good people and ask them to learn C++. I mean how the heck did anyone actually pass this magic barrier of becoming a "C++ dev" in order to get hired as a C++ dev?

Because “just hire good people” is on par with “just hire good pilots”. Easier said than done.

Um no. A closer analogy would be like hiring a good 737 pilot for 777 instead of someone with thousands of hours on the 777.

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

#355

Earlier quoted context omitted.

"Oh, and it's possible to make C as good as Rust", do you have some concrete advice documented somewhere? Thanks!

Write a full unit and functional test suite and run them with asan, tsan, msan and maybe valgrind. This has caught all the memory bugs before getting to production in my experience. You need the test suite to verify that your code does what you think it does anyways, the sanitizers are just a nice bonus to verify that it also has the safety you think it does.

Yes, absolutely. This is how I do it.

The test suite and asserts for every assumption are hugely important too. Testing under runtime is important.

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

#356

Earlier quoted context omitted.

Because, little by little, C++ became "unlearnable". Long ago C++ made C a little bit more complex. Because there were already lots of C programmers that wasn't a big deal. But then it didn't stop. Little by little C++ grew into a monstrosity. A lot of people went along. I gave up. For new programmers to climb in 2-3 years a mountain that seasoned programmers took 15-20 years to climb is asking too much.

In what world is C++ harder to learn than Rust?

For the vast majority of programmers who don't know either. learning how to write correct Rust is easier than learning how to write correct C++.

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

#358

Earlier quoted context omitted.

This is a tangent, but how do people comply with the MIT (or other) license when statically linking binaries? You have to include the copyright notice and license, but I almost never see that being done (and, based on the Rust projects I’ve seen, there are often tens, or even hundreds of MIT/BSD/Apache licensed dependencies).

People who use permissive licenses usually don't care about the license-inclusion clause, so most people just don't bother with it until someone comes asking. At the end of the day, fixing that problem is just a matter of including a new text file in the next release. It's nowhere near as big of a deal as when someone complains that you're not complying with the GPL. By the way, whether you're linking statically or d…

I disagree with both paragraphs.

By choosing a license that requires attribution, developers are communicating a preference. MIT0 and 0BSD exist. If someone does not care about attribution, they would use one of those licenses.

Dynamically linking to a MIT lib is not the same as distributing an MIT lib, so yeah static linking to the lib is completely different, according to the terms of the license.

If you are working professionally as a software developer, or even just appreciate open source contributions, please take licensing terms more seriously.

Kind regards.

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

#359
C sits at a sweet spot of performance vs. expressiveness vs. portability whose Pareto-optimality has withstood a half-century test of time. It’s not going anywhere.

The case for replacing C++ is a lot stronger but I don’t see game engines, for instance, switching to Rust (or using garbage collection) any time soon.

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

#360
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.

Even more of a reason to implore a moratorium immediately.
Post reply on HN