4 ms·

This is exciting. I've not had problems with latency in fish, but the promise of rust is that there is so little latency that it heralds a close to the metal f

This is exciting. I've not had problems with latency in fish, but the promise of rust is that there is so little latency that it heralds a close to the metal feeling I've not seen in decades. I think that feeling is visceral and laudable, regardless of the actual runtime profile. It's under-appreciated in the design community. IPC latency is as big a problem in operating systems and programming languages as RPC latency is in cloud systems. I have no experience with rust, but I do depend on helix daily: https://github.com/helix-editor/helix https://github.com/helix-editor/helix and helix is rust. I think this kind of open source experiment is exactly what we should be encouraging because it's forward-looking and straightforward to test. I think the fish community could decide easily by A-B testing the Rust and C++ builds with real users and see how they compare in terms of reliability, performance, regressions, time-to-fix, and so on, assuming the team has the bandwidth to absorb the sideways nature of the work without derailing fish. To me, rust is more than trendy and I can remember the first time I touched Walter Bright's work decades ago, so I'm open-minded about D too. A simple KLOC or cyclomatic complexity as a proxy to abstraction would be an interesting lens.

zozbot234 4y ago
I think this rewrite is driven by the well-known safety challenges and long-term maintainability concerns with C/C++, not performance per se. Of course rewrites from existing high-level languages to Rust can result in huge performance gains.
- mlindner 4y ago
  That's different than what they say in their high level planning doc. https://github.com/ridiculousfish/fish-shell/blob/riir/doc_internal/fish-riir-plan.md https://github.com/ridiculousfish/fish-shell/blob/riir/doc_i... > Allowing background functions and concurrent functions has been a goal for many years. I have been nursing a long-lived branch which allows full threaded execution. But though the changes are small, I have been reluctant to propose them, because they will make reasoning about the shell internals too complex: it is difficult in C++ to check and enforce what crosses thread boundaries. > This is Rust's bread and butter: we will encode thread requirements into our types, making it explicit and compiler-checked, via Send and Sync. Rust will allow turning on concurrent mode in a safe way, with a manageable increase in complexity, finally enabling this feature.

zozbot234 4y ago

I think this rewrite is driven by the well-known safety challenges and long-term maintainability concerns with C/C++, not performance per se. Of course rewrites from existing high-level languages to Rust can result in huge performance gains.

mlindner 4y ago
That's different than what they say in their high level planning doc. https://github.com/ridiculousfish/fish-shell/blob/riir/doc_internal/fish-riir-plan.md https://github.com/ridiculousfish/fish-shell/blob/riir/doc_i... > Allowing background functions and concurrent functions has been a goal for many years. I have been nursing a long-lived branch which allows full threaded execution. But though the changes are small, I have been reluctant to propose them, because they will make reasoning about the shell internals too complex: it is difficult in C++ to check and enforce what crosses thread boundaries. > This is Rust's bread and butter: we will encode thread requirements into our types, making it explicit and compiler-checked, via Send and Sync. Rust will allow turning on concurrent mode in a safe way, with a manageable increase in complexity, finally enabling this feature.