3 ms·
Maybe yes, but on the other hand I've never been paid for anything that used OS calls directly. The only times I've used such APIs was creating simple keylogge
by tester756 4y ago
Maybe yes, but on the other hand I've never been paid for anything that used OS calls directly.
The only times I've used such APIs was creating simple keylogger for tests and very simple cheat for a video game (tested on non-official servers).
C# nowadays seems mostly like web backend development, tools, game scripting or automation, at least that's my perception.
Anyway even if WinAPI, then why not Rust?
- UncleEntity 4y ago> Anyway even if WinAPI, then why not Rust? Because they said they already know rust and were asking about C…
- tester756 4y agoI meant in general, not just OP
- gwbas1c 4y ago> Anyway even if WinAPI, then why not Rust? Plenty of reasons: First of all, most operating systems (and other lower-level APIs) you want to work with expose their APIs as C. These don't all have bindings in Rust. Even if you want to do them in Rust, you need to know enough C to be able to understand how to consume the API. But then, there's plenty of legacy code in C. We aren't going to rewrite everything in Rust overnight. More importantly, I think the "jury's still out" if Rust is better than C for embedded programming; or programming that's primarily direct memory manipulation. (And, if your embedded environment only gives you an API in C, you need to know enough C to write the API bindings for Rust before you can do embedded programming in Rust.) Personally, I don't have any experience with unsafe Rust code. (I only do hobby projects in Rust.) In C# you can do C-style direct memory manipulation if you need to; but I'm not sure if Rust's "unsafe" is equivalent.