3 ms·
Yeah, Win32 (Windows API) will be around for a long time one way or the other, and there is a ton of tooling and docs around it. Even for non-Windows usage it i
by ojeda 7mo ago
Yeah, Win32 (Windows API) will be around for a long time one way or the other, and there is a ton of tooling and docs around it. Even for non-Windows usage it is to be considered in certain situations.
> Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.
Even without untrusted inputs, in 2026 one should think twice before selecting C++ for a new project. There are still some reasons to do so, of course, but Win32 isn't one of them -- one can use it from a memory safe language just fine, e.g. https://github.com/microsoft/windows-rs https://github.com/microsoft/windows-rs
- steve1977 6mo agoI just had a look at two examples from that windows-rs repo. https://crates.io/crates/windows-sys https://crates.io/crates/windows-sys https://crates.io/crates/windows https://crates.io/crates/windows Both seem to do the actual work in unsafe blocks, so I guess you could as well use C++, no? (only have limited Rust knowledge)
- poly2it 6mo agoIt's straightforward to contain the unsafe usage and potentially write safe wrappers and structures around it. Memory bugs mostly stem from the larger application in conjunction with the API anyway, rarely only the API layer.
- maleldil 6mo ago> so I guess you could as well use C++ The unsafe code is written inside the library, which the user can contain in a safe API. With C++, the entire codebase is unsafe.
- LeFantome 6mo agoUnsafe blocks are common when interfacing with C or C++ code. The first thing you want to ensure is that you avoid unsafe in YOUR code. That is, after all, where you are going to create your bugs. Ideally, there is no unsafe code in the crates you use. If there is, at least there are more eyes on that code to catch problems. You can inspect and debug that code, and others can do it for you. Others may battle test it and stress it far more than you will. And at least the unsafe code is isolated to a few areas in the supporting libraries. Less to inspect. Less to debug. Fewer places to introduce memory related regressions. It does not at all follow that, given an unsafe block, we may just have well used C++.
- wolvesechoes 6mo ago> Even without untrusted inputs, in 2026 one should think twice before selecting C++ for a new project. Yes, you may be harmed by proper IDE and debugging experience via Visual Studio.
- ojeda 6mo agoI like Visual Studio, and have used it for C++. And, yes, it would be great if they add native support for Rust. But that would not make me pick C++ over Rust. Other requirements may.
- blub 6mo agoA good rule of thumb for programming languages is to check what the general recommendation is on HN and do the opposite. Using win32 from Rust is nonsensical. This is the kind of use-one-tool-for-any-job Visual Basic 6 programmers used to have, except VB6 would have actually been much better than Rust at Windows programming.
- ojeda 6mo agoMy reply was about Win32 and typical C++ development. Obviously other projects may be best written in C# or other languages and frameworks. Anyway, Microsoft is the one providing the Rust crate(s) I linked, and according to the releases it seems they are using them internally too. I do not see what is "nonsensical" about using them, and I have used them in the past just fine, just like I used Win32 from C++ in the past.
- hbn 6mo agoI was gonna say he addressed Microsoft's rust library, but apparently that was something different? https://github.com/microsoft/windows-app-rs#this-repository-has-been-archived https://github.com/microsoft/windows-app-rs#this-repository-... I'd say it's confusing but I wouldn't expect any different from Microsoft.