Hacker News Reader

Comment by DrBazza | Hacker News Reader

If you think Rust strings are bad, you're obviously never developed on Windows.

From my failing memory, MBCStr, CComBStr, BStr, CString, XLString, and then all the unicode versions. Then you're developing in C++, so you also have std::string and std::wstring, oh and u16string, and u32string. Plus char, and wchar.

View on HN

Author here: I've spent about half a decade writing Win32 applications, including things deep in NTFS.

I agree completely that everything about string typing on Windows is worse, especially once you stray off of the happy path. But the post isn't intended to equivocate against a ecosystem with 40 years of legacy APIs in it; it's to nitpick a new ecosystem that I otherwise love ;)

Agreed. Abstracting the OS and its different string versions is hard. Even more so when your language has to work on multiple OSes. And then add into the mix non-mutable by default.

This blog post [1] may interest you (if you haven't already read it).

[1] https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild...

I don't see an alternative to interfacing with that though. If we were to just use UTF-8 strings for everything then there would be files we couldn't handle in various OSs for example. So while it's a bit unwiedly to use filepath.to_lossy_str() etc. I prefer it to a leaky abstraction that hides necessary complexity.

It wouldn't be an issue if OSes forbade non-UTF-8 paths...

It's the unfortunate case that we have OS environments that are usually, but not always, UTF-8, and there's no clear, reliable indication of whether or not UTF-8 is to be expected.

And this was the other article about Rust strings I meant to link:

https://fasterthanli.me/blog/2020/working-with-strings-in-ru...

"Not as bad as Windows" isn't exactly a high bar to clear.

Don't forget lptstr, lpstr, lpcstr, lpwstr, and a dozen more I forgot.

Don't forget _bstr_t! And VARIANT's holding strings (and all the VARIANT variants) and when to use the OLECHAR or TCHAR types and related functions instead of wchar or char...

Yeah, I guess maybe nothing will ever be as bad as strings in Windows with C++.

But rust should't go down this road any further.

If you develop for Win32, you only need to care about UTF-8 and UTF-16 strings and converting between them is just a native function call.

If that were true, then WTF-8 wouldn't exist.

I searched, and this comment was not a joke

Reply on news.ycombinator.com