There is nothing specific in the rust port that makes fish more available for servers or LTS distros.
Before, you would have had to get a C++11 compiler (which used to be a bit of a PITA until 2020 or so), now you need to get rust 1.70 (which isn’t terrible given rustup exists).
I see they’re taking it from this comment, which says
Fish should be available on servers, which run old LTS distros - this means we build our own packages for a variety of them.
Which is something that fish has always done - you can go to https://fishshell.com/ and get packages for Ubuntu, Debian, OpenSUSE and CentOS - all server distros, and these packages are built by the fish developers, not the distros.
That quote comes from the “Setting The Stage” section of the comment, which describes the status quo. This is about explaining what fish does and needs from a new language, not about something that fish wants to achieve by switching the language.
There is nothing specific in the rust port that makes fish more available for servers or LTS distros.
Being written in Rust does improve availability, because by default Rust statically links against everything except libc, and you can opt out of that if necessary. So there is inherently no need to build separate dependency packages for each distro, unless you use a Rust crate that specifically links to a C or C++ library.
Oh, right, yes; of course it statically links the standard library. I was thinking of the fact that the standard lib is precompiled, but yes, it’s statically linked.
fish links against pcre2, which is a C library (via the pcre2 crate).
(it used to also link against ncurses, now it uses the terminfo crate instead, which just reads the terminfo database in rust)
Of course there is a way to make fish distributable as almost a single file (https://github.com/fish-shell/fish-shell/pull/10367), which rust does make easier (rust-embed is frickin’ cool), but these sorts of shenanigans would also be possible with C++ and aren’t really a big driver of the rust port. It’s more that cargo install would try to install it like that and so why not make that work?
Really, my issue here is that the article makes “making fish available on servers” this huge deal when fish has always been available on servers?
The phrasing “available on servers” does seem quite weird. It does seem that having a single, standalone binary is much easier with Rust than with C++, though.
I think the point is that Rust will make it easier to distribute portable binaries. You can use Musl and then you get a completely static binary with no dependencies that works on old versions of Linux.
You can achieve the same with C++, but it’s waaaay more hassle.
There is the point you can make, which is that you can more easily create self-contained statically linked binaries (tho fish needs more than what cargo itself can provide here because it ships a ton of data files, see https://github.com/fish-shell/fish-shell/pull/10367),
and then there’s what this site keeps claiming from a misreading of a comment I made when the port just got started, which is that fish is now “available on servers”. Which is just wrong, it’s always been available on servers and it’s been easy to install a new fish on LTS distros for users for ages.
There is nothing specific in the rust port that makes fish more available for servers or LTS distros.
Before, you would have had to get a C++11 compiler (which used to be a bit of a PITA until 2020 or so), now you need to get rust 1.70 (which isn’t terrible given rustup exists).
I see they’re taking it from this comment, which says
Which is something that fish has always done - you can go to https://fishshell.com/ and get packages for Ubuntu, Debian, OpenSUSE and CentOS - all server distros, and these packages are built by the fish developers, not the distros.
That quote comes from the “Setting The Stage” section of the comment, which describes the status quo. This is about explaining what fish does and needs from a new language, not about something that fish wants to achieve by switching the language.
Being written in Rust does improve availability, because by default Rust statically links against everything except libc, and you can opt out of that if necessary. So there is inherently no need to build separate dependency packages for each distro, unless you use a Rust crate that specifically links to a C or C++ library.
It actually statically links the Rust standard library too. You can also avoid glibc by using musl with a one line change.
Oh, right, yes; of course it statically links the standard library. I was thinking of the fact that the standard lib is precompiled, but yes, it’s statically linked.
fish links against pcre2, which is a C library (via the pcre2 crate).
(it used to also link against ncurses, now it uses the terminfo crate instead, which just reads the terminfo database in rust)
Of course there is a way to make fish distributable as almost a single file (https://github.com/fish-shell/fish-shell/pull/10367), which rust does make easier (rust-embed is frickin’ cool), but these sorts of shenanigans would also be possible with C++ and aren’t really a big driver of the rust port. It’s more that
cargo installwould try to install it like that and so why not make that work?Really, my issue here is that the article makes “making fish available on servers” this huge deal when fish has always been available on servers?
The phrasing “available on servers” does seem quite weird. It does seem that having a single, standalone binary is much easier with Rust than with C++, though.
I think the point is that Rust will make it easier to distribute portable binaries. You can use Musl and then you get a completely static binary with no dependencies that works on old versions of Linux.
You can achieve the same with C++, but it’s waaaay more hassle.
There is the point you can make, which is that you can more easily create self-contained statically linked binaries (tho fish needs more than what cargo itself can provide here because it ships a ton of data files, see https://github.com/fish-shell/fish-shell/pull/10367),
and then there’s what this site keeps claiming from a misreading of a comment I made when the port just got started, which is that fish is now “available on servers”. Which is just wrong, it’s always been available on servers and it’s been easy to install a new fish on LTS distros for users for ages.
Yeah you’re right that comment doesn’t make any sense.