One of the fish core devs here. You can ask me anything if you like. Happy to forward suggestions to the rest of the team. I've shared my opinions in the linked GitHub thread under the @mqudsi handle.
Not the person you asked, but I've never seen anyone claim this happens before. Yes there's plenty of people pushing things to be rewritten in Rust, but those always fall on deaf ears and don't really accomplish much. Rust rewrites are always from an activist insider, or sometimes the repository maintainer themselves, pushing for the rewrite, not from any external people not associated with the project.
It would be highly surprising to me if any external commentator pushing for a Rust rewrite has ever succeeded in convincing the maintainers to do so. That's just not how open source works.
Here's what he said way back in August of 2016, just barely over a year after Rust hit 1.0 in May of 2015. https://www.infoworld.com/article/3109150/linux-at-25-linus-...
> Q: What do you think of the projects currently underway to develop OS kernels in languages like Rust (touted for having built-in safeties that C does not)?
> Linus Torvalds: That's not a new phenomenon at all. We've had the system people who used Modula-2 or Ada, and I have to say Rust looks a lot better than either of those two disasters.
> I'm not convinced about Rust for an OS kernel (there's a lot more to system programming than the kernel, though), but at the same time there is no question that C has a lot of limitations.
The enthusiasm of the person asking the question was evident.
What was trickier to handle was their insistence that "X would be better if written in Rust" without really understanding what makes X successful.
This was further compounded a bunch of copycat projects written in Rust with very limited functionality. Their project's marketing said that "it's written in Rust!" was their primary advantage.
Fundamentally, users don't care, or even know, which language your software is written in. All they care about is whether your software solves their problem.
To answer your direct question: I got multiple "you should use Rust!" comments. I smiled, said thank you I know that Rust is the right choice for certain problems. I then asked "How would Rust help here?" and listened.
When Rust is the right language for the problem, I'll re-write. Until then, I'll be polite and listen.
You could probably solve the things I just talked about with Go or some other new compiled language but the community has settled on Rust and Rust has great features right now that are working, so my thinking when I see something written in Rust is usually relief.
I don’t really hate Rust and like what it has done for safety, but it hasn’t really been used widely enough to see what happens if “the masses” start to use it.
Where other languages say "you're just a bad programmer and you should feel bad", Rust makes it its own problem, and focuses on preventing such mistakes instead. Rust's infamous learning curve is from enforcing a ton of requirements that ultimately make more robust programs. You have to handle errors. You have to lock mutexes. You have limits on mutability and global state. You have to think about data flow, and can't just make a program that is a web of everything referencing everything else.
Rust is not that new. The masses are already using it. I've worked with Rust noobs, and I've seen "Enterprise Rust". Bad Rust code is still not that terrible. The language limits how much damage noobs can can cause. There's tooling to help with unidiomatic code. Heavy use of dependencies and strictness of Rust's interfaces means noobs can write simple glue code on top of someone else's robust code.
However, for many problems, the sweet spot of a good-enough static type system and garbage collector - effectively a better Python - is a better fit.
This article explains things well, IMHO: https://mdwdotla.medium.com/using-rust-at-a-startup-a-cautio...
I think certain team members have individually gravitated towards rust over the years, probably each for reasons of their own. Peter is the driving force behind this commit (I don't think anyone else would have ventured to open this PR and would probably have launched a rust fork as a side project instead) and I've been seeing him publicly state his evolving opinion on rust over the years. He's thorough and methodical and certainly not prone to seismically shaking up the codebase on a whim or because of a RIIR comment made in passing; I think it probably just reached the point a lot of others that maintain other projects have reached in the past, where the appeal of porting it to a (hopefully better) language reaches a tipping juncture that makes it worth entertaining.
Personally, every time I delve deep within the internals of fish's legacy codebase I just come away increasingly frustrated with how much of what I'm doing is battling the language or working around its warts rather than working on what I really want to be doing. We've spent too many man hours to count porting concepts like Option<T> and friends over to take advantage of the hygiene and correctness they lend to codebases. I most recently spent forever working out a CoW string, then didn't have it in me to actually merge the branch because of how much churn it would probably entail.
But back to your question - I feel like most "why don't you rewrite it in rust" questions can generally be dismissed almost entirely out of hand because they're made in passing by people with no stake in the project who have no idea what that would entail, what it would look like, and at what cost it would come. The only people I ever spoke to seriously about that were other core maintainers, and there are very few outside that pool whose opinion I would personally attribute any weight to on a question like that.
1. How do you propose to handle changes to fish while the re-write is in progress? Should fish/C++ stop evolving? See https://www.joelonsoftware.com/2000/04/06/things-you-should-...
2. Wouldn't this be better handled by a fork of the fish codebase with a shared language specification and test suite?
1. That's the primary concern I have right now. There's only so much bandwidth the team has to work on new features, bug fixes, and a rewrite port. Anything that requires cross-compilation-unit changes C++ side will probably be "that" much harder to do, or at least it'll add "that" much more friction to doing so. The pace of fish development isn't breakneck by any means, but it's still going to be something to keep in mind.
The currently suggested module-by-module approach is a fairly good compromise (relying on FFI to bridge between the port and the original code), though it does mean that changing any "core" shared structure is going to have to be done twice (or three times, if you count C++ headers vs impls). If we elect to have a cpp-only 3.6.x around for some period of time receiving backports (maybe just completions, critical breakage, and security fixes?) that would of coures be yet another thing to keep in mind.
I think this is probably going to be the most important question for the team to work out an answer to in the linked PR, with feedback from the community.
2. This is complicated by the fact that there really isn't much motivation to keep two versions of fish chugging along (possible cpp-only short-term branch excluded). The team is small, a greenfield rewrite of the project (rather than a port) is ill-advised due to the number of niche compatibility and quirk workarounds in fish core, and if you magically had a feature-parity rust port of fish available, I don't think anyone would really want to keep hacking away at the cpp version indefinitely. Fish never really saw great uptake as a scripting language (core fish devs are probably the only ones that have "fish scripts" tens of thousands of SLoC long) so it's just the "main interactive project" and the spec is "whatever the version of fish most used by our users currently does." It would probably be as much effort to define (other than via code and tests) "the fish spec" than it would be to rewrite or port it to rust in the first place.
My greatest personal loss would be the nostalgia of running fish on systems that are truly from the 90s (as fish's once-serious now tongue-in-cheek slogan is "finally, a command line shell for the 90s"). But that might be a small price to pay for greater correctness, better maintainability, and more idiomatic code that's more welcoming to passing-by contributors.
[1] https://github.com/search?q=repo%3Atwpayne%2Fchezmoi%20fish&...
The Joel blog post which you referenced is excellent, and is a major influence on my thinking. Joel identifies "from scratch" rewrites as a major mistake. Don't throw away code! It convinced me.
My proposal is a incremental translation of our C++ to Rust. Not throwing away code, but porting it: comments, warts, battle-scars, and all, incrementally on master. Any C++ changes concurrent with the port would either get merged first and then ported, or be translated to Rust. We use an FFI for interop. There is no long-lived branch which might fall behind.
To your second question: fish-shell has a small all-volunteer set of devs, and we don't have the resources to actively develop both a C++ version and a Rust version. This would be all-in: we can do patches of past versions, but multiple implementations is not feasible.