Woah... rewriting something that complicated in Rust is... impressive. That's thousands of lines of C++ being converted to Rust. I don't know where these people find the time (and money?), but I'm glad they exist. Hats off.
this post was submitted on 27 Nov 2023
69 points (100.0% liked)
Rust
6049 readers
64 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
Probably a hobby. When I was younger, I would help with stuff like this, but now I have kids and prefer to spend my limited time differently.
Hats off to them, at the very least it'll make for an awesome resume!
Just wondering: why was the rewrite necessary?
It doesn't look like they did it for performance, since they claim the code might actually be slower, at least for now.
Was there a particular reason that made Rust give a gain significant enough to deserve a full rewrite or was it just because the maintainers wanted to restructure things anyway and particularly liked Rust?
EDIT: Ok, found their reasoning after some digging.
It seems to be a combination of both things. They believe that switching will attract contributors and make it more modern... but also they seem to have had some trouble with thread safety in C++ that would have required them to do some restructuring anyway.
It seems to be a combination of both things. They believe that switching will attract contributors and make it more modern… but also they seem to have had some trouble with thread safety in C++ that would have required them to do some restructuring anyway.
It still feels like at best they are optimizing for the wrong metric and at worse they are just trying to rationalize an arbitrary choice.
I mean, the first reason they point out is "high probability of still being relevant in a decade." I mean, is Rust even a candidate in this domain? All leading programming languages have been around for longer than Rust and are actually specified in international standards, which ensures they will be around for essentially all eternity. Rust provides nothing of the sort. Is there anyone willing to put their hands in the fire for the expectation they will be able to build today's Rust projects a decade from now?
Also, Rust is renowned for having a steep and tough learning curve. Those are hardly the traits you seek to increase your potential userbase.
More importantly, threading stuff is limited to key architecture components that once in place are expected to change little to nothing. It's like picking .NET because you think it supports background processes well. Except the bulk of your code changes won't touch that, so what's the point?
Anyway, anyone is free to invest their time and effort in any venture without having to explain their motivations to anyone.
I agree with the sentiment. But I didn't want to be too critical about it, because like you said, it's their project and they don't have to give particularly strong reasons for what they choose to spend their time on.
And after all, this approach is probably fitting for a non-POSIX compliant shell like fish. I expect that those who would rather break compatibility in exchange for a "look & feel" that appears more "modern" are likely to also prefer breaking support for some old but stable tooling by switching to a more "modern" language ecosystem, even if doesn't have the battle-tested history and wide compatibility of more traditional languages. Those who care about that kind of stability might be better off using more traditional shells anyway. So maybe doing this would actually make working on fish more attractive for the kind of devs who would be more likely to contribute. We'll see.
are actually specified in international standards, which ensures they will be around for essentially all eternity
LOL
"All leading programming languages...are actually specified in international standards"? Here's an actual list: https://en.m.wikipedia.org/wiki/Category:Programming_languages_with_an_ISO_standard
Off the top of my head, here are some languages that aren't on there: Java, Python, Perl. Some languages that are on there but almost no one uses: ALGOL-60, CHILL (which appears to be extinct?), MUMPS, and Modula-2. Notably, there's a version of Lisp closely related to Common Lisp, but I've never actually heard of anyone using it.
Of the ones that are on there, most are not actually standards-driven the way C and C++ are, and even those each existed for over a decade and became widely used prior to standardization.
The current latest C# ECMA standard describes version 6.0; the current C# version is 12.0. The ISO spec is even further behind.
Standards don't determine language usage, popularity, or longevity.
I just checked and the first commit was almost 20 years ago now, the top contributor has been with the project ~10 years, the second top contributor has been contributing ~8 years, and there are several large contributors that have started making commits in the last 5 years.
I use this shell every day and it looks to be a very stable project. I just wish I knew how to donate to them.