That may not seem like a big deal for the x86_64 world where modern mitigations largely make shellcode a thing of the past (hence heap exploitation, ROP/JOP, etc) but it is a BIG DEAL for embedded microcontrollers that lack OS/HW memory protection - an area where #![no_std] Rust shines.
As a security researcher and not a developer, let me be very frank: you should STRONGLY consider Rust in place of C or C++. But know that release profile builds don't do integer overflow checking, so don't get cocky :P
I think it’s also available for free online. Here?
Both are great and I still refer to The Book (and Programming Rust) from time to time.
I'd be really keen to pick up v2 of Programming Rust.
TerraFX is greater than just Windows bindings but it is certainly useful for even just that. I've contributed a lot of bindings recently for some low-level Windows headers. Contributions are welcome!
Assuming Microsoft isn't talking about solely using Rust in Windows The Operating System and Linux The Operating System, they agree with my definition.
Keyword being "closer" to the operating system, of course it doesn't mean just syscalls and Assembly. If you define "system" in "systems programming" in this broad sense of "something that other things call" you dilute the meaning of the term. Any program becomes "systems programming" then.
I'm sure that most people didn't use the term in this sense before Go's creators did and till this day I see only the Go community re-purposing the expression. I'd be happy to be proven wrong, though.
That tended to mean a language designed to compile down to processor instruction sets the way C, C++, or now, Rust do.
Go was intended to replace C++ and C for many of the things that Google programmers did, but it wasn't intended to aim at "bare metal" if I recall Rob Pike's design talks correctly.
Every now and then this misconception is found on HN.