Hacker News Reader

Comment by ojeda | Hacker News Reader

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

View on HN

A 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.

My 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.

I just had a look at two examples from that windows-rs repo.

https://crates.io/crates/windows-sys

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)

Unsafe 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++.

> 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.

It'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.

> 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.

I 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.

I was gonna say he addressed Microsoft's rust library, but apparently that was something different?

https://github.com/microsoft/windows-app-rs#this-repository-...

I'd say it's confusing but I wouldn't expect any different from Microsoft.

Reply on news.ycombinator.com