Umm, no thanks.
It's time to halt starting any new projects in C/C++
81–90 of 929 posts
Re: It's time to halt starting any new projects in C/C++
#82Calling him the Azure CTO is strictly accurate, but HN readers probably know Mark Russinovich better as one of the primary developers of sysinternals[1]. I bring that up to highlight the weight of his opinion: Russinovich is legendary in terms of his systems programming contributions. [1]: https://en.wikipedia.org/wiki/Sysinternals
absolutely! came here to say just that. also the excellent book "windows internals", which is kind of like the bsd red book, or the magic garden svr4 book, but for systems derived from the windows nt kernel. but perhaps his best work is this: https://learn.microsoft.com/en-us/sysinternals/downloads/blu... a screensaver that produces a realistic blue screen (kernel panic) for the version of the operating system and ke…
I remember trying to install that screensaver yet always having it crash my system, for some reason.
I did wonder how a screensaver can crash the kernel, until I remembered what it's supposed to do.
I was embarrassed for quite a while after that.
Re: It's time to halt starting any new projects in C/C++
#83> For the sake of security and reliability. I just read a few C++ vs Rust comparisons online yesterday and didn't see anything about a significant difference in security or reliability. Mind you the articles weren't very technical. How is Rust so much more secure and reliable than *modern* C++?
Memory unsafety makes securing large codebases difficult because even minor errors in unimportant parts of a codebase have the potential to compromise an entire binary if an attacker can figure out how to get execution to reach the unsafe code and exploit it. Human code review is fallible and junior engineers exist, so if you want to be confidant that your codebase is free of such vulnerabilities you need to depend on static analysis. Rust makes this a lot easier because a lot of the guarantees you'd want to make using static analysis on your C/C++ codebase are built into the language, and the language helpfully flags for you the sections of code that need careful human scrutiny.
Re: It's time to halt starting any new projects in C/C++
#84Earlier quoted context omitted.
Well, it's a multiparadigm language, so both :-) I'm being facetious, but it really is both: it's too unstable in ways that are bad, and also too stable in other ways that are bad. Edit: since you updated your comment: Rust is not in the same position as C++. C++ has an unstable ABI that it cannot break; Rust has an unstable ABI that it can (and regularly does break). Rust works around this with developer tooling; C+…
> Rust works around this with developer tooling; how does that work for companies that may use proprietary rust libraries? the proprietary lib authors won't recompile their shit for you just because you upgraded to the latest rustc
As pointed out, the C ABI is stable. If companies absolutely feel the need to distribute Rust shared libraries and cannot guarantee the compiler being used, then it's a reasonable choice. I suspect that isn't very common, however.
More realistically, the answer is to change the interface: Rust is pretty popular in software architectures where the unit of operation is a networked or IPC'd service; vendors can distribute binaries that communicate at that layer instead.
Re: It's time to halt starting any new projects in C/C++
#85> For the sake of security and reliability. I just read a few C++ vs Rust comparisons online yesterday and didn't see anything about a significant difference in security or reliability. Mind you the articles weren't very technical. How is Rust so much more secure and reliable than *modern* C++?
> How is Rust so much more secure and reliable than *modern* C++? Rust catches things like use-after-free at compile time. *modern* C++ still lets things slip through e.g. #include #include #include int main() { std::string s = "Hellooooooooooooooo "; std::string_view sv = s + "World\n"; std::cout
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 practice, rust will take over when it convinces enough C++ developers that the tradeoff is worthwhile.
That rarely happens by CTO's, or anyone else, telling everyone they are doing it wrong, but instead by helping people see easier ways of doing things, and ways to get work done faster/etc.
Or, you know, waiting for everyone who does it the old way to die.
Re: It's time to halt starting any new projects in C/C++
#86For systems programming, use whatever the Linux kernel uses. For everything else, there is javascript.
I don't think it's possible to choose a worse (mainstream) language for general purpose use than Javascript.
If it's not running in the browser it should simply never be JS. That is the only environment where you are stuck with it. Almost anything else is better but you should probably using one of Java/C# or Kotlin/Rust in 2022.
Re: It's time to halt starting any new projects in C/C++
#87Earlier quoted context omitted.
> Rust works around this with developer tooling; how does that work for companies that may use proprietary rust libraries? the proprietary lib authors won't recompile their shit for you just because you upgraded to the latest rustc
As pointed out, the C ABI is stable. If companies absolutely feel the need to distribute Rust shared libraries and cannot guarantee the compiler being used, then it's a reasonable choice. I suspect that isn't very common, however. More realistically, the answer is to change the interface: Rust is pretty popular in software architectures where the unit of operation is a networked or IPC'd service; vendors can distribu…
> vendors can distribute binaries that communicate at that layer instead.
they could do this in C++ also but they overwhelmingly don't, I don't see why they would in any other language for the same target applications
Re: It's time to halt starting any new projects in C/C++
#88Has he ever heard of kernels or device drivers? Probably not.
Re: It's time to halt starting any new projects in C/C++
#89Inside Azure there’s an over reliance to C#, and the older versions of it to boot! So one team in charge of making .NET run faster and better, while the other one drags on using decade old versions
Then for “speed” there’s weird mashups of C++ and C# that are just littered with terrible internal build tools that harken back to a nice 2010s and the idea of:
“Idk it builds in my machine just fine”
As far as Rust goes, it’s as plentiful as F# projects (so not existing).
But that’s just what my close friend says at least.
Re: It's time to halt starting any new projects in C/C++
#90Has he ever heard of kernels or device drivers? Probably not.
Most likely yes, check SysInternals and Windows Internals books.