One of the common refrains is that the Rust community pushes people into doing these sorts of things. How many “you should rewrite it in Rust?!?!!” messages have you all received in the years? If you got any, how did they weigh in on this decision?
Hey, Steve. We've received a few, but not as many as you might think (at least relative to fish's popularity). I can't speak for @ridiculousfish but I would say such comments probably had close to zero impact on (t)his decision.
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.
For one of my projects [1] I got about ten in-person questions/discussions equivalent to "Why don't you use Rust?" at various conferences/meetups over three years.
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.
So as someone that potentially would ask you that, here's my thinking. Rust programs are (in my experience) always fast, less buggy (I'm sure you'll immediately scoff at that, but compared to the number of runtime errors I get in JS programs vs Rust I think it's significant), and they don't require massive dependency chains like Python and JS programs.
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.
Is that because of the language itself, or because people who develop in Rust right now tend to really like programming, and are likely above-average developers?
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.
It is Rust itself. My Rust programs are less buggy than my C and JS programs, and I'm not smarter when writing Rust. In fact, I'm much lazier.
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.
Rust is fantastic for writing robust, secure, high-performance software. Rust is definitely a much, much better C++ in almost every respect. No doubt there.
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.
someone posted a thorough benchmark on both compile and run times of rust vs C++ recently. c++ won on almost every test, so it's not as fast as rust people tend to spread.
> One of the common refrains is that the Rust community pushes people into doing these sorts of things.
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.
Anecdotally I've seen plenty of people talk about the Rust-in-Linux endeavor like it was a gang of door-to-door missionaries that banged on old man Torvalds' door until he begrudgingly let them come in for a cup of coffee. I don't think people make a big distinction between "activist insiders" and "activist outsiders" in this context.
I'm not a part of the endeavor and only have looked in from the outside by reading some of the mailing list archives but it never looked to me like it was a result of what you describe. Torvalds was welcoming from the get go, even name dropping Rust years before the Rust-in-Linux endeavor even started (which likely helped prompt the endeavor in the first place).
> 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.
