fish pauses development builds during its Rust transition
A partially translated shell has different performance and build costs from a finished port. fish's May update separates migration progress from release readiness.
Passing tests during an implementation port does not make the intermediate program a useful release. The mixed-language version can preserve behavior while imposing build costs and runtime overhead that disappear only after more code moves. In the May 27 fish release update, committer David Adam explains that development builds are paused while the C++ core moves to Rust. The partially rewritten program performs worse and is more complicated to build.
The update reports removal of about 20 percent of the C++ code over the preceding months, with an explicit qualification that this is the author's measurement. It also estimates that beta testing will not be appropriate until late 2023 at the earliest. Those statements describe progress and readiness separately. Code removed is evidence of translation work, while release suitability depends on the resulting program.
I value fish's interactive behavior without requiring a large configuration project. That makes the distinction between a development snapshot and a usable shell particularly important. An intermediate build that imposes migration costs on its users needs a clear purpose beyond being newer than the stable release.
The migration keeps two implementations in one program
The original port plan calls for an incremental translation on the main development branch. C++ and Rust coexist while components move. The build similarly retains CMake while Cargo builds the Rust portion. Replacing the build system follows translation of the C++ implementation.
That sequence lets contributors integrate work in smaller changes. It also produces a transitional program that needs both toolchains and a foreign-function interface between them. Keeping continuous integration passing establishes that the tested behavior still works at each stage. It does not remove those extra build requirements or prove that the intermediate performance is suitable for general users.
The plan anticipated this cost. It lists a prolonged period of complicated builds among the risks and accepts temporary inefficiencies such as extra string copies at the language boundary. Those copies can be reasonable engineering choices when the boundary is intended to disappear. The May report says the resulting development program is currently worse to run and build, which is consistent with that planned transition cost.
This is a useful distinction when evaluating a migration. The final architecture can eliminate a conversion that the intermediate architecture requires. Performance of the intermediate program therefore cannot establish the final result in either direction. It is nevertheless the performance that a development-build user would experience today.
Removing code is an incomplete progress measure
The reported 20 percent concerns removed C++ code. It is not a claim that 20 percent of user-visible behavior has changed or that 20 percent of the remaining engineering effort is complete. The original plan says the work starts with components such as builtins and moves toward the core. Different components have different dependencies and review requirements.
A short module with many callers may be harder to translate than a longer isolated component. Some utility code can temporarily exist on both sides of the boundary, while major components should use one implementation through interop. Line removal can therefore occur at a different rate from elimination of the boundary itself.
These are implications of the documented strategy, not alternative measurements supplied by the project. Adam's update presents its estimate with an appropriate qualification. Treating it as a precise completion percentage would discard that qualification and imply a schedule the source does not establish.
The beta estimate is similarly an estimate. Adam names late 2023 as the earliest plausible beta period and gives no firm release date. The original plan had already described its schedule as uncertain. Neither statement supplies a basis for claiming that a finished Rust implementation is available or that beta readiness will arrive on a particular day.
Build integration serves contributors during the transition
The development guide from the initial merge describes a Rust static library linked with the C++ library. Corrosion invokes Cargo from CMake, while cxx and autocxx provide interop. Running Cargo alone builds the Rust library after CMake has generated configuration, not a complete standalone shell.
That structure supports contributors who need to translate and inspect a particular module. The guide describes opening the Rust crate in development tooling after the configuration step. A useful local iteration path for a contributor does not necessarily imply a straightforward binary distribution path for every platform.
The interop tools also have fish-specific adaptations for wide strings and pointer handling. The plan intends to remove those temporary dependencies when the implementation no longer needs C++ communication. Until then, the build has to assemble the program as it exists, including the compatibility arrangements required by both languages.
Pausing generated development builds reduces distribution of that temporary complexity. The update does not say development itself is paused. Translation continues, and the source remains a place for contributors to work. What stops is the routine production of development binaries whose costs currently outweigh their usefulness to general testers.
Concurrency remains an architectural objective
The May update repeats concurrent execution of fish functions as a motivation for the Rust work. The original plan explains the intended mechanism through compiler-checked thread requirements using Rust's Send and Sync. This is a reason to undertake the port, not a feature the progress report says users can enable today.
I find that motivation more informative than a language preference by itself. The project wants its implementation to express requirements that make a previously difficult execution model manageable. A successful translation still has to precede the architecture work that depends on it, and the release update keeps the current delivery status explicit.
Stable maintenance remains a separate possibility. Adam notes a small collection of fixes that may justify a 3.6.2 release but gives no timeline. That leaves room for maintenance of the existing series without presenting the partially translated development tree as ready for general release. As of this update, the supported information is that the port is progressing, development binaries are paused, and beta readiness remains months away by the maintainer's estimate.