Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
This comment from the core team spells it out: https://github.com/fish-shell/fish-shell/pull/9512#issuecomm...
> C++ is an old standardized language with multiple implementations, married at the hip to C, an even older even more standardizederer language. Any changes take ages to get to users so we can actually use it. We moved to C++11 in 2016 (some quick calculation shows that's 5 years after the standard was released), and we're still on C++11 because the pain of upgrading is larger than the promises of C++14/17. We needed to backport compilers for our packages until, I believe, 2020.
> Having multiple implementations means you always hit the worst of any of them, because you can't dictate which implementation your users use. So we have to deal a lot more with cmake than we would like, sometimes for things as awkward as "which header is this function in".
This is exciting.
I've not had problems with latency in fish, but the promise of rust is that there is so little latency that it heralds a close to the metal feeling I've not seen in decades.
I think that feeling is visceral and laudable, regardless of the actual runtime profile. It's under-appreciated in the design community. IPC latency is as big a problem in operating systems and programming languages as RPC latency is in cloud systems.
I have no experience with rust, but I do depend on helix daily:
https://github.com/helix-editor/helix
and helix is rust.
I think this kind of open source experiment is exactly what we should be encouraging because it's forward-looking and straightforward to test.
I think the fish community could decide easily by A-B testing the Rust and C++ builds with real users and see how they compare in terms of reliability, performance, regressions, time-to-fix, and so on, assuming the team has the bandwidth to absorb the sideways nature of the work without derailing fish.
To me, rust is more than trendy and I can remember the first time I touched Walter Bright's work decades ago, so I'm open-minded about D too. A simple KLOC or cyclomatic complexity as a proxy to abstraction would be an interesting lens.
https://madnight.github.io/githut/#/pull_requests/2022/4
This can show you certain data. I’ve linked to Q4 2022, specifically PRs opened. You can see C++ at #4 with 9.7% of PRs, and Rust at 14 with 1.6%.
Rust users are also going to be biased towards GitHub over other places.
Early on, Rust’s goal was to improve Firefox, a large C++ codebase. A bunch of language design decisions were made to ensure this could work well.
However, that doesn’t mean it’s always super easy. C++ interoperated with C even more easily: just compile your code with the new compiler! With Rust, it’s more like FFI.
https://cxx.rs/ is at the forefront here.
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.
[1] https://github.com/twpayne/chezmoi
One of the founders of Heroku actually had a short-lived effort to build a Ruby-based shell called Rush https://github.com/adamwiggins/rush
That's because Qt 6 wholeheartedly converted to CMake for you. (At least it is better than qmake.) In order to support this Qt has this large battery of CMake files [1]. Qt is of course a clear outlier, but you can't expect the same level of support from every other library you want. My points about "anything exotic" still stand.
[1] https://github.com/qt/qtbase/tree/dev/cmake
Let's make it a bit more concrete with an actual example of submitted code.
Here's a recent patch I wrote "Improve E0308: suggest user meant to use byte literal, w/ tests and fix" which adds a suggestion for Rust's diagnostic when you write for example '*' the literal char, Unicode U+002A but it needed a single byte and that's not what a char is. My code suggests adding the prefix b, so writing b'*' here, meaning the ASCII code for that symbol 0x2A which is a single byte ::
https://github.com/tialaramex/rust/commit/130d02b62e65c5f2a4...
I wrote that code but I don't understand the internals of how self.tcx.sess().source_map().span_to_snippet(span) works. Not my problem, we're in the diagnostics code so even if this is perhaps slightly slower than optimal it doesn't matter because a human will need to read this output and act on it - E0308 is a type mismatch, the program does not compile as written.
Does my reviewer know? Maybe, I didn't ask them, but they don't really need to, it's clearly fine here to call this stuff, there won't be a nasty surprise "Oh, make sure you restore the FQ5 when setting Z due to calling sess() in this code" because that's not how Rust works whereas in a language like C++ of course such traps may exist.
Now there is some risk I made a logic mistake, but, I wrote tests for this of course, unlike with subtle memory safety bugs, logic bugs are often caught by proper testing. My tests her are somewhat superficial, I check 'X' and '#' which should both cause the suggestion, and I check '€' which should not, but I think they cover the cases the compiler will really see here.