Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fish 4.0: The Fish of Theseus

fishshell.com

Post reply on HN
Print view View original

131–140 of 204 posts

Re: Fish 4.0: The Fish of Theseus

#131

Post by hylaride »

coffeeindex wrote: post #66
oguz-ismail wrote: post #64

Earlier quoted context omitted.

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.

Re: Fish 4.0: The Fish of Theseus

#133

Post by chubot »

boris wrote: post #81
chubot wrote: post #8

Congrats to the fish team! Great writeup with lots of interesting detail. I wonder if this is the biggest project that has moved from C++ entirely to Rust (or maybe even C to Rust?) It probably has useful lessons for other projects. If I'm reading this right, it looks like fish was not released as a hybrid C++ / Rust program, with the autocxx-generated bindings. There was a release during that time, but it says "fish…

> Feature Detection Is Better than Version Detection The problem with feature detection (normally referred to as configuration probing), at least the way it's done in ./configure and similar, is that it relies on compiling and potentially linking (and sometimes even running, which doesn't work when cross-compiling) of a test program and then assuming that if compilation/linking fails, then the feature is not availabl…

Hm what's an example of those invalid C constructs? I'd be interested in seeing what happened

One answer is the __has_feature tests mentioned in a sibling comment. Then you are using a supported API, not arbitrary code. Browsers should probably support something like that, if they don't already.

But the arbitrary code is still a useful fallback, for when the platform itself doesn't support config probing

I think you're saying that "writing good ./configure is hard", which is absolutely true. But it's still true that feature detection is better than version detection.

Re: Fish 4.0: The Fish of Theseus

#134

Post by giancarlostoro »

scop wrote: post #11

I remember switching from bash to zsh a few years back and thinking I was the bees knees. After the switch trying other shells seemed like bike-shedding because, I mean, what more could a shell? Then I got a new computer and decided to start from scratch with my tooling and downloaded fish. I was shocked how it instantly made zsh feel cumbersome and ancient . Heartily recommend others give it a try as a daily driver…

My only issue with Fish is when pasting things from the web that assume Bash, a lot of the time it just works, then now and then I get screwed. I don't know nearly enough Fish or Bash to switch. Still though, I prefer Fish ultimately.

Re: Fish 4.0: The Fish of Theseus

#135

Post by ComputerGuru »

boris wrote: post #81
chubot wrote: post #8

Congrats to the fish team! Great writeup with lots of interesting detail. I wonder if this is the biggest project that has moved from C++ entirely to Rust (or maybe even C to Rust?) It probably has useful lessons for other projects. If I'm reading this right, it looks like fish was not released as a hybrid C++ / Rust program, with the autocxx-generated bindings. There was a release during that time, but it says "fish…

> Feature Detection Is Better than Version Detection The problem with feature detection (normally referred to as configuration probing), at least the way it's done in ./configure and similar, is that it relies on compiling and potentially linking (and sometimes even running, which doesn't work when cross-compiling) of a test program and then assuming that if compilation/linking fails, then the feature is not availabl…

IMHO a broken toolchain is a broken toolchain and that's kind of outside the scope of autoconf -- and I say this despite having banged my head against the wall only too many times as a result of an odd toolchain misconfiguration leading me into chasing autoconf gremlins.

One thing about rust is that it has always treated cross-compiling as a first-class citizen. Cargo is very intentional about the difference between the HOST and TARGET triplets and you can't mix them up unless you are doing so intentionally.

The rsconf feature detection crate was similarly designed with cross-compilation in mind from the start and eschews running binaries in favor of some clever hacks to exfiltrate values during the cross-compilation process.

There is only one rsconf feature (retrieving compile-time constants) that is currently labeled caveat emptor as it does not support cross-compilation; perhaps I can nerdsnipe someone here into figuring out a workaround: https://github.com/mqudsi/rsconf/issues/3

Re: Fish 4.0: The Fish of Theseus

#136

Post by thayne »

_zagj wrote: post #107
thayne wrote: post #55

Earlier quoted context omitted.

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 wi…

> 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.

> 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++.

Re: Fish 4.0: The Fish of Theseus

#137

Post by ComputerGuru »

runiq wrote: post #112
underdeserver wrote: post #73

The tone in the "The Timeline" section seems apologetic: > The initial PR had a timeline of “handwaving, half a year”. It was clear to all of us that it might very well be entirely off, and we’re not disappointed that it was. I'm amazed that you estimated it at so little time originally, and I'm amazed you shipped it in full in just 2 years. Congrats!

Absolutely. Staying within an order of magnitude for a project of this size is just really good eyeballing. :)

It's actually not fair to judge this one way or the other at the two year mark.

We technically removed the last C++ code from the core project in January 2024 (~a year ago), the last C++ code altogether (a test helper) in June 2024 (six months ago). We only decided to push out a release now because we've added enough new features (not counting the rewrite as a feature) to warrant a release.

But at the same time, someone could argue that the current codebase is still far from being fully idiomatic rust, there are various C++-isms ranging from the use of UTF-32 (historical from the nature of std::wchar/std::wstring under *nix) to still passing around file descriptors rather than rust `File` objects (that will take a lot of rearchitecting to make mut-safe).

Ultimately, a project is never "done" and we're not being paid at all let alone contingent upon completion of the port, so there's no real use in saying it took precisely this long or that long. We're releasing now because we want to, but I wouldn't tie the release cadence with the port timespan.

Re: Fish 4.0: The Fish of Theseus

#138

Post by ComputerGuru »

nindalf wrote: post #105
outlore wrote: post #86

I am curious to ask others here, are there other low-config alternative tools like Fish that, looking back, now seem like a no brainer? Ghostty is a recent example, Helix seems like another. I’d love to know about other tools people are using that have improved or simplified their lives.

Agree with you on helix. I love it. Atuin for improved history search. Starship for an improved shell prompt. zoxide - better cd ripgrep - better grep just - a command runner. I put project specific commands/scripts in there so I don’t have to remember. All of these are indispensable for me.

imho starship is really just eye candy for the shell; it's not necessarily an actually improved shell prompt if you're on a "modern" shell like fish (a shell for the '90s!) or if you've put effort into customizing your shell experience with any of the other shells.

Re: Fish 4.0: The Fish of Theseus

#139

Post by anthk »

nindalf wrote: post #105
outlore wrote: post #86

I am curious to ask others here, are there other low-config alternative tools like Fish that, looking back, now seem like a no brainer? Ghostty is a recent example, Helix seems like another. I’d love to know about other tools people are using that have improved or simplified their lives.

Agree with you on helix. I love it. Atuin for improved history search. Starship for an improved shell prompt. zoxide - better cd ripgrep - better grep just - a command runner. I put project specific commands/scripts in there so I don’t have to remember. All of these are indispensable for me.

CD is builtin, there's no better cd.

Re: Fish 4.0: The Fish of Theseus

#140

Post by ComputerGuru »

djoldman wrote: post #117

> 57K Lines of C++ to 75K Lines of Rust ... > A lot of the increase in line count can be explained by rustfmt’s formatting, as it likes to spread code out over multiple lines, like: ... I wonder what the character count diff is?

So the problem with character counts is that unless you put in an insane amount of effort to calculate it, you're not going to get "significant chars" but rather "bytes"

That said, you asked so here's the result of the difference within the `src/` directories comparing 3.7.1 and 4.0 beta (so excluding docs, fish scripts, etc):

    > cd fish3/src; find . -type f -exec cat {} + | tr -d '[:space:]' | wc -c
    2172330

    > cd fish-shell/src; find . -type f -exec cat {} + | tr -d '[:space:]' | wc -c
    2207996
That's an increase of 35,666 bytes, or just 1.6%

If you don't exclude whitespace, the difference is just under +250k bytes (an 8% increase).

Post reply on HN