Hacker News Reader

Comment by freedomben | Hacker News Reader

> The one platform we care about a bit that it does not currently seem to have enough support for is Cygwin, which is sad, but we have to make a cut somewhere.

> We’re also losing Cygwin as a supported platform for the time being, because there is no Rust target for Cygwin and so no way to build binaries targeting it. We hope that this situation changes in future, but we had also hoped it would improve during the almost two years of the port. For now, the only way to run fish on Windows is to use WSL.

I understand, but this is indeed incredibly sad. To this day I still use Cygwin, and in fact prefer it to WSL depending on what I'm doing. Cygwin is an incredible project that is borderline miraculous for what it accomplished and provides. Without Cygwin I may not have any sanity left. I can't exude enough love for the Cygwin team.

Hopefully rust will support cygwin as a build target in the future!

View on HN

There's nothing technically stopping Rust from supporting Cygwin, except lack of volunteers to complete the port:

https://github.com/rust-lang/rust/issues/5526

(this feature request has been open for 12 years)

It's strange how the article starts off complaining about C++'s platform "issues":

> We’ve experienced some pain with C++. In short:

> tools and compiler/platform differences

before conceding that, because of Rust, they 1) are actually dropping support for a platform they previously supported and 2) can only support (in theory) a small fraction of those platforms supported by g++, but that that's OK because those are the only platforms which really matter. I get that it's a trade-off, but it would have been more intellectually honest to just admit this is one area (portability, backwards compatibility, and ABI stability) where C++ mops the floor with Rust, instead of pretending it's a another paintpoint Rust avoids.

I don't see how the article is pretending anything. They had platform issues with C++ (portability and usability on the platforms they supported), and switching to Rust fixed those issues but gave them a different set of platform issues (they could no longer support Cygwin).

Neither c++ nor rust is a clear winner in portability and platform support. C++ is available on more platforms, but in some ways rust makes it easier to support multiple platforms than it is in c++, for example using rustup to install the latest version of the compiler.

What they got from this isn't that they can now support more platforms, but that they now don't have to spend as much effort on supporting dealing with differences between different platforms.

> Neither c++ nor rust is a clear winner in portability

C++ is the clear winner in portability because of GCC and the wealth of platforms it supports. You can argue you don't care about supporting, e.g., OpenBSD on PPC, but trying to hand-wave away this advantage C++ has over Rust is disingenuous.

C++ is the clear winner in what portability is possible.

But as they outlined, in a lot of cases achieving it is substantially more effort per arch+OS+version target than Rust.

Getting a better ROI on your time is a valid reason to consider something better for your use cases.

It's not disingenuous, you just missed this part:

> but in some ways rust makes it easier to support multiple platforms than it is in c++

The ease of installing Rust on Windows has helped build a culture of cross-platform libraries/crates, and so it's significantly easier to build applications that support more platforms than C++.

Take a library for coloring text on a console, and chances are, it'll work on cmd.exe too (despite that not even using ANSI escape codes).

Take a library for loading other libraries, and it will load .so, .dll, and .dylib too, with feature-gated methods to deal with each platform's quirks.

Rust's standard library helps a bit, e.g. it isolates platform-specific modules into things like std::os::unix and std::os::windows, so it's a bit more obvious when you're trying to use something that won't work on all platforms.

However, it's more just a cultural thing; many Rust things work cross-platform now, people see how nice that is, and so people try to maintain the status quo.

With C++, you often need MSYS or Cygwin, and those have their own limitations; you can certainly make something in C++ that won't need them, it's just harder in comparison.

> but trying to hand-wave away this advantage C++ has over Rust is disingenuous.

I'm not trying to hand wave that away. That is an advantage c++ has. But if you only care about supporting platforms that rust supports, rust can make supporting all the platforms you do care about easier than if you used c++.

C++ may run in more places than Rust but that's nothing to do with how good the tooling is. C++ runs everywhere AND its tooling is abysmal.

Yeah, it's somewhat interesting that they point to Debian's popcon (which is opt-in), when the statistics are basically coming from amd64, whereas I think it would be much more interesting (if possible) to see what the number of installs of fish are on openwrt (and other embedded distros). Currently the openwrt fish install is ~2MB (which is massive on a router), I wonder what the new install size will be with the rust version, and if practically they've dropped everything except desktop/server linux and MacOS?

Rust binaries, once stripped, are not necessarily much fatter than their C++ counterparts. We're not expecting a huge increase there.

Embedded distros should still be supported, though you might need to cross-compile for a few depending on rust toolchain availability. Cygwin is supposed to be getting a working rust target at some point, but who knows?

I fully expect fish 4.0 to be in openwrt (because openwrt runs on x86_64), but what percentage openwrt machines have the space to run it would be interesting (I suspect it won't be an issue, as likely those near the lower limit of openwrt are probably sticking with busybox anyway, and not installing a different shell).

Personally, what I want is inexpensive hardware (routers, but also storage devices) that don't use much power (e.g. ~5W) but are also viable targets for projects like fish, so we can all have nice things.

I know rust-fish is being used on at least some non-x86_64 non-aarch64 routers because we've accepted patches by those users to make it build on platforms without native 64-bit CAS.

IIUC lacking 64-bit CAS is an example of a place where on the surface the Rust situation looks worse than C++ but that's misleading

In this scenario C++ will provide "atomic" types that are just locking - they work but they don't have the behaviour you presumably wanted - and Rust will say OK, there's no 64-bit CAS so you can't have these features.

If all you actually needed was a type that has apparently atomic behaviour then I guess the C++ feature is perfect, but I'm assuming almost nobody asks for an atomic type if they would have accepted a locked type instead and so for them Rust saying "No, sorry" is actually a good heads up that they need to think again for this target.

Interesting perspective. In our case, we accepted a patch to effectively use a lock around a 64-bit integer as the workaround for these platforms, however.

That would be any pre-ARMv8.1 machine?

In this case, it was specifically openwrt on mipsel.

genuinely curious: with so much love for cygwin, why not just run Linux? possibly with a dual boot?

Corporate jobs are nearly always on Windows machines. Cygwin+GitBash can usually sneak past the gate without raising too many eyebrows. WSL is still voodoo dark mark that can require conversations to get IT to allow.

Exactly. I have been running Linux on my personal computer for 15 years now. But frequently for work purposes and corporate jobs I have to work on Windows.

Switching between OSes is a hassle. Besides WSL already has all the loveable parts of Linux, there isn't much point in dual booting anymore

If you’re using WSL, why use Cygwin?

If you're at a very large corporation, Cygwin could have been approved decades ago, but WSL is still going through "auditing". WSL is still new enough that bureuocratic organizations haven't satisfied themselves enough that it can be secured or are just plain stubborn enough to not want the hassle.

I refuse to work at large companies for this reason, but one company I worked for brought on a large American bank as a customer and their infosec terms for vendors essentially required their IT "standards" on us, which sucked as we were a Mac shop. It almost came to a head when all the developers were told they had to seek approval for upgrading their build tools.

How did that saga end?

To avoid using cmd.exe/PowerShell for stuff that needs to run natively. For example, when I used Linux I'd use this very small program named darkhttpd for sharing files among my computers over WiFi; when I switched to Windows I compiled it on Cygwin and it worked just as fine.

Reply on news.ycombinator.com