The funniest thing in that thread is the person who jumped in to say that they don't know much about fish, but think the project should seriously consider abandoning the work they've done on Rust to date and instead consider D.
As well as the guy who just commented that they should use Zig instead as it's a "1-to-1 alternative to C" despite the fact that fish was written in C++.
"Rush" sounds like a special kind of amphetamine that you take right before going on 32 hour "deep dive" for purposes of corporate espionage, in a 1980s cyberpunk setting where your best friend is a lady with laser-deflecting mirrored eyes and razor-embedded fingernails
In other words, it sounds like the Good Stuff (tm)
I’m pretty sure back in the late 2000s there was a liquid vial called “Rush” you could buy from headshops here in Aus that had 4-methylmethcathinone in them, before “meow meow” (no one called it that) became well known.
Rush is the most popular brand of poppers. Maybe you're thinking of those? It's a liquid in a vial, but nothing like MDMA, and definitely older than the 2000s. If not, and there was another drug called Rush sold in a vial, I'll bet that it's caused some unfortunate mix-ups.
No no they're talking about RCs. There used to be a shitton of shady products containing some random chemical(s) like synthetic cannabinoids or cathinones, often claiming to be just herbal blends or safe and legal alternatives to the real stuff. So it's absolutey possible you could buy a packet of MDPV and it said Rush on the packaging - just some random branding that would likely change
Haha nah not poppers but they also sold those. Just not the more commonly known brand names. These were sold as “legal” highs openly here despite actually being illegal! There were a few different names but it was all the same thing, 4-MMC in liquid form to drink.
Also had London Underground Doves which were 4-MMC capsules as well.
Nonsense, I have a wide variety of musical appreciation, spanning a wide gamut from Justin Bieber to Nickelback. When I’m feeling adventurous I’ll dare to experiment with deep cuts from the early years of recorded music, like Maroon 5 or Aqua.
(Seriously though, Rush is music I can enjoy, though more a fan of Pink Floyd and Steven Wilson.)
…and you kinda need to have the chops of Steve Howe, Rick Wakeman or Chris Squire to perform in it. But ultimately Yes evolved (well, devolved) into making approachable, crowd-pleasing pop music in the 80s.
C++ has arguably gotten more technical, complex and ambitious as time has gone on, and let’s face it, it is a lot darker than Yes. So King Crimson would have to be my vote for C++’ prog-rock spirit band.
> C++ is becoming a legacy language and finding contributors in the future will become difficult,
This is wild to see written down. Am I alone in feeling like there is a huge disconnect between what people online say and what happens I guess in the real world?
Developers I actually talk to never seem to have these kinds of opinions about c++ and alot more reserved about using rust
I think that C++'s build system difficulties are _huge contributors_ to people not feeling like C++ is "worth learning".
People do the C/Rust comparison, but at least C has a simpler mental model so is a different thing. I feel like C++ has similar, if not more, complexity to Rust and is harder to onboard.
I do think there are domains where "let's use Rust" are a bit ... aspirational more than anything (anything related to graphics or OS integration...). And there C++ makes a lot of sense. But I think that day by day the number of projects where C++ is the only obvious choice goes down. Hell, it's been going down since Java!
People always assume people who like Rust and are a bit more hesitant about C++ are just hype driven haters. I'm mostly exposed to C++ through my hobbies in creative coding, graphics programming, etc., and I would like to be a better C++ developer and be more comfortable with those projects. But every time I have to set up a new project it feels like death by a thousand cuts, and the fun art project I was about to work on just becomes a painful chore. I never, ever feel this way with Rust, even though it's significantly more immature in this space.
Maybe I'm just one of those spoiled younger developers who expects great DX on all my tools, but it makes me really reluctant to invest more time into learning C++ when I could be contributing to open source Rust and improving the ecosystem. Getting better with C++ just feels like learning an endless series of sharp edges.
This was something that Microsoft did really well back in the Visual Studio days. That said Rust really raised the bar not just on tooling but the whole end-to-end experience and with cross-platform being table stakes now it really makes for a compelling choice.
Well, it is no surprise given their C++ investment, that Microsoft keeps briging more Rust like experience into Visual C++ then.
They are adopting Rust in some small spots like Azure Sphere, and Rust/WinRT, yet WinDev, XBox, Office, .NET (for the runtime), DirectX aren't getting rid of their C++ code anytime soon.
Rust experience is compeling if one doesn't need to rewrite the world, e.g. doing CUDA in C++ versus Rust.
Seconded. I can have fun using Rust, I can't have fun using C++, so Rust is what I've spent the past ~4 years getting more and more familiar with. Now I'm at a point where I could apply to Rust jobs, but certainly not C++ jobs
Considering this is a volunteer driven open source project with a high "for the heck of it" factor (Wikipefia: "Fish is considered an exotic shell since it does not rigorously adhere to POSIX shell standards"), I don't think the having fun argument is quite as bad as all the serious people say.
Yeah, but I was also making a further point: if everyone uses the enjoyable language in their spare time, and nobody wants to use the miserable one unless they have to, you get a gradual brain-drain. More and more people have more and more experience with the fun one, and over time it gets easier to hire for (or find contributors for)
Of course it's sticky- someone who's already an expert in the miserable language may not choose to totally re-skill themselves (and anyway, once you know something that well it tends to become less miserable). But the new generations will heavily favor the thing that's welcoming to them, not the thing that's prickly
You completely ignored dependencies, which in my experience everyone seems to handle differently (and definitely not in a declarative way).
Differently put: a phrase "metabuild system" has both a lexical sense and an idealized sense. The lexical sense would be something that generates an input to build systems. The idealized sense would be something that does everything else not possible or difficult in build systems. CMake was definitely far from that ideal [1]; it was often simpler to make a configure script in your favorite language (and, for god's sake, not in M4) than using CMake.
[1] Was using a present tense but edited after realizing that I don't know much about recent changes to CMake. Still enough to justify my (and others') criticism.
> When people talk about setting up a new project, they talk about starting a hello world project and build up from there.
The original reply said one dabbled C++ via "creative coding, graphics programming, etc.", which definitely needs dependencies from the beginning. Can you draw a nicely shaded triangle only with the C++ standard library?
> If the library exports no cmake config and you have anything exotic you can put together your own cmake find modules, and proceed to follow step A.
They are not exotic, libraries without cmake config are common. So, as I've said before, people had to come up with their own find modules and this requires lots of trial and error to get it right. Guaranteed, it might have been possible to collect those into some sort of registry (a la DefinitelyTyped for TypeScript .d.ts files), and probably something like Conan can provide that, but ideally that should have been built into CMake. And keep in mind that Cargo---something we were comparing against back in time---does all of them declaratively. (Arguably, from users' perspective, it can handle C/C++ dependencies better than CMake!)
Yes! I spent 2 hours the other day trying to figure out why some OpenGL header had moved in between macOS versions, or had failed to install correctly with Xcode. OpenGL is indeed, not an exotic library, but this is the perfect example of why working on these projects is annoying. It's totally platform dependent, and while people who spend most of their time in C/C++ land are used to hunting down system libraries, "where does this random file that got installed with unrelated platform toolchain get installed" is painful.
I have no doubt that people who work on big commercial C++ project have sensible build systems and documentation that's not too hard. But it's incredibly common when working in this art/graphics space to need to try to get someone's bitrotted random project without docs or build system running. Common to have to do that AND have to do it on another platform.
There totally is an impedance mismatch. It's definitely not as bad as you might think, but this is exactly the reason that I theoretically want to use C++. Art code is the perfect example of code where (a). mutability is whatever / good and (b). safety literally does not matter. Its the ultimate domain of hacking something together to make something pretty on the screen, not serious software engineering.
> The original reply said one dabbled C++ via "creative coding, graphics programming, etc.", which definitely needs dependencies from the beginning. Can you draw a nicely shaded triangle only with the C++ standard library?
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.
> That's because Qt 6 wholeheartedly converted to CMake for you.
It's not Qt6. The same goes for Qt5, which has been around for what, close to a decade?
And what's your point, exactly? That things are hard if you purposedly ignore all the examples that prove that things are patently easy and trivial? Because it seems evident to me that if you want to quickly setup a C++ project to try out stuff, a CMake project with single-digit lines of code that get you a window with an OpenGL context going is right what you'd be looking for.
But instead you complain that the choice of build system and framework made things easy? And that's why things are not hard
In Rust, using a library is as simple as “cargo add library”, and this is always the case. It’s even the case for most popular C/C++ libraries which tend to have Rust wrappers available that seamlessly integrate them with cargo.
As someone who works in C++, the build systems are definitely the worst part. QMake is abandoned. Cmake is the de-facto option and is an ancient horrible mess that feels like a miracle if it works at all. What's left?
Options that are barely supported, severely limited in features, are only reasonable for tiny side projects, etc.
Aside from tooling (which is much better in Rust), C++ just isn't a very expressive language and has a high impedance with cognition. I've worked in C++ for well over a decade, and now that I've used Rust for a couple years, I just don't ever want to go back. It solves too many pain points of C++ to ignore.
Compared to what? Modern C++ is by far the most expressive systems language. That is its primary selling point. It isn’t pretty but it is uniquely powerful. One of the reasons C++ isn’t disappearing any time soon is that it elegantly and efficiently handles some software design problems that Rust struggles with. Rust and C++ are optimized for different types of software.
As is implied, the type of software someone is writing has a large impact on whether or not they need the expressiveness of C++.
> Modern C++ is by far the most expressive systems language.
If you want to iterate over a range of integers, you need to manually explain to the computer how to do it. In 2023. Also, you need to Write Everything Twice because of the ancient header system.
Ranges: kind of, there is the very awkwardly named std::ranges::iota_view, but it doesn't support random access and who knows if the compiler can optimize iteration over it into a simple loop.
Modules are not supported by most compilers (in g++ you have to enable them as an experimental feature with -fmodules-ts, and if you want to import the standard library as modules, you need to pre-compile them into your project directory with some arcane commands).
Once you you've worked enough with proper enums and matches, that's the first thing you'll be lacking in C++ (and no, std::variant is a horrible mess without proper syntax support and doesn't even get close).
There is a difference between what you can do at all, and what you can do without hard thinking. C++ makes a lot of things possible, but fewer things easily possible. I program mostly in C++ and I don't hate it, FWIW...
Agreed, but I would probably still be programming in C++ if the tooling weren’t so bad, irrespective of the expressiveness. That said, I’m glad Rust is expressive, but more glad that it picked a coherent set of language features—it feels much less cobbled together than C++ if only for the benefit of hindsight.
> C++ just isn't a very expressive language and has a high impedance with cognition.
I feel that you are the very first person ever making such a statement. Can you provide what's your single best example showing C++'s inexpressiveness and "high impedance with cognition"?
I've had great experience with migrating C/C++ projects at work to use Bazel, at least in the sense that a couple of hours' work yields me a fast, correct, reproducible build and has usually sped up incremental build times by orders of magnitude.
But in a corporate environment where repositories are often authenticated, the fact that dependency fetch issues are reported as Java exceptions (having the wrong password in your netrc file shows up as "IOException occurred during fetch of ... Code 401") is a deal breaker for a C/C++ development staff unfamiliar with Java.
They happily take their ten minute incremental builds and "it works on my machine" issues in return for a build process they can understand, and as much as I want them to be wrong (I use Bazel all the time at home), I can't blame them for wanting tooling they understand.
Yeah, Bazel’s ergonomics can leave a lot to be desired, but to me the results are worth those issues. In general, changes to Bazel rules are much less common compared to code changes, so at least it’s only a small subset of time where you might see such issues.
For this sort of thing, what I tend to do is write doctor scripts that check this kind of stuff "out of band". Can be tricky, but like "have credential stored in a file, then have an out of band script that checks that the credentials can reach a server" can save a lot of headaches. "Did you run the doctor script?"
Interesting. My friend, who works at well known gaming company you've probably heard of, recently spent several months of his life fighting back against a group of people that came in from an acquisition that were trying to convert the company's well-working CMake system over to Bazel. He described it in pretty poor terms and described how it constantly caused the build system to fail. He eventually succeeded in convincing management to keep the CMake system rather than converting it to Bazel at the objection of the more senior devs from the acquisition.
It’s a somewhat steep learning curve, but in my experience once you have your Bazel rules set up properly, it’s incredibly powerful, enabling lots of time savings from caching, as well as helping enforce reproducible outputs.
I feel like Bazel is much more convincing _after it's working_, cuz you really do get much faster builds. But the work has to be done, and there's a lot of unlearning to do.
If your project doesn't take long to compile or test anyways.... I can see getting annoyed.
> I feel like Bazel is much more convincing _after it's working_, cuz you really do get much faster builds.
I have to call bullshit on this claim.
CMake is at its hear a build system generator. It offers a high-level abstraction to define software projects, and it uses that abstraction to generate the actual build system. It can generate makefiles, but also Ninja, Xcode, visual studio, and even msbuild projects.
What actually does the build is not CMake, but make, msbuild, ninja, Xcode, or visual studio. Not CMake.
You run CMake once to generate the build project, and when you actually want to build the project you only call ninja or make etc.
To top that off, some of these build systems support build cache systems such as sccache or ccache. Plugging in one of these tools can easily drop build times to a fraction of the time. Literally. I had C++ projects which used CMake whose build time of a complete rebuild dropped to 15% of it's original time.
I haven’t been able to get Bazel to work passively for small, non-toy Go projects—I’m sure it’s something I’m doing wrong, but Bazel is a complex beast to operate. It’s far more complicated to use than Cargo.
use bazel if you're compiling large C++ or Java projects. If you're using rust, use cargo.
Nothing beats a language's own dedicated packaging system (yes, even python's mess is better than bazel+python) but C++ and Java have bad build systems, so bazel is better for them
Granted, but the context of the thread was that C++ build tools are low quality compared to other ecosystems, and you mentioned that Bazel was supported and "quite good" implying that it was comparable with other language ecosystems (perhaps that's not what you intended to communicate?). I believe that it's better than CMake, but the original point (C++ lacks good build tooling compared to other languages) still stands IMHO.
> Cmake is the de-facto option and is an ancient horrible mess that feels like a miracle if it works at all. What's left?
There is build2[1], which tries to approximate Cargo's experience for C/C++ projects while providing more depth, especially in the build system (unfortunately the "build by convention" ship has sailed for C/C++ so there needs to be some flexibility).
As some indication of the project's "seriousness" (there are a lot of toy build systems out there), it builds Boost and Qt (both 5 and 6 but only classic for now).
> Cmake is the de-facto option and is an ancient horrible mess that feels like a miracle if it works at all. What's left?
I've been working with C++ for a few years and did some work porting legacy apps to CMake. I've saw awful CMake legacy projects but since CMake 3.0 and the introduction of it's declarative way of setting up targets CMake is actually quite nice to work with.
What exactly does CMake do that you feel is "an ancient horrible mess"? Can you provide any specific example?
Initially coming mostly from the Java ecosystem with its mature (not perfect) build and dependency story, it took me days to understand that none of that exists in C++.
All of it seems to be based on copying dependencies around or installing them on a system level. Plus mostly template/text driven make files.
I'm still not sure if this is really how C++ is developed.
Four years ago, when I last looked, I wasn't able to find a good resource for people with my background to learn C++ the ecosystem (not the language).
That turned me to Rust.
All of this text to give strong support for your first paragraph.
I spent the better part of a day trying to work out how to get VS Code to see library functions in the auto complete feature. Eventually I got it so it could ctrl click to go-to-definition but it still underlined the functions as undefined and auto complete wouldn't show them. I wasn't willing to go any further and waste more of my free time to solve this. I'd never experienced such an unintuitive process.
Had this same experience several times in various projects and in all sorts of IDEs, major pain. If it’s helpful, I recently came across the 10x c++ editor project, which has the best c++ code completion experience I’ve seen by a huge margin. Some rough edges UI wise, but it’s still in beta
No you are not alone in being shocked by that statement. What they could have more accurately said is that C++ is becoming a legacy language within the subset of programmers that contribute to wide open open source projects hosted on GitHub. This is an important factor to consider for a project like Fish, given that the viability of the project depends entirely on getting (quite often very young and very bought in to the latest hotness) programmers to contribute their free time.
Serious business obviously still writes in C++ more than rust and so it isn't legacy, but I can see why somebody may not be excited about spending their free time writing C++, and so Rust is the better choice if it gets people excited to contribute.
> I still don't see jobs paying a tc of 250k+ for rust jobs. Those exist for cpp
They are out there, though the "in Rust" is part of the footnote usually.
I interviewed recently for a 350k+ job involving rust and the odd thing about it was that I'm an okay C++ programmer, but I'm about as good as the average rust programmer because it's not been popular for that long.
Nobody is asking for a decade+ experience on rust, only that you don't run away from it when you hit compilation fights with the borrow checker.
This is not just about Rust though, but because I'm a second systems sort of engineer who can go in replace an aging C++ platform slowly by rewriting bits of it or modularizing it as we go. And the pay matches how badly they want to tear out the tech debt in the rewrite pass (also how horrible it will be for the first 8-10 months).
COBOL programming also pays good money. It's usually when a language becomes "legacy" that pay starts rising, because the supply of interested programmers starts drying up.
People are making arguments here about whether it's legacy based on number of projects in C++ or # developers who know C++, and that's just wrong. It's unnecessarily conceding the argument that we can't compare languages on the merits, which we can.
Cobol is legacy compared with C++, when C++ was new. You can see it immediately, the new language is just better than the old one, the writing is on the wall. All of the arguments for C++ boil down to path dependence ("We have X million lines in it", "obscure platform X isn't supported by clang", etc) there aren't good arguments for a new project to pick C++ over Rust.
So it's legacy because Rust dominates C++. It will take time for that to play out and for the amount of code in rust to exceed the amount written in C++, but it's true.
(There's an additional argument one might make that Rust is a niche language that won't gain traction, but we're far past the point where that argument can be taken seriously, with Rust in the Linux kernel, and Amazon, Google and Microsoft all adopting it)
While I praise Rust's security, there are dozen of use cases where C++ rules and Rust hardly has an option that can match C++'s offerings in libraries, IDE tooling, job offers, platform support, unless one is into creating ecosystems from scratch mood.
C++ is still the de facto language to write truly performance-oriented programs. While I do find Rust refreshing in that it actually brings something novel to the PL space, let’s not put the horse before the cart. While I’m optimistic about Rust’s future, it is still a tiny niche language compared to bigger ones, especially C++ in their targeted niche.
Cpp is the de facto language for that, it’s not that it is impossible to do so in rust. But there are certain patterns not as well expressible in rust.
> People are making arguments here about whether it's legacy based on number of projects in C++ or # developers who know C++, and that's just wrong.
They are hype-driven cargo-cultists who embody the role of hype-driven fanboys mindlessly pushing a hyped technology.
No technical merit is presented other than cargo-cult aspirations, and to fill in the void in their rationale they resort to try to denigrate other technologies again through non-technical arguments.
The most pressing problem plaguing Rust is it's community and it's extensive use of ignorant and/or bad faith claims to upsell Rust while criticising technologies they know nothing about. Most of the people they are trying to pull these stunts are professional software developers with years of experience. Perhaps some of them know a thing or two about the technologies they've been using? Why does the Rust community think these stunts work in their favour?
> No technical merit is presented other than cargo-cult aspirations, and to fill in the void in their rationale they resort to try to denigrate other technologies again through non-technical arguments.
I don't even believe you think this is true. People who recommended Rust are generally positive.
Sure, sometimes it's compared to other languages and ecosystems, but that's usually done to point out improvements it has over other languages people are familiar with (I think that's just to describe).
For example, I could talk in a void how I like that the packaging and build system are more cohesive and simple, but it will be a long essay as to why, and ring differently to different audiences. An TypeScript, Ruby and Python developer will not be interested, since they've always had those. But comparing it to C/C++ build systems makes more sense, because the languages occupy the same domain.
There's other examples I could give with regards to the type system, etc. So, it's not there for me to tell you "why C++ sucks" but to easier demonstrate to you what improvements would make your job easier and more enjoyable. Some people disagree, and you do too, and that's fine.
If you say you disagreed because X, people will respond, though. They will either think you're trying to misconstruct the narrative (like I feel you did in this comment, but I apologise if that's not true), or think you have a misunderstanding or a misconception and want to clarify what they said. So, it's not an attack, it's just Internet comment etiquette.
The point was never to put C/C++ down, just to make it easier to illustrate the improvements. People have always complaining and disliked the accidentally complexity of C++; it's got nothing to do with Rust. The only difference now is that there's an alternative.
Or another thing, which could be purely anecdotal: I've worked on C++ codebases and Rust codebases both in private and professionally, and even though I have more experience with C++, I'm generally more confident when working with Rust. Probably because I'm less "vigilant" of certain types of bugs due to the more modern type system.
None of this is to say that Rust doesn't have its own problems, because it certainly does
Maybe because the Rust community care about the language, develop it openly, in cooperation with like-minded people, want to be inclusive and care about software security? Of All these, what does the C++ standard committee do?
No surprise why Rust people can be ( sometimes) sound like cult, where it's just a community.
Yeah, it's insane. You're not alone. I have had a career working in C++, but also love Rust and was paid to work in it for a while. But most people in the industry I casually talk to -- who aren't a particular kind of open source or language nerd etc. -- have barely even heard of Rust.
There's no way it's legacy.
Rust might attract new devs to the project, sure. But at the same time, quality software mature developers work diligently with the tools and frameworks they have and improve things iteratively rather than trying to burn down and rebuild everything.
And rewrites in general, no matter the language, are on the whole dangerous and harmful ventures that usually lead to trouble. As per the classic Spolsky essay.
Still, I wish the fish folks luck. If they can pull it off, all power to them.
> But most people in the industry I casually talk to -- who aren't a particular kind of open source or language nerd etc. -- have barely even heard of Rust. There's no way it's legacy.
While Rust is still too young to make C++ a legacy alone, the transition has been long underway. "Scripting" languages, managed language runtimes, and a popularity of web development has greatly reduced needs for C++. Nowadays no one writes a web server in C++ [1], not because it is not performant enough for its job, but because other languages are better suited to provide a tradeoff between development experience and performance. C++ will continue to have lots of niches for coming decades, but is already a legacy in many enough fields.
[1] Well, not really! First and foremost I have written a C++ web server as late as in 2016. But we needed a very good reason to do so, and any further logic was delegated to C#.
They do say it’s more of a port than a rewrite. They aren’t trying to do everything a new way this time around. That’s usually the downfall of a rewrite.
I’ve done these kinds of ports before. After you get used to it, you can almost shut your brain off and just start copying lines (so long as the languages are similar).
There is a lot of new state-of-the-art code being written in C++. I work on code bases that use both Rust and C++ which may seem odd to the casual observer. The reality that isn’t often acknowledged is that they excel at different things despite both being systems languages. For some kinds of software, C++ has far more finesse than Rust, the latter being a bit of a blunt instrument when very complex state interactions are involved — “safe” Rust implementations are comparatively bloated and slow. Rust works better with when state interactions are a bit more linear and straightforward.
The way I am seeing it shake out is that C++ is used for the core and Rust is used for skins and interfaces around the C++ core. It plays to their strengths to some extent.
That's an interesting statement. While you can most definitely write systems in C++ and Rust, they really start to excel when you are in the lower layers of the stack where many other languages start to fall short. What is the significance of calling attention to systems development in particular?
What tends to drive change? Growth and young people.
New developers and young people are not choosing C++ as a language these days. Rust is 'hot' and has much more mindshare even if it's not being used in large enterprises much yet.
What are the demographics of the developers you talk to? That may clear up your confusion.
I agree to you. There whole C++ thing is too unnecessarily complex.
In order to just compile a single Hello world program, you need to install the standead library, a linker and a compiler, each with their own version.
There is too many ways that compilation could fall, and fixing them requires extensive knowledge about different aspects, like how linker works, how is C++ standardized, etc.
The error message you got is really unhelpful. Missing a virtual keyword in a destructor, and you got a few hundred lines of error message and none of them mentioned "virtual". Segment fault is hard to trace because you do not have any error message at all.
Rust is just a lot simpler because it remove/abstract away lots of complexity. Just install Rust with rustup and it will just work. Error message is pretty helpful too.
As a young (enough) programmer, I'm keenly learning C++. Not because I love the language though, but because I am interested in game development, specifically in Unreal Engine for now.
I write code in C++ professionally and I do not see anything wild about that statement. It is very rare to start a new project in C++ outside of a few domains (high-performance finance, game development). There are more and more "C++ successor" language projects started by people even from C++ committee. I see more and more very well known people from the C++ community starting to learn Rust.
C++ is really unpleasant if you want to hop-in into some project. External dependencies (in most cases manually handled), various build systems (including custom ones - every project I worked on used a different build system!), various standards - ex. we have C++23 around the corner, and Fish has stayed on C++11. If you work in C++ you will stumble upon code from C++11 (or even earlier) to C++17. Learning C++ with intention to work in it means you need to basically know every standard released.
I don't think anyone should learn C++ nowadays if they don't have too - the only exception is if you are really interested in the industry that mainly use C++ and it doesn't seem it will change.
Well there's also a difference between what people want to work with at $DAYJOB and what scratches the itch for open source development on the side. If you're already working with c++ you know you'll be far more effective to continue doing so for some time, and it's hard to justify telling your employer to spend your time switching to something else.
For a hobby or side project, though? You just do what is interesting and fun, and maybe working with new languages is fun to a lot of people. This could account for the (perceived) difficulty in finding c++ contributors, despite the prevalence of c++ in existing code bases.
C++ is definitely very sticky. I’m not yet convinced that Rust will successfully displace it in projects like LLVM or WebKit. Components perhaps, but I think we’re quite a way from these sort of major projects being written in Rust, though I’d be happy to be proven wrong.
These two projects are older than Rust itself, and have hundreds of person-years of effort put in them. That's a huge investment, and huge inertia. It will take a similarly long time and large investment to replace them. It might happen eventually. Blink is adding support for Rust dependencies. Rustlang is adding pure-Rust Cranelift back-end.
But instead of looking at projects established in pre-Rust history, consider future outlook: if someone is currently writing very first lines of a project that will become equally big in a decade or two, that may likely be in Rust, not C++.
> I’m not yet convinced that Rust will successfully displace it in projects like LLVM or WebKit.
This comment induces a sort of cognitive dissonance in me. Rust is in the Linux kernel, and Firefox. How are LLVM and WebKit different? Of course, Rust may not displace C++ everywhere. Is that what you were saying?
Those examples aren’t super convincing to me. At least not yet.
Rust was created at Mozilla to help with browser engine development, so it’s not totally shocking that it’s in Firefox.
Rust is in the Linux kernel in the sense that its build system can compile interoperable Rust code. But the kernel is big — it’s 30 years of C code written by thousands of contributors which receives dozens of patches (in C) per day. Obviously “Rust in the kernel” has to start somewhere, but as of today, it’s really only relevant to Rust people who evangelize it. A kernel developer who doesn’t read HN would probably have no idea that Rust support was added.
Going back to the OP, the claim that C++ is “becoming a legacy language” is…bold. IMO it’s a ridiculous comment until large C/C++ projects (e.g. Linux, LLVM, Postgres/SQLite, big AI/ML toolkits) are mostly rewritten in Rust or overtaken in market share by alternatives written in Rust. If all of the biggest systems software projects in the world are still mostly written in C/C++ and still receive almost all of their contributions in C/C++, claiming that Rust is bumping those languages to some “legacy” tier is ridiculous. Things might go that way in the future, but we definitely aren’t there yet.
> IMO it’s a ridiculous comment until large C/C++ projects (e.g. Linux, LLVM, Postgres/SQLite, big AI/ML toolkits) are mostly rewritten in Rust or overtaken in market share by alternatives written in Rust.
Given this super high bar, I'm not sure any language would fit the mold of "legacy". I could just as easily say COBOL isn't legacy given this standard, as the world has not chosen to rewrite most of its COBOL software in Java yet, although we tend to think of COBOL as the legacy language.
So I disagree with your definition of "legacy". "Not considered for greenfield development" seems like a better definition of legacy to me.
So, yes, the term "legacy" for C/C++ would seem a little heavy handed for all software domains. But, for the software domain `fish` is targeting, it's not a ridiculous claim. Lots of the new, interesting stuff happening in systems-y, tools-y CLI stuff is happening in Rust. That isn't to say all of it is, or C/C++ isn't used ever, but if the OP said, "Look at the trajectory", and "Can you imagine writing a new shell in C or C++ in 10 years?", I might have to agree. Or, more concretely, if the OP said, "I personally can't imagine writing my open source software CLI tool in C or C++ in 10 years", I would definitely agree.
That's sort of what I was getting at. It seems incremental adoption is likely, but I'm not sure anyone is seriously going to try and rewrite all of Firefox or Linux in Rust.
Those are some of the largest public projects in existence. Even if you went with a "traditional" alternative (D? Swift? Ada?) - there is no way such an effort would not take years. Incremental is the only way to transition such behemoths.
I didn't share an opinion on rust or cpp, just a comment on the difference that I experience between people I have conversations with and the opinion of vocal internet people.
Only like 1% of people actually write on the internet. The everyone's doing it argument seems to me, more like a vocal minority.
> Only like 1% of people actually write on the internet. The everyone's doing it argument seems to me, more like a vocal minority.
Both the US Federal Government and the EU are apparently in the "vocal minority" who think programmers should stop using C++ because it's unsafe. Both have created documents which more or less just outright say that over the past year or so.
As a result, two other very significant things have happened which might reasonably cause people to decide that for C++ this is perhaps the beginning of the end rather than just an interesting bump in the road.
1. Several people or groups announced "successor languages" in 2022. Unlike Rust, these aren't merely languages which are sometimes cited as potential safer alternatives to C++ or as languages you might choose instead, yet have an existence all their own - The successor languages are specifically targeting C++ and C++ programmers. In this number we can count Carbon, Val, Circle and Cpp2 / CppFront.
2. Several WG21 ("The C++ Standards Committee") members wrote papers for WG21 either claiming that there's no problem (this is not, in fact, a thing you do when there's no problem, nobody writes US policy papers saying the US is not at risk of attack by Belgium) or offering vague plans for plans to do something about the problem. These are hastily written (Bjarne Stroustrup wrote or co-wrote four of them in as many months, all with numerous typographical errors) and do not in my view make a case that C++ is or will be fine although that's how they're intended.
Game dev is large part C++ exclusive because of legacy (the widely used engines were started long before Rust existed), so does one really have a choice if the goal is learning game dev? In the end, you learn what you need to accomplish your goal, even if you'd prefer other tools.
From my own experience with that branch of industry: you won't hear about it because it is likely not open source and those building it don't bother with such things as online communities for project visibility and so on.
But in government and very large businesses (banks, insurance companies, airlines) I would not be surprised at all if there was still greenfield COBOL work done. Just not nearly as much as say in the mid 80's.
See also the ton of "No True C++man" arguments in this thread :)
Yes, modern C++ may be pretty good, but how many people actually get to write it instead of sticking with the tried and true ye olde versions actually in the codebase.
you're correct. c++ isn't a dying language, and it's getting better every 3 years. the rust crowd likes to use that meme to gain adoption, but in the real world c++ is still dominating with no signs of stopping.
C++ isn’t dying, but it hasn’t been dominating since the early 2000s. I have a lot of grievances with the overly-enthusiastic Rust folks, but I haven’t heard them say that C++ is dying as a selling point for Rust. Frankly, Rust sells itself over C++ pretty effortlessly—hell, Cargo versus CMake is enough to get a lot of experienced C++ folks to switch to Rust (never mind the safety features).
Anyway, C++ is just getting new features every 3 years—these features are often really great additions, but they’re limited by compatibility with existing features (they’re not the best they could be) and not having legacy features in the first place is an enormous and overlooked value proposition.
Unfortunately, Bjarne Stroustrup himself disagrees with you that TIOBE represents the "facts":
> Most of the popular measures basically measures noise and ought to report their findings in decibel rather than "popularity." [1]
I believe he is wise enough to not change his opinion when TIOBE designated C++ as the Programming Language of the Year 2022 (which would mean, borrowing his words, C++ somehow kept making lots of noise).
A better source for what? It doesn't boil down to one metric or statistic.
I see you didn't actually read the link I pasted, especially not the section "Evaluating languages for projects". There's several possible ways you can compare (StackOverflow survey, JetBrains survey, GitHub PRs, StackOverflow trends, Google trends) but ultimately it comes down to what's a good fit for your project.
The claim being made in the original post and subsequent posts is that c++ is losing popularity. this claim is not true, and all evidence points to it gaining in popularity despite the HN echo chamber that it's too hard.
I still see you didn't read what I wrote. Please, just take a moment to read before firing off a comment.
I didn't make the claim that C++ is losing popularity, but I did mention some sources that do. These are marginal, not dramatic declines. Certainly not a terminal decline.
The original claim is "C++ is becoming a legacy language". This is clearly a claim about the trend of C++'s popularity over many years. You're trying to refute that claim with a single data point about one year, which isn't sufficient to refute a trend. For example, a single bad day in the stock market doesn't refute the claim "the stock market is trending up over the year". Moreover, your data point is probably just noise--a 4% swing when the error margins are closer to 50%. TIOBE is basically just guessing, and a guess isn't evidence.
FWIW, I've been a professional C++ programmer, and I like C++.
>You're trying to refute that claim with a single data point about one year, which isn't sufficient to refute a trend.
Below the list a graph showing the ratings over a 20 year period is provided. It shows C++ declining until about ~2017 but recently starting rising again.
> TIOBE has +/- 50% error margin and even if the data wasn’t unusable, it’s misrepresented (measuring mentions picked by search engine algorithms over a historical corpus, not just current year, not actual usage). It’s so bad that I think it’s wrong to even mention it with “a grain of salt”. It’s a developer’s horoscope.
> TIOBE thinks C popularity has halved one year and tripled next year. It thinks a niche db query language from a commercial product discontinued in 2007 is more popular in 2023 than TypeScript. I can’t emphasize enough how garbage this data is, even the top 10. It requires overlooking so many grave errors that it exists only to reinforce preexisting beliefs.
In my experience, it depends on the kind of development.
For hobbyist and open source development (myself included) it is right: C++ is just legacy.
But in the professional industry, C++ is still alive and strong. Lots of professionals are comfortable with C++ and don't want to ear about Rust or anything else.
All my customers paying money are using C++. Even for new projects.
That said, I can see a growing interest for Rust in the industry as well. So this might change really soon
It isn’t mentioned in the proposal as far as I could see. But for me the huge benefit of Rust over C++ for an open source project is the greatly reduced amount of scrutiny contributions need to be subject too. Unlike C++, you can’t introduce undefined behaviour or memory safety issues in any boring line of code. I imagine this is seen as a big win from the point of view of project maintainers.
I don't buy that at all though. Logic bugs are far more common, you will still have to carefully review each line and section. C++ isn't inherently unsafe either, you can use it with zero dynamic allocation if you really want or use language tools like ref counted smart pointers. Ultimately you can write unsafe and bad rust code too so reviewers will still have to carefully review every submission.
AIUI memory safety issues are literally over half of security issues. (Also, Rust's type system makes it much easier to avoid logic bugs).
> C++ isn't inherently unsafe either, you can use it with zero dynamic allocation if you really want or use language tools like ref counted smart pointers.
No you can't. C++ fans always claim this is possible but they're never willing to point at specific rules for which code does or doesn't do this, or which libraries are out there that do or don't follow their rules. It's vaporware.
> Ultimately you can write unsafe and bad rust code too so reviewers will still have to carefully review every submission.
Given that existing review procedures aren't perfect, the acceptable defect rate is clearly not zero. So if switching to Rust eliminates half the bugs, people could do half as much review and the end defect rate would be the same; why would that not be acceptable?
A breakdown comparing the language that caused the errors would be helpful. I expect that codebases in C or C++03 or even (idk) C++14 have much higher rate of memory corruption derived vulnerabilities, than those written in C++20.
I agree in the abstract, but people like to argue about if a codebase is truly "Modern C++" or not, even when they use newer versions of C++, due to it largely being about patterns and the amount of them. So you'll have people nitpick this to death.
> No you can't. C++ fans always claim this is possible but they're never willing to point at specific rules for which code does or doesn't do this, or which libraries are out there that do or don't follow their rules. It's vaporware.
I'm no C++ fan, but I've worked on codebases that do zero dynamic allocations including in C++. The rules are something like "never call malloc or use keyword new, communicate with other threads only by copying things into or out of queues." It doesn't save you from buffer overflows or whatever though.
Logic bugs are far more common, yes, but also much easier to spot barring subtle edge cases. Whereas with memory unsafety, the reviewer must load every function's conditions and invariants to their brain to emulate the borrow checker, at review time. Also the severity and cost of memory unsafe bug are far more higher: 70% exploit from memory unsafe, finding such bugs are also MUCH harder than finding logic bug.
This is not C anymore. When you write modern C++, it's much much more hard to introduce memory safety errors. And the logic hides in corner cases, so when you need to review logic, you're necessarily also reviewing memory correctness. I also don't agree with you on the part that logic is much easier than memory corruption - perhaps you haven't worked on systems complex enough?
The 70% quote includes programs written in C, which I would argue, has a much higher of memory corruption errors.
The thing with logic is that some logic is simple and some logic is complex. With C or C++ you have to check the simple logic just as carefully as the complex logic because any line of code might introduce a memory vulnerability and UB which could effect your entire project. With Rust, a quick glance over the simple logic is probably enough and you can focus your review effort on the complex bits and the few unsafe blocks (if your project uses any).
> I don't buy that at all though. Logic bugs are far more common, you will still have to carefully review each line and section.
I think the parent's point is that it's less likely a bug will be "lurking". You may disagree with that point too, but I tend to agree that it's more likely a memory safety issue is "lurking" than a logic bug is.
Maybe it can be reworded to say that the energy you spent on looking for memory issues is saved and can allow more focus on logical errors.
I find doing a code review a demanding task that leaves me drained by the end of it. Despite being drained, I still I don't feel confident I've been thorough enough.
It doesn't change the point I'm making that just because something is written in Rust means it will require less strictness of code review. There might be a class of bugs that are more difficult to hit in rust but that's just one of many bug types. You can still write terribly buggy code in rust. Assuming less strict review is necessary would be overall worse for the project and likely let _more_ bugs in.
> Assuming less strict review is necessary would be overall worse for the project.
Maybe? It might make it easier for those less experienced with C/C++ memory safety issues to review? Instead of thinking of it as being less strict, I might think of it as -- freeing the reviewer up to focus on other issues.
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 ::
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 here 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.
"Rust is an emerging programing language that aims at preventing memory-safety bugs without sacrificing much efficiency. The claimed property is very attractive to developers, and many projects start using the language. However, can Rust achieve the memory-safety promise? This paper studies the question by surveying 186 real-world bug reports collected from several origins which contain all existing Rust CVEs (common vulnerability and exposures) of memory-safety issues by 2020-12-31. We manually analyze each bug and extract their culprit patterns. Our analysis result shows that Rust can keep its promise that all memory-safety bugs require unsafe code, and many memory-safety bugs in our dataset are mild soundness issues that only leave a possibility to write memory-safety bugs without unsafe code. Furthermore, we summarize three typical categories of memory-safety bugs, including automatic memory reclaim, unsound function, and unsound generic or trait. While automatic memory claim bugs are related to the side effect of Rust newly-adopted ownership-based resource management scheme, unsound function reveals the essential challenge of Rust development for avoiding unsound code, and unsound generic or trait intensifies the risk of introducing unsoundness. Based on these findings, we propose two promising directions towards improving the security of Rust development, including several best practices of using specific APIs and methods to detect particular bugs involving unsafe code. Our work intends to raise more discussions regarding the memory-safety issues of Rust and facilitate the maturity of the language."
Code with zero dynamic allocations can still be memory unsafe. Ref-counted pointers in C++ are not inherently memory safe either.
If you do run into memory unsafety in rust, you already have signposts pointing towards possible problems. You get very little help in comparison in C++.
That seems blatant enough that a compiler should catch it, even a C compiler. Clang in fact does so:
idiot.c:4:3: warning: array index 69 is past the end of the array (which
contains 10 elements) [-Warray-bounds]
oops[69] = 420;
^ ~~
idiot.c:3:3: note: array 'oops' declared here
int oops[10];
^
But... if 69 is replaced with a user-supplied argument, then that bypasses the detection.
int idx = atoi(argv[1]);
int oops[10];
oops[idx] = 420;
If you write a literal illegal index in Rust the compiler will attempt to evaluate it as constant, conclude it's impossible and reject the program (whereas note that Clang only emits a warning for this scenario even though it's clearly bogus)
And so the runtime Panic will occur in Rust only for the dynamic case.
Notice that in WUFFS the user argument code is still a compile time error. WUFFS wants to know why you thought it would be OK to put arbitrary numbers in idx, a variable you are using to index into an array of size 10, and thus which should only have values between 0 and 9 inclusive. It won't be happy until you write logic to ensure this can't happen.
Rust is designed to remove the entire class of memory safety bugs, yet this comment seems to be a collection of hand wavey disregard for the stark differences in language design.
Those are just one type of bug. There are plenty of other bugs you can create in rust code and reviewers can't just assume because it's written in rust the code needs less scrutiny.
In my experience those one type of bug are also the hardest bugs to find and fix, even when you know it's sometimes happening. The system can get sufficiently complex such that it's near impossible to find the bug unless you get lucky. And often when you find the bug it can result in an apparently architectural contradiction and it becomes very non-obvious how to fix it as there are two architectural decisions that happen to be at odds with each other rather than a simple mistake.
How many many of these were ownership problems that could only be solved with a strict borrow checker and could not be solved with a garbage collector?
Think of it this way: every time the borrow checker throws a fit, it very likely saved you from a memory safety bug. Now, whether or not you would have made the same mistake in C or C++ is a different issue.
GC is unacceptable for some applications. Generally speaking, shifting the memory safety checks to compile time results in better runtime performance. Is the added complexity worth the performance gain? That’s for you to decide.
> every time the borrow checker throws a fit, it very likely saved you from a memory safety bug.
This is not even close to being true, the borrow checker does not accept all memory safe programs. It tries to do a good job of accepting programs that are both safe and have simple and elegant guarantees of safety across module boundaries (which is good for extensibility and evolvability).
But there are designs that can only be expressed in Rust by using constructs that replace some of these compile-time guarantees with runtime constraints.
I can say, that after quite a bit of experience in C++, and I often wrote code that would be rejected by the borrow checker, even if the code would actually be without issues, if the borrow checker would be disabled. Hard to tell exactly, but it seemed that the false positives outnumbered the real issues. Not saying it was a real problem, but certainly hints at what you said.
It’s more complicated than that. First of all, the parent did day “very likely,” and not that it’s always true. So the disagreement is over the degree.
Second, this can be tough because it is hard to self-evaluate. The two languages have different semantics. Some stuff is UB in Rust, but well defined in C and C++, and some things that are UB in C and C++ are well defined in Rust.
What this means is, while you are correct that Rust will reject some memory safe programs, I’ve also seen so many people over the years ask questions like “why does the borrow checker disallow this?!? It’s this easy in C++!” yet they’re running afoul of semantic differences, or they forgot some property (like thread safety) that isn’t enforced by the compiler in those languages, but rustc catches it.
Tl;dr you’re technically right but in the real world it plays out more subtly than I think you’re giving it credit for.
It's true that there are some things that are "well defined in C/C++ but UB in Rust" but it tends to be stuff that the Rust dev community tries to address over time, by providing facilities for doing the C/C++ thing safely given the minimum required guarantees (and no more than what's truly required). Pinned data is perhaps the clearest example here; "out" pointers and in-place construction is AIUI in the works. Failing to address these issues creates safety concerns, as users will resort to calling code that expects Rust semantics and create UB by doing so.
I agree that the Rust community tries to bring safe alternatives to some of these things, but it's not really relevant to my point here.
> Failing to address these issues creates safety concerns, as users will resort to calling code that expects Rust semantics and create UB by doing so.
Absolutely. What I'm saying is that sometimes this is expressed by users as "I can do this" when they actually can't, which makes it hard to talk about how much the borrow checker truly gets in your way. They're just two different languages with two different sets of semantics, you cannot assume that everything that works well in one works well in the other, in both directions.
Most applications should probably just be written in a garbage collected language, but Rust and C and C++ are mainly there to support use cases where running a garbage collector isn't appropriate. (I.e. you're trying to get your code to run as fast as possible, and don't mind doing some extra work.)
Maybe there's a reasonable case that Rust has developed to the point where an experienced Rust user is just as productive as an experienced Java or C# user even when it comes to tasks that aren't performance critical. For my part I think I'd rather use Haskell than Rust for tasks where GC overhead isn't a deal-breaker.
This is in fact a large part of why people are so pro Rust. Think of the compiler as a very strict linter, one so strict it can catch things that just aren’t semantically possible in many other languages, including C++.
Some linters catch some undefined behavior, but not all undefined behavior (I'm guessing not even most undefined behavior). And no one runs linters. If they did, a ton of CVEs would just vanish. But they haven't.
Logic bugs tend to affect the feature that the offending code is meant to support -- if the feature isn't working correctly, it's probably a logic bug in the implementation, so you can look there.
Memory safety bugs, on the other hand, can have unpredictable results that are far away from the code that actually caused the problem. Usually it's possible to figure it out from clues like, "the program only crashes after I use this particular feature" but sometimes memory safety bugs can stick around for a long time without anyone figuring out why every once in a while the program crashes for unexplained reasons.
If someone submits a pull request adding some feature to a big project, then the stakes of accidentally approving a bad change are (usually) a lot less if you're only concerned with logic bugs and they only affect that feature.
I know this can be seen as the "now we have 15 competing standards" thing , but I want Google's Carbon to work out.
Effectively a perfectly interopable (both ways) subset of C++ with some syntactic sugar and niceities.
But yes I agree that best practices of modern C++ means most of the baggage and bad ways of doing things don't have to be done. Now just to enforce it via education and linters or something conventionally.
I hadn't heard of Carbon until very recently, and when I went to look at it, it doesn't seem to solve any of the real problems with C++. Their stance on memory safety appears very lukewarm.
So I don't really see why Carbon is at all interesting other than it just being another form of their standard "Google being Google" with their extreme "Not Invented Here"-itis. It just sounds like a slightly warmed over version of C++ with different syntax and near identical semantics.
Carbon at first blush appears to show that Google doesn't appear to understand the real problems with C++.
I can't see why anyone other than Google would ever end up using the language, at least as currently described by Google in their goals for the language. In general for something to be rewritten it needs to cause very substantial advantages to justify the rewrite.
(Disclaimer: was at Google/know some people working on Carbon but I had zero involvement myself)
If you are in a position where you can wholesale rewrite your program (or are starting greenfield), Carbon is pretty clear upfront that you should use another language: "Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should."
Natively fitting into the C++ ecosystem at Google and in some other extremely large C++ codebases (e.g. being able to directly use templated C++ code, using the same build system, bidirectional interoperability) is what is being prioritized.
I see. I missed that point of advice they gave. However even for existing large C++ codebases, I feel you'd be better served by piecemeal writing code in something like Rust with FFI, if you're going to switch language at all. Carbon doesn't move you in a better long term direction. It appears only useful for delaying the inevitable, which doesn't seem to make much monetary sense.
My sense is that you can always introduce something that people will be opinionated about.
But this makes me wonder: is there a language that lacks idiomatic designs because there is only one way to actually do anything? I imagine not but maybe!
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.
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.
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.
Thanks for the questions. They're the same ones I had when I was (separately) entertaining the same RIIR idea.
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.
Thanks for providing first-party fish integration/completions support! That takes commitment, especially since frameworks like clap just generate "static" completions that take zero advantage of fish's runtime introspection functionality.
I just discovered Chezmoi last week. For years I thought I was fine manually symlinking into a repo. Boy was I wrong! Thank you for the wonderful project.
You are most welcome! The beautiful thing about fish is that it's truly cross-platform, even on really niche environments, so I can agree with you but change that to "on any *nix system" rather than just Linux alone :)
Thank you so much! Fish is my favorite shell. The way it deals with auto-completion and history is so elegant. It saves me so much time! Never going back to bash. Thanks again!
I've never really looked in to Fish but this seems like some pretty exciting work. I'll be checking it out and considering switching from ZSH when it's done.
I have mixed feelings about this. It's an interesting experiment and I'm curious to see how it'll pan out, but most of the justification boils down to "C++ is established and boring, Rust is trendy". To me, this wouldn't be convincing enough to switch to a language that doesn't even have a spec and in which a lot of libraries depend on very recent versions of the compiler.
For a free and opensource project, developer enjoyment and attractiveness to a wider audience of enthusiastic contributors is a very valid justification.
They even address this at the begining of the post:
>Nobody really likes C++ or CMake, and there's no clear path for getting off old toolchains. Every year the pain will get worse.
>C++ is becoming a legacy language and finding contributors in the future will become difficult
Dealing with a large C++ code bases and CMake build errors is about as fun as getting kicked in the head.
If Fish was a business and their entire focus was the bottom line, then it'd be a different conversation.
Personally I've found trying to set up a dev environment for C/++ projects to be like pulling teeth. I don't want to spend all day tracking down what my distro calls a library package. I want to get stuck in to programming right away if I'm doing it in my own time for fun.
Rust projects seem to always be extremely easy to compile, make use of common shared libraries, and shared patterns. Once you learn the language, you need to know little about the individual project like you do with C/++ projects.
This is probably the biggest reason I write new stuff in Rust. It's not as much a problem for existing projects that have already set up all their build infra though.
Well, that and you get stuff like fs::read(path) instead of always having to go find the ReadFile function from the last project you worked on like in C++ land.
>C++ is becoming a legacy language and finding contributors in the future will become difficult
To add to this point, I used to work at a large-ish C++ shop and we were already having problems finding C++ developers years ago and I'm assuming its just getting worse.
I worked at dev company that projects were outsourced to. I was waiting to be assigned to a project for few months. One day manager came to ask us if there's anyone that knows any C++. I can do C++ but I kept quiet. I was hired as a JS dev to have fun and I didn't want to be dealing with crappy C++ for the rest of my career at that company. Nobody out of 30 people or so admitted to knowing C++. It's highly unlikely that they all didn't know C++.
Much of Fish's genius is in feeling great to use, right away. It's a lot of small stuff, and dissected into minutiae, you could argue about each that it's not really necessary, or that you could already get existing shells to do that.
But when you add it all up, it makes Fish delightful in a way that no other shell quite is just yet.
I'd say it looks like they want to bring some of the same philosophy to their own toolchain and source code. It's about making Fish more delightful, just for developers this time rather than just end users.
I'm optimistic that the Fish maintainers will be right this time, too. And at the end of the day, hell— it's their project, it should stay fun for that. As long as they don't break my usage too badly, I prefer that they rewrite Fish in whatever way keeps its development joyful for them. (I trust them on this. It's a small team maintaining a project they clearly love, and I think they have the chops.)
I couldn’t have said it better myself — fish is truly a revelation. I moved from bash to fish maybe ten years ago, and the positive impact of fish has been enormous. The project contributors have made so many good design decisions, and as you posit, and it’s great example of the whole being greater than the sum of the parts.
On a related note, I’ve been really happy with the project’s release / update cadence. It seems like every few months a new feature or refactor drops that makes my life easier. It’s just such a great tool, and such a well-governed project.
C++ is established to be painful. Even the best engineers, working on Chromium at Google, keep producing lots of bugs using C++, the majority of these being memory-related bugs.
Maybe Rust is equally hard and slow to write, but at least the result generates fewer CVEs.
I love Rust but man, what a weird way to introduce it. The bashing on C++ was a bit silly - the biggest benefit over C++ IMO is that Rust makes it much easier to avoid certain kinds of memory bugs.
Note that I said easier: C++ allows that avoidance of bugs too, especially modern C++, and the ISOs do a lot to encourage the right stuff, but its still a very mixed bag in my personal experience. There are also plenty of bad idioms in the C++ space that people blindly follow, so there is some diligence required.
Also, I have to add for that one guy typing a reply to me now: this isn't to say C++ devs are inferior. In fact far from it, there are some seriously smart people in that space that I deeply respect. But its important to distinguish the devs from the tool, and when we are talking JUST about the tool, Rust seems like a good pick here.
The point of the "bashing on C++" is to present a persuasive argument for the rewrite: "the status quo is unworkable, we need a solution, Rust is the best solution". This is a much stronger case for something as drastic as a rewrite than "Rust is better".
Rustaceans should evangelise their language with actually relevant points though, not bring up unrelated bloat into their arguments.
For example, there is no reason to talk about cmake in a conversation like this. Its childish and sabotages a legitimately good movement: using a safer language.
Edit: I have made quite a silly gaffe. This is a lead dev commenting, not a thread started by a visiting user. That changes things quite a bit. My apologies to you and the dev in question.
This isn't a Rustacean evangelizing their language, though, it's a leading developer in a project making a case to the rest of the dev team. OP presumably has some idea of how the rest of the team feels about C++ and CMake and how they'll react to this negative characterization.
As a C++ developer, not having to deal with cmake et al again is not the worst argument for using another language. Not a major one (cmake is servicable after all, just annoying), but one. Don't see how arguing with better tools is "childish" and "sabotaging".
To me, the issue is the construction of the argument, and the context.
Cmake has flaws but unless the fish devs have explicitly complained about them, I would say it doesn't make sense to bring it up (note: maybe they did, which would invalidate what I've said and make me look a bit silly). However, we know security will affect them (since they're a shell interface) so that does make sense to mention.
But, between cargo and cmake, I agree I will always pick cargo.
I’m generally kind of a wet blanket on “rewrite all the things because Rust!”, but…
A shell is one of the few pieces of software where the lowered attack surface might legitimately justify a massive effort to achieve feature parity to what you have now. Browsers, ssh servers, stuff like this it’s plausible.
> * Nobody really likes C++ or CMake, and there's no clear path for getting off old toolchains. Every year the pain will get worse.
Subjective, at best. CMake isn't really more painful than bash scripts, they're both well defined, well-documented and stringly typed.
> * C++ is becoming a legacy language and finding contributors in the future will become difficult, while Rust has an active and growing community.
Speculation. C++ also has a very large active community. Reminds me of when people said Ruby would die. People are still using Ruby.
> * Rust is what we need to turn on concurrent function execution.
Why? C++ is just as powerful of a language as Rust, if ergonomically different and providing fewer safety guarantees.
> * Being written in Rust will help fish continue to be perceived as modern and relevant.
The worst reason given on this list. You're proposing a rewrite for appearance's sake, to keep up with the Jones'? We're talking about tearing down and building all the walls in an entire house here, not just painting the siding.
Why not just come out and say "I want to rewrite it and Rust because I want to rewrite it in Rust"? This is such a blatant example of pop culture in development affecting decisions.
> CMake isn't really more painful than bash scripts
Feels like damning with faint praise, though I suspect that was not your intention. "hacky pile of bash scripts" is usually the thing build tools get praise for replacing/subsuming.
it is a broken language forcing users to focus on the language itself rather than actual problems. it is a museum class language run by trucks load of bureaucracy.
12 years after the release of C++11, think about all those wasted years & opportunties.
It has never been a better time to depreciate C++.
> C++ is the programming language equivalent of democracy.
No, it is not. It is a language controlled by a small group of elites of the past, aka dinosaurs. How many day to day developers of C++ had a say in its stdlib or core language features? Literally zero.
It is the programming language equivalent of autocracy - it works very efficiently when everything is under control, but it can crash in all kinds of unexpected ways when anything is out of control.
> Nobody is thrilled with it
You are right. That is the exact reason why we are seeing more and more existing projects moving away from such legacy languages while very few new projects are repeating the previous mistakes by using C++ again.
> but it's still better than the alternatives.
No, that is not true. There are tons of other languages that are far better. People are walking away from C++ to get their codebases completely rewritten in those alternative languages is the best proof. So far, e.g., I've never seen any single major project that switched from golang or rust to C++.
Let's be honest, it is time to completely have C++ written off. It is a liability not an asset. Some old folks can keep worshiping it, that is fine, young people are not going to waste their lives on such backward language defined with a 1970s mindset by a close group of dinosaurs who have a combined age of 1 million years.
The democracy quote wasn't meant to be a comment about the governance of the C++ standards committee. It was the "bad, but better than the rest" idea, as well as the humorous nature of the quote, that I wanted to use to draw a comparison with programming languages.
Criticizing C++ based on age has two problems. One is you probably don't have any real data on C++ users, so it's just speculation. Two is it's a logically invalid argument, an ad hominem. If someone were to criticize Rust based on the age of its users that wouldn't be a good argument either. Also, a language being newer doesn't make it inherently better. Bad programming languages are created anew every day.
I will take Rust more seriously when it gets widespread adoption in industries where performance and productivity really matter. Take AAA games for example. These projects require squeezing every last bit of performance out of the hardware; toolchain support for a wide range of desktop, console, and mobile systems; $80 million budgets with tight deadlines. Another industry like this is high frequency trading. I'm not saying Rust can't provide these benefits, but the fact that we haven't seen Rust widely adopted in these industries speaks to the effectiveness of C++ for raw speed and getting shit done.
I share your frustration with C++. I have PTSD from working on C++ codebases for 8 years before moving onto languages that weren't as nerve wracking.
However, your comment is a bit too harsh and does disservice to the efforts of smart, well meaning people who make up the C++ committee. Also your remarks are very ageist.
You can criticize the outcome of a project without disparaging the people working on it.
> does disservice to the efforts of smart, well meaning people who make up the C++ committee
it is small group of people who managed to successfully ignore the entire audience for decades. I'd like to just ignore them when they intentionally ignored all their users.
we are talking about a language that took decades to get its networking support into its stdlib. I am not sure who many decades you have, I don't have many.
> You can criticize the outcome of a project without disparaging the people working on it.
the current issues of C++ are entirely caused by the people who controlled or let's say hijacked that once pretty cool language. I don't know how to address the issue without attacking those hijackers.
but I totally get what you mean. here is my proposal - people should all stop using this legacy language, let's write it off, depreciate C++ in 2023 sounds a very good move to me.
See my sibling reply to tw1984 where I discuss AAA games and high frequency trading. If Rust is unambiguously better, you would think there would be an incentive to adopt it in these industries where development costs are high and a lot of money is at stake. In reality, there are always tradeoffs, and Rust has some tradeoffs that make it risky or impossible to adopt in areas where raw speed and productivity are really important.
Not an easy page to read — the follow up comments evoke that feeling of dread where I’ve tried to move the needle in one direction only to have my thread swamped with people who express their drive-by opinions loudly, in-writing, without taking any responsibility for how they are affecting the overall tone of the conversation and basically derailing it into a discussion about bike shed color. “How about using Zig?” indeed.
We talk here a lot about remote work. Open source projects are the ultimate in remote work where only the most disciplined communicators get anything done, usually by collaborating in private, and everyone else twiddles about with flame wars until they next meet up in person at FooConf and finally get some work done.
Rust is a great language but it seems to attract plenty of "tech geek" people who don't really understand programming or CS beyond the surface and act zealot-like over "insert current trendy tech". I think the curse of a complex language like Rust is that it attracts people who make it a part of their identity and develop cult-like behavior because it makes them feel smart and special. I hope a healthier community will develop around Rust overtime.
I've observed the complete opposite. The people pushing for Rust are people who are highly experienced software engineers who have gone through a career of hardship because of memory unsafe languages and understand the tradeoffs. The "tech geek" doesn't even understand languages at all and so don't push any language at all.
It's instead the mass of "programmers" who've spent their lives only using a single language like C or C++ who instead write comments from ignorance criticizing Rust by claiming it's just being pushed by "tech geeks".
I'm not part of any Rust community. I've been out of university for almost a decade now and have been repeatedly burned by legacy C and C++ codebases causing bugs that take weeks to find because of their rarity and non-reproducibility that are inevitably memory corruption issues. If I could swing a magic wand and convert all C and C++ code to Rust I'd do it in an instant. (And I'm a pretty piss poor Rust programmer at the moment, and I'd still do it. I'd rather be learning something that would benefit my psyche and allow me to enjoy my job more.)
I've seen as many of the tech geek stereotype where there's some level of masochistic appeal of C (especially C89) to them where "if it's hard and some people can't do it, then clearly it must be good and only for the best". Especially among hobbyists who've never had to maintain a production codebase or deal with changing user needs.
It's a bit ironic because Rust is also hard, but in a totally different way than C89 is hard. For instance, plenty of novice devs got started with C89 (or even C++) as their first "serious" programming language, but we're not even sure how Rust could be adapted to fit the same role. (Probably it would involve teaching the basics of Rust as if it was a quasi-Haskell, or at least a deeply weird ML. So quite different from how C89 is taught!)
On the contrary, I feel rust could be a great language for students because the borrow checker will slap sense into them from early on and each error it throws teaches them a little more on memory, data safety.
Being allowed to mutate an integer (or object) through two different pointers on the same thread is perfectly safe and even useful (in the general case, for non-tree-shaped problems) on a CPU. Rust adds unpleasant syntax to achieve it through Cell, unpleasant syntax and undefined behavior footguns to do it through raw pointers, and guaranteed undefined behavior to do it through aliasing &mut, so I no longer treat Rust as a general-purpose programming language. And when teaching beginners, this would give the incorrect impression that it's somehow undefined behavior to access memory through multiple pointers on the same thread (rather than merely a tradeoff which increases code flexibility at the cost of local reasoning).
And on a more personal level, I dislike the Rust community (and language, eg. for loops depend on trait resolution)'s heavy use of functional, generic, and higher-order function abstractions (rather than explicit imperative code amenable to sequential reasoning). I feel heavy use of generics is confusing in a language used to teach programming to students (and I think usefully learning mainstream programming revolves around algorithmic reasoning from the level of memory and bytes through structured programming, rather than pure functions and iterator combinators).
> Being allowed to mutate an integer (or object) through two different pointers on the same thread is perfectly safe
Not safe in the presence of variant records (i.e. enums in Rust), since one pointer might be used to derive a pointer to a field of one variant, and the object might concurrently be switched to a different variant. This is why Cell<> only relies on explicit get and set methods in the general case, where the entire object gets replaced. It's a well-known problem in temporal safety.
I find that Rust prefers to prevent programmers from committing undefined behavior, rather than giving them the tools required to achieve tasks, when these requirements come in conflict (unsafe code is built to allow implementing general functionality with unchecked code, but is more difficult to write without UB than the equivalent operations in safe Java or unsafe C++, partly because mutating a & or aliasing a &mut is instant UB)
You have a very odd definition of a general purpose language. All the functional ones are out, because immutability doesn’t let you mutate through any pointer.
In my observations, immutability-focused functional languages are generally either non-Turing-complete and built as configuration/declarative languages, or find niche usage and do not replace JS/C++/Java/C# for mainstream programmers building a spreadsheet or word processor (and aren't built for low-level programmers to replace C++ for a browser engine or video game or non-allocating real-time audio engine).
I already teach borrowing and ownership semantics as ways to avoid memory issues in C. While Rust is a more complex language on the whole, the fundamentals of borrowing and ownership are more broadly applicable concepts.
Rust 101 would definitely be a weed out class for students trying to get a CS degree!
Context: I took C++ back in college in 1999 and 2000. There were students who struggled with it then who dropped CS as a major. Later on I heard that Java took over as a 101 class. Now I think it’s Python.
Heap allocation doesn't really come up all that much in "101" programs, though. You have Strings of course, but that's about it. So I think teaching Rust could work, people just haven't gotten around to trying it. Most intros to Rust including the official book explicitly assume familiarity with some other programming language, and often fail to explain other things (at either the "low" or "high" level of semantics) that a 101 student wouldn't know.
Indeed, the changing user needs aspect is inevitably the cause of so many memory corruption issues when old code, that's only really understood by that one or two grey beard still at the company and about to retire (or have already retired), needs to be changed. The change is put in and everything looks fine and then it's given to the customer who eventually complains of rare crashes on their previously-working-just-fine hardware. (Oh and you don't find out about the crashes until almost a year later given the long release cycle so have long forgotten what you did a year ago.) Inevitably it's used as an avenue for the sales engineers to upsell the customer on new hardware claiming their hardware is out of date. The software engineers all know this is a white lie given that the same software runs on both pieces of hardware and the hardware didn't actually change much.
It just ruins you over time and makes you wish you never had to work in this business.
> The people pushing for Rust are people who are highly experienced software engineers who have gone through a career of hardship because of memory unsafe languages and understand the tradeoffs.
The beginning of this statement is at odds with the end of it. Anyone who understands tradeoffs won't push anything because they know that which tradeoffs are acceptable is intimately dependent on the problem being solved, and without deep knowledge of the problem one cannot even begin to speak about accepting tradeoffs. Pushing someone who doesn't yet understand their problem towards a solution is the antithesis of engineering.
Moderately experienced code monkeys, who have been around enough problems to see failure, but not enough problems to understand that other people have different problems to solve seem to like to push languages onto other people, though. I'll give you that.
Surely you jest. Do you think most web services are written in C? Most enterprise software has been written in Java for a very long time. When you see exploits in other languages it’s often exploits due to the fact they were written in C/C++. Buffer overruns are no an artifact of the prevalence of C/C++, but that of the stack that you operate the C/C++ surface area is the weakest.
I don't understand why people care so much about these online faux-communities. A language or technology should be able stand on its own without a community. Rust can easily do that. It does for me. I couldn't care less about whatever culture war people are trying to inject into this.
Culture eats strategy for breakfast [edited, this used to say lunch because I'm tired and should go to bed]
Rust's safety in practice is a cultural phenomenon. For example, you could (using "unsafe") write an implementation of Index for your Rust type which has the exact same unsafety as the typical C++ operator[]. In Rust the community will insist your type is broken, an unsafe Index is wrong, whereas in C++ most of the community would see that as fine, why should operator[] be safe? After all the standard library's types behave this way. Culture is the only difference here. So, in fact culture is crucial to Rust's success.
Now, you could try to argue that it's unrelated, that there's this nice neat line between some cultural decisions like "Is it OK not to exhibit type safe behaviour?" and some other cultural decisions like "Is it OK to make racist jokes in my documentation?" but turns out that wherever you think that line "obviously" goes lot of people disagree and you're going to spend all your time fighting about that if you insist it's real.
This is something that I wish more designers of programming languages paid attention to. We often say that programming languages succeed or fail based entirely on social factors, but I don't think that we always fully internalize what that means.
Given how important the programming culture surrounding a programming language is to determining how day-to-day usage of the programming language actually plays out, programming language features should not only be judged on their technical pros and cons, but also on the kind of culture that they tend to promote, which is very much an extrinsic, social thing.
There are certain features that tend to draw in certain kinds of programmers and repel other kinds of programmers. Those programmers will in turn pull in all sorts of other technical baggage that has a variety of other technical knock-on effects.
Hence when creating a new programming language, we should think carefully about what kind of culture certain programming language features promote and what kinds of programmers those features would attract and repel, because those can ultimately twist the programming language in ways far more influential than any of its original features.
I have nothing against the language and if it suits my purpose I will use it, and I have. But I don't want to use it for everything and I don't want to be told I should. For me it kinda either works or it doesn't. I'm not sure what kind of community it would take, like I dunno some programming language for racists or ISIS or something, but I don't think people should let it bother them.
The Rust community reminds me a lot of Bitcoin. You cannot say anything without a reply-guy telling you why you're wrong, even if it's just something minor. I already see all kinds of "it's in the kernel" posts in here too. (Hint: it's "in the kernel" is actually an argument against its use for, say, the web--not for it.)
This is just another instance of the tired cycle of people not understanding most problems in tech need evolution, even though the big things come from revolution. Just look at how mad people get about Apple's "forced obsolescence." You cannot start everything from scratch even for revolutionary gains.
Are there revolutionary gains with Rust? Well, I don't think it should be that hard to make revolutionary gains over a language that's the same age as I am. It would probably be better if everything was written from the ground up, but unless AI does it for us, that's a lot of wasted man-hours.
Apple still hasn't rewritten its entire stack in Swift, much less its kernel, and no one in the industry moves much faster than they do.
I would definitely consider starting any PC-based project (Rust doesn't very many platforms) that I might have used C++ or C for in Rust. And I prefer to used either a very low level language or a very high level language or two together (e.g., asm libraries with Python) and maybe one day Rust will work for me for that, though it has a huge runtime too. Mostly that doesn't matter.
I just try not to blame the language and it's good features for the obnoxious reply-guy cults that surround it. There are worse languages with good communities and definitely worse communities out there.
But no, I don't want to rewrite my MODplayer from 1990 in Rust.
> The Rust community reminds me a lot of Bitcoin. You cannot say anything without a reply-guy telling you why you're wrong, even if it's just something minor.
I overall agree with you and there is no reason to rush switching languages for already established projects, but not even for new ones. But I don’t think that this quoted part is really true about the Rust community. Sure, it has a very vocal minority you hear the most which might fit your description (it’s always those we see first), but I find the more general community very well-versed in low-level programming, more often than not having a strong C++ background and/or some advanced FP knowledge, which is great. I regularly visit r/rust even though I don’t use the language too much, simply because the quality of discussion on certain issues is very high.
Look at what happened to my post. A reply guy arguing that the binary size isn't large. I mean, everyone talks about this. Just like I said.
It's not even a big deal, I don't care. I have 3mb or whatever, but denying it is just bonkers.
You expressed an opinion about the runtime. If your complaint is actually that your Rust binaries are big, that's a different thing. The "reply guy" knows what a runtime is.
In a language like Java of course the entire Java Virtual Machine is a runtime. There are lots of nice things to like about this, but it's pretty heavyweight. In C and Rust the usual application software is built with a runtime, it just doesn't do very much. For example the runtime makes the world for your software hospitable before your main() function executes and it needs to arrange that atexit() work for example. Rust's runtime does a little more than C's but not a whole lot.
Both C and Rust have a mechanism to write software for an environment where you just wake up naked and setting up even the basic hardware is your problem, as might happen on a tiny embedded SOC too small for an operating system - C calls this "freestanding" and Rust calls it "no_std" but that's not the default.
The new complaint your have though is about binary size - your Rust binaries are big often because of mono-morphisation, a compiler optimisation pass which converts all the polymorphic functions used in your program into distinct instances of that function for each type used, possibly inlining some of them where they're used; and because it's statically linked so the binary ends up with all this stuff in it even if that same stuff would be used by other binaries. It's not big because there's some massive runtime living in the binary.
The sad part of current C++ culture is that long time ago, back in the Usenet flamewars of C versus C++, we used to be a bit like RIIC++ and we cared about the improved type safety and language features over what C was able to do.
Even Dr. Dobbs Journal, The C/C++ Users Journal, C++ Report had enough articles regarding safety in C++ applications.
Somehow this culture was lost, maybe as those of us that cared got focused in other languages as well, so now the hardcore performace about anything else are the majority and security conscious people have an hard time making them realize security matters.
As someone else who likes Rust quite a lot but has had a couple poor run-ins with 'The Rust Community™', I completely agree. A core part of 'The Rust Community™' seems to adopt extreme political viewpoints that act to alienate part of the population so I strongly say I love Rust but I try to ignore that 'The Rust Community™' even exists.
Well to play devils advocate; learning rust was pretty hard for me, definitely needed help from the community (readers may judge that it says more about me than rust if they wish).
I think his comment goes more in the direction of "Pythonistas" or "Rustaceans". When I coded in C/C++ about 15 years ago I never felt like a part of a "C" community, same the last 15 years I coded with Python (and Java), I'd never consider myself as a "Pythonista", even though I love the language and the effort everybody puts into making this language so useful as well as learnable. The Rust community is also really helpful and well structured in the sense that you know what to expect from a contribution (like a crate), but I'll never label myself as a Rustacean even if I'd start using Rust as my primary language. These "groups" seem strange to me, almost like a cult which I feel is out of place. Like a group of Americans learning and using the Italian language calling themselves "Italians" just to point out that they have a special relation to that language which others don't have. The analogy doesn't really work, because there are no such person's like born "Pythonistas", but it somehow illustrates the vibe these groups apparently want to irradiate. I love the languages for what they are, and the love and effort the communities put into them shows more through the language itself than through a label a community gives itself.
Yeah there was nowhere near as much of this tribalistic nonsense in the 90s. The millennial affinity to identity and tribalism, in general, is quite weird.
I see it as more of a deliberate community building choice, one that we've seen for decades and one that's more popular now than ever, I'd argue, and not some "millennial" propensity towards tribalism.
Every brand/product/service/etc is trying to create communities around themselves, with fan clubs, VIP memberships, social media groups, email lists, Zoom/in-person conferences/webinars, etc.
It used to be you had to have a ton of reach and value to pull those off before the internet, now every project has marketing and social media people doing the same thing online.
Really? I know it was mostly 2000s, but a lot of Paul Graham's writing was about how great Lisp is [1]. It also sounds like the C versus C++ arguments were wild too if Linus is still riled up about it.
I used to program Perl and C on various *nix systems in the 90s. I wasn't a Perlist or C-ist or Unix-ista. I didn't need to hate Macs and Windows and C++ as part of my identity.
If there is a trend toward identity and tribalism, it would be a pretty natural response to the midcentury trend toward isolated nuclear families and hyper-individualism. My recollection was that culture in the '90s was actually quite obsessed with "tribes" and identity as a direct reaction to the dog-eat-dog '80s.
oh right I see what you mean. I'm a late millennial and I've so far avoided putting too much of my self identity into tech I like.
At the same time - it takes all sorts to make a village, right? Those superfans of this or that language, library, database, whatever.. I'm glad they exist in the world and share their knowledge.
Wow I don’t see that in my experience at all. They tend to be amazing programmers and systems developers who love Rust because it makes complex things easy and safe without sacrificing performance. The rust community on whole feels really open and helpful in my explorations of late, that were started simply because everyone I greatly respected loved Rust and they knew their shit about languages better than anyone else I know. I’ve not found them wrong.
Every single tool that Ive replaced with a rust-replacement is faster, more stabld, has healthier development and release cycles.
Uutils, helix, zellij, ripgrep, and countless others.
Ive stopped caring (mostly) to convince others of it, but many, many Rust projects are clearly started by very experienced folks that know how to release and foster a community.
I think most of this stems from the fact you can focus on the problem you want to solve, instead of mundane plumbing (like in C or C++ project).
Suuuure, some people will complain about the borrow checker, but I think it's people who are mostly inexperienced with Rust. It's not really an issue for anyone after they've played with the language for a while.
Like, these days I rarely have to debug a borrowing errors, and if I do it's a few minutes of work tops.
more examples that I thought of while writing this; `fd` and `sd` which I use daily now. and since my nix config lists my rust tools, because I'm a `mut hardcoreZealot` TM: `exa` (try `exa -al --tree --level 2`), `dua` (try `du -x i`), `gitui`, `jless`, `bat` (sparingly)
`xplr` and `joshuto` are clearly thought-out non-trivial TUI file explorers that seem to scale to the naive and a certain power-user type.
`difftastic` is a very cool replacement `diff`.
`jj` is compatible with git, and like git-branchless, but I'll bet on `jj` for a number of reasons. It's also awesome and in 3 years there's going to be some amazing tools built with `jj` and...
(not a daily/semi-daily use, at all, but special mention:) `git-oxide`, I mean, you can guess from the name, the monthly reports show just how incredibly thoughtful the author is and just how incredibly viable and already-usable this project is (especially given the complexity which I really would not have understood without the thorough monthly updates).
followup, there's no reason for this to really mean anything, or for anyone to "believe" me, but I just opened this post on reddit:
and wow, what a smart tool, and a smart way to release it. I know how to mount a snapshot, and ripgrep/fd through it, could script that, but making that resilient would suck. The way this is presented is smart. It's a new OSS project, shows example usage in the reddit post. Anyway, I thought of my comment earlier, and of course, there it is, `Cargo.lock`, bias confirmed. And a tagged release. And has a `LICENSE`. And has committed `Cargo.lock`.
For the sake of not replying too much I'll say I'd echo everything spoiler wrote in this posts' sibling comment. And at the risk of coming across poorly, there's something that's a cross of stockholm-syndrome and sunk cost fallacy and it seems like when certain potentially displacing technologies gain more and more steam, there's a louder and louder minority that claim that this new paradigm is just too disruptive and what are they teaching our kids. (oops)
I’ve done some stuff in C and C++, and Rust is the one that made sense and I stuck with. It’s by far the easiest systems language I’ve ever used.
Also, this seems like a classic “Arch, btw” sentiment. Where you hear it over and over and over again, about how the folks who use this one tech are all assholes, but you never actually see the asshole.
FWIW I was turned off by a lot of the rust evangelism but you dont have to search that far to find relatively normal rust communities now. It's big enough that it's no longer just the over enthusiastic writing it.
Well, I don't know about borrow checkers, but scoped memory was added to C++ over a decade ago. In fact, I led the charge to remove every single new and delete from our codebase, and cause add it to the list of things disallowed by the static analysis tools.
Today, I wouldn't use new or delete in any C++ program for any reason. Segfaults and null pointers have become extremely rare.
I appreciate that RAII is in C++ as well. RAII is an addition to C++. You can write valid C++ with memory leaks all over the place. This is the nature of being a superset of C. In Rust, there is no other way (outside of using unsafe). It is a language based around compile time memory safety. Segfaults and null pointers aren't extremely rare, they're extremely rare in modern C++ (which is a subset of all C++)
The borrow checker validates references as they are passed throughout your program. You can have either (many immutable references || one mutable references). This may seem simple but is key to the memory safety ideas. The usages of references are validated. Move semantics are checked at compile time.
However the borrow checker is not only about new/delete, it also prevents other forms of reference invalidations (e.g. when holding a reference to a vector element while appending to the vector, that reference can become invalid when the vector gets resized).
While you shine a beacon of light with CS arguments like “zealot-like”, “trendy tech”, and armchair psychology like “part of their identity”—very rigorous and technical.
A lot of people who argue for Rust claim that it is both memory safe and fast, which is well-documented at this point. But it’s not like you’re going to address the actual arguments made in reality, are you.
> 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".
> C++'s string handling is subpar, and it's much too easy to fall into passing raw wchar_t * around (and we don't have access to string_view and that just enables even more use-after-free bugs!). This is annoying, because a shell is almost entirely string handling and unix api wizardry.
> The other general issues with C++ (header files, memory safety, undefined behavior, compiler errors are terrible, templates are complicated) are well-known at this point so I'm not going to rehash them. We know them, we have them, we hate them.
Not really sure why bold statements like this are so popular. But people read them, blindly assume they’re true and further propagate this mentality that “Rust is faster, more secure, lighter, has 12 pack abs, and a hot blonde gf”. A lot of us are sick of hearing it.
I think most C++ programmers would agree with that statement. C++ isn't winning any awards in programming language elegance, ease of use, or innovation. That doesn't mean it's bad, but I don't think very many people who work in C++ wind up evangelizing the language in the same way Rust or C programmers promote their languages.
Does anyone really like C++ and also knows it really well?
I’ve never really met anyone who’s actually liked C++ in the form it’s become in the last several years. It’s not that people need to dislike it if they don’t like it. But do people actually have a positive opinion of it?
I use C++ daily, and I think I know it well, and the more I get to know it the less I like it. I don’t dislike it but it’s a mess.
The same goes for CMake. I think it’s alright. But does anyone like it? It’s the best C++ build system plus ecosystem (please note I mention both, not just build system) but it’s easy to not like.
Put another way, if I had three ratings of “like” “dislike” or “meh”, both C++ and CMake are meh.
For certain types of code, modern C++ is uniquely expressive and powerful despite its many flaws, which is attractive. If you know how to use modern C++ well and switch to other systems languages, you immediately notice the loss of expressiveness and that some things become much more difficult to do. I don’t like C++ aesthetics but I do like its expressiveness and power (and neither C nor Rust are particularly aesthetic either).
The recent versions of C++ are vastly superior to the older versions. While I know there are some people like this, I can’t imagine what people find attractive about legacy C++. It was a terrible language to use until relatively recently.
As for C++ build systems, once I started using Meson I never looked back. Meson is actually pretty nice.
I think you unfortunately talked past both my points.
1. I’m specifically NOT saying that C++ doesn’t have its merits. It does. It’s a very capable language. But that’s different than positive mindshare, and I’d argue very few people genuinely like the language. Most people I encounter or see online seem to fall into apathetic about it, or want it to be simpler like C or more comprehensive about safety like Rust or have a better STD+Build system like rust.
2. Meson is great sure, but that’s why I specifically said PLUS ecosystem. Nothing really compares to cmake right now for the ecosystem and that’s a really big deal.
> Being written in Rust will help fish continue to be perceived as modern and relevant.
Rewriting something for no reason will for sure turn mature developers off. I've yet to hear a good reason for why you're proposing this rewrite. I'm sure it'll be perceived as very modern and "relevant" though.
> This should be thought of as a "port" instead of a "rewrite" because we would not start from scratch;
This is like when your ever-high friend says "I can quit anytime, man." You can call it whatever, but it doesn't change the fact of what this is. Total psyops there.
> Rewriting something for no reason will for sure turn mature developers off. I've yet to hear a good reason for why you're proposing this rewrite. I'm sure it'll be perceived as very modern and "relevant" though.
Fish has been lovingly maintained by a small group of developers for a long time, and it's an excellent piece of software. The person proposing the Rust port has been the chief maintainer a long time.
I don't think you understand the credibility they have with longtime users and contributors.
Not the GP, but I want to point out that while I respect the chief maintainer and not doubt their credibility with fish's users, no one is immune to mental fallacies.
GP's comment points out where there's gaps in thinking/logic in the arguments made to do the port.
Personally I think the maintainer would've done well both to the community and oneself if the reason given was
> Hey, I'm bored, I want to practice Rust and want to do something fun, so I'm doing this.
Why isn't using a language that has a growing community of young developers not a "reason"? They're looking towards the future and making the bet that it will be easier to get new contributors in Rust than in C++. Maybe you disagree with the prospective future of C++, or the feasibility of rewrites, but it hardly seems like "not a reason" to peruse something like this, it seems like a pretty strong one, since as you say "finding good C++ devs is hard" and they're interested in growing the number of contributors in the future.
Because, while the sequence "100,000 100,000 100,000 100,000" is stable and "1 2 3 4" is growing, that does not mean that the latter will eclipse the former anytime soon - the point being implied by TFA
I seriously doubt there are 5 orders of magnitude more C++ open source contributors actively participating in projects on GitHub than Rust, which is the relevant question. Enthusiasm counts for projects like this that are looking to stay relevant.
At this point, I would love solid numbers on the number of new C++ projects (open source or otherwise) vs Rust. Google just came out indicating how well the transition was working for them with respect to memory vulnerabilities.
C++ is simply not intended for new projects in this day and age; even Carbon and cppnew are specifically designed for projects that must interoperate heavily with C++ libraries, and are thus not entirely greenfield in that sense. The Carbon developers have explicitly made it clear that new projects should be written in a safe language if at all viable.
I am watching the Carbon talk now. Successful language transitions have happened in the past when the new language is fully and easily interoperable with the old one. How easy is it to add Rust to a C++ code base? If the answer is 'not at all', then the transition is unlikely to happen anytime soon (it hasn't happened in the decade that Rust has been around). "New projects should be written in a safe language" -- what about the existing ones? Your memory safe web server isn't very useful when it's sitting on top of a kernel tcp/ip stack RCE vulnerability.
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.
> it hasn't happened in the decade that Rust has been around
This seems to imply that no C++ codebase has had Rust added to it. This is not true, just to be clear, there are. Firefox, for example. Chrome soon. All kinds of things. I also may have misunderstood you!
If cxx.rs is at the forefront, I'd describe autocxx and crubit as being at the bleeding edge. But they hold the promise of significant improvements in interop between Rust and C++.
> How easy is it to add Rust to a C++ code base? If the answer is 'not at all',
Its not clear that you even read the linked post on GitHub before commenting.
The first post in that GitHub thread says: "This should be thought of as a "port" instead of a "rewrite" because we would not start from scratch; instead we would translate C++ to Rust, incrementally, module by module"
> then the transition is unlikely to happen anytime soon (it hasn't happened in the decade that Rust has been around)
> "New projects should be written in a safe language" -- what about the existing ones? Your memory safe web server isn't very useful when it's sitting on top of a kernel tcp/ip stack RCE vulnerability.
The best time to start rewriting everything in an ML-family language was 20 years ago; the second-best time is today.
I'm highly skeptical that ML will take over everything. ML is great for cases where being "sometimes wrong" or "approximately correct" is acceptable. It's not acceptable for the vast majority of computer science problems however. If there are many correct answers then ML is a good use case. If there is only one correct answer then ML will never be used there.
Edit: I assumed that "ML" here stood for Machine Learning, it appears that was not the case.
It’s his project. He sees it that way, as do others. You see it differently. The objective truth is probably somewhere in between.
Other projects have seen a significant positive impact after switching to rust. I hope fish shell also sees that impact, regardless of any feelings around rust.
As fish user, I can be concerned that a rewrite like this might ruin a project, and consequently oppose such rewrite. Doesn't matter whose project it is. If you think I should just ignore it and "accept decision" - this is when it's clear, that what you really mean is "you just should not care".
As a fish user, I'd be concerned about the opposite - having a burden of a big c++ codebase and all it's build shenanigans to maintain which is not fun at all anymore could lead to the project becoming stale, especially with a low bus factor.
Plus, it could gain new external contributors. Heck, I'd consider contributing myself now whereas I wouldn't consider wasting my time on doing c++ for fun unless it was mission critical for some reason
My thoughts exactly. Why would the implementation language bless a piece of software as ‘relevant’? I’d also argue learning how to do for loops in bash, which would let you write them on about any server in any data center on the planet, would serve one much better.
> How is it becoming a legacy language? This is completely false and unsubstantiated. Yeah, finding good C++ devs is hard, the thing takes skill.
If getting good developers that know technology X is hard and getting harder over time (which I think is definitely true about C++), this on its own will cause technology X to become legacy.
Something being cool and modern matters a lot more than you seem to believe.
Rust is a great language and it's growing in popularity. It's a good choice to get experience with Rust, grow their community and improve the codebase.
It would be like trying to run a FOSS project in COBOL. No one wants to do that for fun. The bank manages by paying people a fortune to do something they don't want to do.
Your comment is quite unnecessarily vitriolic, but I do love the notion that it's possible to become cool by learning a new programming language.
Besides, all the common languages we use now, whether or old or new, have all gone through a phase like this. I bet people made similar commentary about C back in the day too.
I always shudder a little when PRs get shared on news sites because I know the devs/maintainers are going to get a huge influx of unnecessary noise/commentary on the PR. Nothing like having the internet opinion bee hive swarming on your project, often wasting time.
That said, maybe this is too negative a perspective and maybe useful contributions will outweigh the noise
> Compared to us sticking to C++11 that's a staggering difference in version support.
I think this is actually a great point towards Rust. Many more rules are written down since the beginning which makes upgrading easier. Even if the rules break something, a change of rules is easier to detect than a new rule being written down, which had multiple implementations in the past.
"Because this language is cool, let's rewrite it" is not a practical approach. I also think the fact that the number of people who are proficient in C++ is decreasing is a problem. But the intransigence of the Rust zealots keeps me away from it.
Honestly, I am not sure how many of the 'Rust zealots' actually write Rust code.
when I was working in it for $$, I found the actual community of packages and maintainers to be quite reasonable people, and the language and tooling choices mostly sensible.
don't let the zealots scare you off, it's a good dev experience... overall
If only I were that brave. Too many things expect bash that I do not want that potential friction. Instead, I manually switch when I launch a terminal.
I never got the appeal of zsh. It felt just like bash with all the interesting features of zsh hidden into advanced functionality, whereas with fish lots of things "just work" out of the box without spending a bunch of time configuring it.
I'd rather have really good defaults and the option for configurability rather than not great defaults and really advanced configurability.
Changing defaults is tricky for established projects with a lot of users, because the software will change underneath for existing users who upgrade which can be very jarring. On the other hand, it makes things harder for new users. zsh starts the "zsh-newuser-install" tutorial to set up a more modern zshrc as a kind of compromise. Maybe that should be a bit easier though with just a "use all modern defaults" option. And, of course, there are many templates/projects in the interwebz.
zsh has many more features than bash, and implements many things better than bash. It's like comparing IE to Firefox or Chrome.
There are things that should be rewritten in Rust. Mostly libraries with vulnerability reports involving buffer overflows. OpenSSL. Bind. DNS servers. Routers. BusyBox. Low level infrastructure that has to Just Work even when under attack.
I've been writing a big project in Rust for two years now, but I'm not fanatical about it. If you're doing web back end, Go is easier and the web-related libraries are well debugged, because Google uses them internally. Also, you get concurrency without the complexity of "async", because goroutines, which are green threads, can block without stalling the system.
Rust is complicated. Probably simpler than modern C++, because C++ has acquired sort-of move semantics, sort-of ownership, and sort-of safety without throwing out any of the old stuff which makes those things sort-of. Safety is a tough retrofit.
Using Rust is alien to the way many programmers work. You don't debug much. You design, you code, and you get compile errors. Sometimes you get all the way down to one compile error, and then realize you have to do a day or two of rewriting to get the ownership logic right. This is fine if you're doing something hard with extensive concurrency where repeatable debugging is not possible and getting those errors out at compile time is a huge win. It's not fine if you're just doing business logic and desperately need to get some new feature into your program. People who mostly program in a REPL have a hard time in Rust.
Too many important Rust crates are still at version 0.x and not yet stable. The language churn of the early days is over. There's still library churn and breaking changes in low-level stuff. That's a classic open-source problem, where nobody wants to do the dull and boring cleanup.
The fact that Rust actively guides you towards a simpler and more elegant design is one of the greatest things about the language.
And I disagree that this is not useful when you're "just" doing business logic and iteratively adding new features, since any codebase that is not refactored when necessary will quickly become too unwieldly to even iterate on.
> What I mean is that we wouldn't use e.g. libc's "iswdigit" and friends ... because we use those functions, we're beholden to the libc wchar_t type ... which means the difference between cygwin (2 byte wchar_t) and as best as I can tell any other system (4 byte wchar_t) can appear everywhere.
Say what now? You can't use a wchar_t with iswdigit() even if you wanted to.
And wint_t (the correct type) is 32-bit on every platform I'm aware of, including Cygwin.
wint_t represents either a wchar_t or the sentinel value WEOF. You shouldn't pass an arbitrary Unicode codepoint to iswdigit() on platforms with 16-bit wchar_t.
Perhaps, but then wouldn't the issue just be that iswdigit() is practically useless, rather than that it 'requires' (it doesn't) using a type that may only be 16-bit?
Even on systems where wchar_t is 32-bit, that isn't a guarantee that the extended character set supported by iswxxx() includes Unicode.
(It also requires your OS to support a large number of locales, which is unlikely. The vast majority of iswxxx() functions are broken on the vast majority of Linux installs.)
> Perhaps, but then wouldn't the issue just be that iswdigit()
> is practically useless, rather than that it 'requires' (it doesn't)
> using a type that may only be 16-bit?
In my opinion yes, though obviously opinions vary.
When Unicode expanded beyond the BMP, the decision by some platforms (Windows, Java, JavaScript) to represent "wide characters" as 16-bit integers became a problem. APIs that accept strings rather than "characters" could be adjusted from UCS-2 to UTF-16, but anything shaped like iswdigit() needed to be reconsidered.
The thing about iswdigit() and friends is that it does mostly do what people expect so long as (1) they don't need to write cross-platform code and (2) their localization needs are simple (BMP only), which is true of like 95% of software, so it can be hard to convince anyone to stop using it in favor of more robust solutions like libicu.
Oh, nice. Can we do systemd next? I've started studying the current C implementation and I can't believe my whole system runs on code that feels so _brittle_. Not to disparage experienced C programmers, but the level of hold-my-beerness implied by all that casual raw pointer passing is astounding for a plain strongly-typed-no-malloc Java/Rust guy like me.
Remember that they’re doing an _incremental_ rewrite. At each step of the way, C++ code will be calling Rust code, and Rust code will be calling C++ code. One function or class at a time, code will be rewritten from C++ into Rust (though not really idiomatic Rust). The string type used by the Rust code must match the semantics and layout of the string type used by the C++ code as much as possible because any infelicity there must be patched up by a run–time conversion each time code in one language calls the other. If you want to change string types, it is best to do it either before or after the rewrite, not during. And I bet doing it afterwards will be easier than doing it beforehand.
I dunno, they put their money where their mouth is by bringing in code and offering some reasonable justification for the switch. I think this is a great example of how such proposals should be made.
I’m just talking about the content of the message in the post. Like, the “modern and relevant” line is exactly the sort of thing you’d say in a parody.
But I agree that they are actually doing the work and not just tossing out a suggestion and that’s great.
I understand all of that, and that’s great, but it doesn’t change the fact that I chuckled and had to do a double take when I first read the PR message because it looks like someone asked ChatGPT to “write a suggestion to rewrite it in rust in the style of an overzealous rustacean.”
I keep recommending fish whenever I get the chance. It doesn't require any customization, has sane defaults, is simple to use, and provides a great shell experience in general.
Additionally, I don't have to google each time I want to write a for loop, because the syntax is "the obvious syntax you'd expect it to be" instead of what bash has. That's absolutely a legit advantage of it.
If you didn't read into it, even though the issue looks like just a proposal in the first message, digging deeper it seems to be created by the top contributor, and is basically "happening".
Looking forward to seeing how this pans out! Especially any lessons learned about Rust afterwards.
> Especially any lessons learned about Rust afterwards.
So far the last few comments appear to be the bucket of cold water that all sane people would hope to see when someone proposes to rewrite $stable_thing (currently written in $stable_sane_common_language) in $new_latest_craze language for no reason - no distros ship recent rust toolchains, while C++ is "mature" and has toolchains that you can count on existing.
I don't think it's fair to say Rust is a "latest craze" language. Maybe five years ago, but not now. Numerous tools have been (re)written in it and supplanted old tools in at least some cases.
Additionally, there are reasons given in the linked issue. I guess you could debate about whether they're good reasons (they sound reasonable to me), but you can't say they're proposing it for no reason just because you don't like or agree with the reasons.
To that point, as someone who learned a decent amount of C and C++ a long time ago, I would probably never get involved in a C/C++ project nowadays, but I've been learning Rust these past few years and would definitely get involved in a Rust project if I had the chance.
And to be clear, I'm not bashing C/C++ at all. They're venerable and appreciated, but I have little to no interest in working with them, and it seems to me that this is a fairly common sentiment.
>I would probably never get involved in a C/C++ project nowadays, but I've been learning Rust these past few years and would definitely get involved in a Rust project if I had the chance.
This right here is a killer motivation. I will never contribute to a C/C++ codebase. The tooling is all bad, and I am too uncomfortable doing the simplest things (hello C strings). With Rust, I have few such reservations, and could contribute a patch here or there.
Last I asked anyone writing rust "for fun" - the answer I got was "latest compiler/features/shiny or GTFO", so rust 1.0 will likely get you LESS free labour from randoms online than C++ would
That's the point...
Compare to C89 code that will happily build on any C compiler of any vintage on any system you dig up anywhere, even those that are big endian, have non-8-bit bytes, or are not 2s complement.
Your C89 code will build on the C2x compiler in Arch and the C11 compiler in Debian stable N-1.
Your C17 code will not build on the C11 compiler in Debian Stable N-1 but will in the C2x compiler in Arch.
Your Rust 1.0 code will build on the Rust 1.67 compiler in Arch and the Rust 1.41 compiler in Debian Stable N-1.
Your Rust 2021 code will not build on the Rust 1.41 compiler in Debian Stable N-1 but will in the Rust 1.67 compiler in Arch.
I don't consider support for vintage platforms a requirement for a language being used in 2023.
EDIT: Since you've edited in this quote
> Last I asked anyone writing rust "for fun" - the answer I got was "latest compiler/features/shiny or GTFO", so rust 1.0 will likely get you LESS free labour from randoms online than C++ would
Yes. This is true. But I don't exactly see maintainers lining up for your hypothetical C89 example either.
> Last I asked anyone writing rust "for fun" - the answer I got was "latest compiler/features/shiny or GTFO"
Funny. I skimmed the changelog for all the changes since that version of Rust, and the only change that looked like it might be must-have is the the one that stabilized inline assembly. The Rust language has matured to the point that it is fine to pick up new compiler versions as lackadaisically as other languages (e.g., C++).
> Compare to C89 code that will happily build on any C compiler of any vintage on any system you dig up anywhere, even those that are big endian, have non-8-bit bytes, or are not 2s complement.
Actually, a lot of C89 code is likely to get hung up on pointers being 64-bits instead of 32-bits. While it is possible to write C code that works on non-8-bit-bytes or not-2's-complement machines, it is easy to write code that is not robust to such assumptions. Furthermore, C programmers--especially older vintage--have this nasty habit of assuming that they're writing only a thin veneer over assembly code, which tends to cause portability issues if they're making very architecture-specific assumptions, not to mention issue when it turns out that the behavior they think is happening is actually undefined and the more powerful modern optimizers make it do something completely different.
Oh, and I can think of two features in C89 which are no longer supported by modern compilers. And neither of them are trigraphs.
I've seen them. Let's see how they tackle those problems. I don't think fish, as a shell you're probably not using for checked-in scripts, needs too much backwards compat.
I know it's a meme, and I don't enjoy Rust that much myself (though definitely more than cpp). At the same time the reasoning is sound, the average open source contributor imo will more likely contribute to a Rust project, rather than a cpp project.
I support the whole thing even if it's just for the maintainers to have more fun maintaining the project (not that I'm suggesting this is the reason), after all they're the ones maintaining it.
If you want to write C++03, that's true, but as a maintainer of the fish build system I was having to backport compilers in order to use C++11 features on supported systems until 2020. Modern C++ is still a moving target and newer versions contain a number of features that make it much more pleasant to work with, but it takes decades to percolate into distributions.
Try splitting a string on a delimeter in C++. Now that I'm fluent in both languages, I find myself constantly irritated by how comparatively uphill simple things can be in C++. I'm always reaching for boost, waiting for 2017, or just writing a function by hand that was a programming example in the 60's and has been in Python for decades.
This might be a naive comment, but why post this as a PR on the original project?
If this person is willing to put in the work (a PR seems to indicate this), why not just fork the entire repo and call it "rish" or something? This software is available under GPL/BSD/etc so there is nothing stopping it.
I don't understand the benefit of replacing an existing piece of software with a complete re-write rather than just re-branding and then attract users and developers by explaining why it's better.
Especially when it's something so fundamental as a shell, I would be pretty upset if a jump from major -> major entailed a completely new piece of software with new bugs or previous functionality removed, which to me seems almost certain to happen.
When the new project reaches either parity or subjective superiority, presumably people would move over to it and if the theory that attracting C++ developers is really that hard turns out to be correct, then fish would sooner or later be abandoned by developers and users alike.
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:
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.
I think this rewrite is driven by the well-known safety challenges and long-term maintainability concerns with C/C++, not performance per se. Of course rewrites from existing high-level languages to Rust can result in huge performance gains.
> Allowing background functions and concurrent functions has been a goal for many years. I have been nursing a long-lived branch which allows full threaded execution. But though the changes are small, I have been reluctant to propose them, because they will make reasoning about the shell internals too complex: it is difficult in C++ to check and enforce what crosses thread boundaries.
> This is Rust's bread and butter: we will encode thread requirements into our types, making it explicit and compiler-checked, via Send and Sync. Rust will allow turning on concurrent mode in a safe way, with a manageable increase in complexity, finally enabling this feature.
Popularity is sometimes a compelling reason - not just to be part of the “in crowd,” but to take advantage of the ecosystem, documentation, tooling and expertise that comes with a popular language or product.
This reminds me quote from Pi movie: "You want to find the number 216 in the world, you will be able to find it everywhere. 216 steps from a mere street corner to your front door. 216 seconds you spend riding on the elevator. When your mind becomes obsessed with anything, you will filter everything else out and find that thing everywhere."
> I can't think of any other language community that does this.
Comments under this particular PR are mentioning at least two languages like "why don't you us this <lang> instead?"
Also what does this have to do with veganism?
For every vegan person there is huge amount of people on the internet, like you, that have urge to mention it.
Veganism always struck me as focused on people making ethical claims. Whereas the love for Rust comes completely from people trying to get away from existing pain that they're experiencing (at least in my experience).
I've certainly seen people make the claim that not using Rust is unethical.
In both cases you only hear/remember loudest and most annoying people anyway. There's definitely some Rust people who are annoying. There are also some vegans who are annoying. It's foolish to focus on only those people.
> Being written in Rust will help fish continue to be perceived as modern and relevant.
I have a hard time taking rust seriously because of this. It's the same category of "hype tech" as crypto/Blockchain for me. Maybe the hype will melt away soon and it'll just be a solid, stable tool.
I think the hype _has_ melted away in the last year or two, since Rust left Mozilla's basement and started working for Microsoft, Amazon, Apple and others. There are newer shinier languages for the hip crowd; the political aspect has toned down naturally while safeguards have helped the community remain vibrant.
I think the strongest signal is the inclusion of Rust in the Linux kernel. Having Linus give his blessing is about the highest level of certification Rust could have hoped for in the public space. The fact that a respected project like fish adopts Rust when they could have stayed with C++ indefinitely is just one more demonstration of this new maturity stage. Expect many more open source projects to follow suit.
