3 ms·

Direct questions, from a someone who knows that Rust has a lot to offer while also has experienced the pain of re-writes: 1. How do you propose to handle chang

by twp 4y ago

Direct questions, from a someone who knows that Rust has a lot to offer while also has experienced the pain of re-writes: 1. How do you propose to handle changes to fish while the re-write is in progress? Should fish/C++ stop evolving? See https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... 2. Wouldn't this be better handled by a fork of the fish codebase with a shared language specification and test suite?

ComputerGuru 4y ago
Thanks for the questions. They're the same ones I had when I was (separately) entertaining the same RIIR idea. 1. That's the primary concern I have right now. There's only so much bandwidth the team has to work on new features, bug fixes, and a rewrite port. Anything that requires cross-compilation-unit changes C++ side will probably be "that" much harder to do, or at least it'll add "that" much more friction to doing so. The pace of fish development isn't breakneck by any means, but it's still going to be something to keep in mind. The currently suggested module-by-module approach is a fairly good compromise (relying on FFI to bridge between the port and the original code), though it does mean that changing any "core" shared structure is going to have to be done twice (or three times, if you count C++ headers vs impls). If we elect to have a cpp-only 3.6.x around for some period of time receiving backports (maybe just completions, critical breakage, and security fixes?) that would of coures be yet another thing to keep in mind. I think this is probably going to be the most important question for the team to work out an answer to in the linked PR, with feedback from the community. 2. This is complicated by the fact that there really isn't much motivation to keep two versions of fish chugging along (possible cpp-only short-term branch excluded). The team is small, a greenfield rewrite of the project (rather than a port) is ill-advised due to the number of niche compatibility and quirk workarounds in fish core, and if you magically had a feature-parity rust port of fish available, I don't think anyone would really want to keep hacking away at the cpp version indefinitely. Fish never really saw great uptake as a scripting language (core fish devs are probably the only ones that have "fish scripts" tens of thousands of SLoC long) so it's just the "main interactive project" and the spec is "whatever the version of fish most used by our users currently does." It would probably be as much effort to define (other than via code and tests) "the fish spec" than it would be to rewrite or port it to rust in the first place. My greatest personal loss would be the nostalgia of running fish on systems that are truly from the 90s (as fish's once-serious now tongue-in-cheek slogan is "finally, a command line shell for the 90s"). But that might be a small price to pay for greater correctness, better maintainability, and more idiomatic code that's more welcoming to passing-by contributors.
- twp 4y ago
  Thank you for your thoughtful reply. A lot of people love fish and I actively support them [1]. [1] https://github.com/search?q=repo%3Atwpayne%2Fchezmoi%20fish&type=code https://github.com/search?q=repo%3Atwpayne%2Fchezmoi%20fish&...
  - ComputerGuru 4y ago
    Thanks for providing first-party fish integration/completions support! That takes commitment, especially since frameworks like clap just generate "static" completions that take zero advantage of fish's runtime introspection functionality.
  - pkulak 4y ago
    I just discovered Chezmoi last week. For years I thought I was fine manually symlinking into a repo. Boy was I wrong! Thank you for the wonderful project.
ridiculous_fish 4y ago
PR author here, these are two great questions. The Joel blog post which you referenced is excellent, and is a major influence on my thinking. Joel identifies "from scratch" rewrites as a major mistake. Don't throw away code! It convinced me. My proposal is a incremental translation of our C++ to Rust. Not throwing away code, but porting it: comments, warts, battle-scars, and all, incrementally on master. Any C++ changes concurrent with the port would either get merged first and then ported, or be translated to Rust. We use an FFI for interop. There is no long-lived branch which might fall behind. To your second question: fish-shell has a small all-volunteer set of devs, and we don't have the resources to actively develop both a C++ version and a Rust version. This would be all-in: we can do patches of past versions, but multiple implementations is not feasible.

by twp 4y ago

ComputerGuru 4y ago

Thanks for the questions. They're the same ones I had when I was (separately) entertaining the same RIIR idea. 1. That's the primary concern I have right now. There's only so much bandwidth the team has to work on new features, bug fixes, and a rewrite port. Anything that requires cross-compilation-unit changes C++ side will probably be "that" much harder to do, or at least it'll add "that" much more friction to doing so. The pace of fish development isn't breakneck by any means, but it's still going to be something to keep in mind. The currently suggested module-by-module approach is a fairly good compromise (relying on FFI to bridge between the port and the original code), though it does mean that changing any "core" shared structure is going to have to be done twice (or three times, if you count C++ headers vs impls). If we elect to have a cpp-only 3.6.x around for some period of time receiving backports (maybe just completions, critical breakage, and security fixes?) that would of coures be yet another thing to keep in mind. I think this is probably going to be the most important question for the team to work out an answer to in the linked PR, with feedback from the community. 2. This is complicated by the fact that there really isn't much motivation to keep two versions of fish chugging along (possible cpp-only short-term branch excluded). The team is small, a greenfield rewrite of the project (rather than a port) is ill-advised due to the number of niche compatibility and quirk workarounds in fish core, and if you magically had a feature-parity rust port of fish available, I don't think anyone would really want to keep hacking away at the cpp version indefinitely. Fish never really saw great uptake as a scripting language (core fish devs are probably the only ones that have "fish scripts" tens of thousands of SLoC long) so it's just the "main interactive project" and the spec is "whatever the version of fish most used by our users currently does." It would probably be as much effort to define (other than via code and tests) "the fish spec" than it would be to rewrite or port it to rust in the first place. My greatest personal loss would be the nostalgia of running fish on systems that are truly from the 90s (as fish's once-serious now tongue-in-cheek slogan is "finally, a command line shell for the 90s"). But that might be a small price to pay for greater correctness, better maintainability, and more idiomatic code that's more welcoming to passing-by contributors.

twp 4y ago
Thank you for your thoughtful reply. A lot of people love fish and I actively support them [1]. [1] https://github.com/search?q=repo%3Atwpayne%2Fchezmoi%20fish&type=code https://github.com/search?q=repo%3Atwpayne%2Fchezmoi%20fish&...
- ComputerGuru 4y ago
  Thanks for providing first-party fish integration/completions support! That takes commitment, especially since frameworks like clap just generate "static" completions that take zero advantage of fish's runtime introspection functionality.
- pkulak 4y ago
  I just discovered Chezmoi last week. For years I thought I was fine manually symlinking into a repo. Boy was I wrong! Thank you for the wonderful project.

ridiculous_fish 4y ago

PR author here, these are two great questions. The Joel blog post which you referenced is excellent, and is a major influence on my thinking. Joel identifies "from scratch" rewrites as a major mistake. Don't throw away code! It convinced me. My proposal is a incremental translation of our C++ to Rust. Not throwing away code, but porting it: comments, warts, battle-scars, and all, incrementally on master. Any C++ changes concurrent with the port would either get merged first and then ported, or be translated to Rust. We use an FFI for interop. There is no long-lived branch which might fall behind. To your second question: fish-shell has a small all-volunteer set of devs, and we don't have the resources to actively develop both a C++ version and a Rust version. This would be all-in: we can do patches of past versions, but multiple implementations is not feasible.