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