Piscibus Oxidate

Most Linux users use something like Bash or Zsh to interact with the command line. There's another choice out there that some people rave about, mostly due to it's many built-in convenience and usability features. We are talking about fish. Fish was written in C++, and was arguably software that was fully production ready. It was of course still being worked on actively, but for all intents and purposes this is finished software that is available in stable versions for every linux distro under the sun.

And then the project initiator proposed to Rewrite It In Rust, except he wasn't joking at all.

And now, a year later, fish is completely implemented in Rust. This is not a release version yet, but you can get it from github. I tried installing it from source and all I had to do was run this command:

cargo install --git https://github.com/fish-shell/fish-shell

That's it. You may want to install python-sphinx for the documentation first (and of course Rust Up your machine), but that's all she wrote. I then proceeded to install Tide for some fancier prompts. Tide has not been updated to work with the Rust-version of Fish, yet it all worked just fine.

So why would anyone do this? After all, while fish has gotten bugfixes and a few small features as part of the port effort, it's still the same shell. Over a year was spent simply switching from one language to another. Had this been a switch from C++ to Go for example, I would agree. However, the project initiator was very clear about the objectives:

1. Nobody really likes C++ or CMake, and there's no clear path for getting off old toolchains. Every year the pain will get worse.
2. C++ is becoming a legacy language and finding contributors in the future will become difficult, while Rust has an active and growing community.
3. Rust is what we need to turn on concurrent function execution.
4. Being written in Rust will help fish continue to be perceived as modern and relevant.

Now item 3 is something I don't really agree with, since there's no technical reason for such a limitation in C++. But perhaps it is simply a matter of lava flow providing friction for such an implementation. And item 4 is also not something I want to get into here.

But let's look at the others:

1. Yes. So much yes. If I clone a repo, I want to run a build command and get a binary. Not have to compile a build file in order to compile sourcecode. Or do things like mkdir build;cd build;cmake ... And don't get me started on just how brittle most C++ build chains are. Unless a project is actively maintained, there's a high chance it simply will not compile anymore. Code corrodes into warnings, warnings turn into errors. That's just the nature of the (C++) beast.

2. Maybe it's a bit early to announce the death of the C++ developer, but for sure the sheer velocity difference is staggering. Add to that the fact that Rust devs are usually more productive because of the modern toolset and libraries. But there's another factor: Most developers, once introduced to Rust, don't go back. This is the main reason why outsides perceive it as a cult.

"I've known Bob as a java developer for 20 years, now all he talks about is Rust"

Yeah Bob isn't gonna ./mvnw spring-boot:run anymore. No more going to Spring Initializr to generate a zip file with a dozen files just to get a barebones hello world application going. Bob's gone. I am not even making this up, this is what I see happening both in the open source world and at work. My team has completely transitioned to Rust. Whenever a major issue pops up in some component or service, usually the first step is to rewrite it in Rust. We even have Go code that we want to port to Rust because we encountered multiple non-obvious issues during runtime that simply would not have compiled in Rust.

This is not to say that we don't make mistakes in Rust. Just recently we had an issue with surveillance data (as in aircraft position information) being buffered, and old data being distributed. There is nothing Rust could do to prevent that since it may well be desired behavior in other areas. But even looking at someone else's code and doing root cause analysis was much easier in Rust.

While the Fish project has spent a year learning Rust, then porting their code to Rust (and from what I can see, they did a banger of a job too!), I do believe they will save a lot of time down the road. And as a nice side effect, they will reap all of the security benefits that come with a memory safe language with none of the perfomance hit you'd incur with runtime memory bandaids in C++.