Hacker News Reader

Comment by _zagj | Hacker News Reader

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.

View on HN

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.

That would be any pre-ARMv8.1 machine?

In this case, it was specifically openwrt on mipsel.

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.

Reply on news.ycombinator.com