The reader and input stack have been ported, which is basically everything. There's still some entry points in C++ (PR being reviewed) and test helper binary (might make a good external contribution as it's entirely self-contained), but almost all of the C++ is gone, and with it large chunks of the FFI.
Now we just have the second 90% to go - making sure this rewritten fish is portable and distributable!
Adding some actual non-HTTP-302 outputs to my browser search backend now that I'm #RIIR (Rewrite It In #Rust π) and wow, it has been /a whole fucking while/ since I have written raw HTML (no framework, no templates, no premade theme to hack up, etc).
Like, the last time I wrote an entire HTML tag from scratch, the "; charset=utf-8" part of one's Content-Type header wasβ¦not really a thing. As I found out by trying to be cute and putting an emoji in the title tag π
So, that's a significant jump - mostly thanks to the merge of the parser rewrite branch, described as "Herculean". The parser, autoloading module, completion module, function management, history management, and the builtins for complete, disown, eval, fg, history, jobs, read, set, and source have all been ported, as well as many other parts of the code.
This also allowed the removal of lots of supporting tools, including the UTF-8 modules, and quite a few bits of the FFI.
After a few months of slow progress this is a huge step forwards.
So, this is a good example of why the methodology of "C++ lines removed" is going to produce a janky impression. The wildcard module has been ported, adding ~1300 lines of Rust, but the C++ is still compiled as it's still partly in use.
The function module and its accompanying builtin have been ported. The string builtin PR edges ever closer to being merged (and currently removes nearly 3000 lines of C++).
How does the code-base continue working if you progressively replace C++ with Rust? Are you going class-by-class, module-by-module and have some inter-language communication? Or are these separate services? Is there more information about this process?
Some work on parallelising the tests. I've ported the cd builtin, and the hype is real - Rust's error messages really are good, and if it compiles it's most of the way to working. Already feel confident in Rust in a way I never did in C++.
γ Rust will invariably solve some issues in todayβs programming, including security-related trouble such as Heartbleed or the goto fail fiasco of 2014. But Rust will invariably introduce new issues, completely unforeseen as of now. And a new, modern programming language will appear in 2050 or 2060 solving those issues, and the rewrite cycle will begin all over again γ
I was (and still am) looking into various Rust build integration issues over the last weeks, specifically when integrating Rust code into existing C code bases.
Today I ran into one that is very easy to fix, and that e.g. shaves off half of the shared library size from librsvg.
Distros might want to do this explicitly in their builds for now.
Make sure to always pass --gc-sections (or equivalent) to the linker when linking a Rust staticlib into an executable or shared library. And in case of the latter, also make sure to only exports the symbols you want to export (librsvg did that part correctly).
Apparently this was also not mentioned anywhere in the Rust docs, and from looking around there seem to be more projects that are not aware of this. So I also added a section about this to the Rust docs (well, reference).
The threading and signal handling modules have been ported. These are both pretty tricky areas. Environment variable handling and the actual parser look like they're on the way.
Lots of Rust added, with various internals such as path and parser utils implemented. However, the C++ implementations are still in use so the progress bar hasn't moved much. The FFI is definitely the hardest bit of the port in my view.