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.

[–] lysdexic@programming.dev -1 points 11 months ago (3 children)

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.

[–] Ferk@kbin.social 3 points 11 months ago* (last edited 11 months ago)

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.

[–] BB_C@programming.dev 3 points 11 months ago

are actually specified in international standards, which ensures they will be around for essentially all eternity

LOL

[–] BatmanAoD@programming.dev 2 points 11 months ago

"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.