Hacker News Reader

Comment by capableweb | Hacker News Reader

> 1. It's amazing that they're doing this as a gradual C++ to Rust rewrite, while keeping it working end-to-end, if I understand correctly.

Seems to me they're not doing it gradually at all.

> Another thing:

> We plan on not doing any partial-rust release.

> That means we would be doing e.g. fish 4.0 as fully rust and zero C++, and I think, contrary to what we usually do that warrants a beta. (Ordinarily we've stopped doing betas and release candidates because they simply don't get any testing).

> We also still want to do a 3.7.0 in-between release that is still purely C++, so we have a better jumping off point for platforms that can't handle the rust version. It would be 3.6.1 with some neat changes backported.

https://github.com/fish-shell/fish-shell/discussions/10123#d...

View on HN

It's a bit of both. They are not doing any mixed C++/Rust releases, but you can check out the source and build it in the current mixed state and it will produce a binary that contains parts from both languages and works as a Fish shell.

>Seems to me they're not doing it gradually at all.

They are doing the release all-at-once, but developing gradually. From the original PR[1]:

>This should be thought of as a "port" instead of a "rewrite" because we would not start from scratch; instead we would translate C++ to Rust, incrementally, module by module, in the span of one release. We'll use an FFI so the Rust and C++ bits can talk to each other until C++ is gone, and tests and CI keep passing at every commit.

[1] https://github.com/fish-shell/fish-shell/pull/9512

The price of C++ compatibility is that it doesn't use Rust strings internally. It's all "wchar" and "WString", which are Microsoft C++ "wide character strings". This may be more of a Microsoft backwards compatibility issue than a C++ issue.

and yet they may be breaking Cygwin support?

I think the problem is more like, there are valid files that aren't representable as rust strings?

That's why OsString exists.

The Cygwin issue isn't strings (well, that could be another issue) but that Rust doesn't support Cygwin in the first place, at least according to the comments in the linked thread.

Well, for whatever reason, it doesn't meet their requirements... See the String section of https://github.com/fish-shell/fish-shell/blob/master/doc_int...

edit: here is a more specific rationale: https://github.com/fish-shell/fish-shell/pull/9512#discussio...

>here are valid files that aren't representable as rust strings

Like? I don't use rust but I assume it's capable of utf 8 ?

Rust strings enforce utf-8 encoding, yes. However, it seems Windows (which uses utf-16) allows ill-formed UTF-16, in particular it tolerates unpaired surrogates.

You can read more here http://simonsapin.github.io/wtf-8/

Rust is capable of UTF-8. It is not capable of not UTF-8. Any sequence of bytes that is not a valid UTF-8 string cannot be represented by the String type.

The siblings are correct but also not precise in a way in which could be misleading.

Rust has one built-in string type: str, commonly written &str. This is a sequence of UTF-8 encoded bytes.

Rust also has several standard library string types:

* String is an owned version of &str. Also UTF-8.

* CString/CStr: like String and &str, but null terminated, with no specific encoding

* OsString/OsStr: an "os native" encoded string, in practice, this is the WTF-8 spec.

And of course, all sorts of user library-created string types.

The issue at hand isn't that there's some sort of special string type that Rust can't represent, it's that they have an existing codebase that uses a specific string type, so they're going to keep using that type for compatibility reasons, rather than one of the more usual Rust types. This means they won't have to transcode between the two types.

<3 WTF-8

If we're competing to be pedantic here, the problem is that Windows encodes paths as UTF-16 and Linux can support just about any random jumble of bytes in a path regardless of if those bytes are valid UTF-8 or not. Neither of these play nicely with Rust's "if it can be represented, it's valid" approach to code safety, so OsStr(ing) exists as a more permissive but less powerful analogue for such cases.

It has nothing to do with Windows. fish doesn't support Windows. Their use of wchar_t is the glibc wchar_t (wchar_t is not Microsoft-specific) which is a 32-bit type and stores UTF-32-encoded codepoints. The Rust type they're using is also the same ( https://github.com/fish-shell/fish-shell/blob/master/doc_int... ).

Reply on news.ycombinator.com