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?
It's time to halt starting any new projects in C/C++
351–360 of 929 posts
Re: It's time to halt starting any new projects in C/C++
#352There 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".
Re: It's time to halt starting any new projects in C/C++
#353Can you even use Rust for Windows GUI programming? Is it a practical choice at all for interfaces?
Re: It's time to halt starting any new projects in C/C++
#354Earlier 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.
Re: It's time to halt starting any new projects in C/C++
#355Earlier 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.
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++
#356Earlier 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?
Re: It's time to halt starting any new projects in C/C++
#357Re: It's time to halt starting any new projects in C/C++
#358Earlier 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…
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++
#359The 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++
#360The 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.