Rewrite it in Rust
github.com
github.com
- a yaml programmer
Yeah! That's what I am!
(Seriously though, Rush is music I can enjoy, though more a fan of Pink Floyd and Steven Wilson.)
Was this intentionally ironic?
I have a wide variety of wine appreciation, spanning a wide gamut from cheap white to cheap red”.
Actually it is more of a wide variety of adjectives in my case.
Super funny if on purpose.
> Was this intentionally ironic?
I think the "seriously though" is a hint that yes this was sarcasm.
> I have a wide variety of wine appreciation, spanning a wide gamut from cheap white to cheap red”.
> Actually it is more of a wide variety of adjectives in my case.
> Super funny if on purpose.
Agree it gave me quite the chuckle.
Actually maybe Yes is C++, in the sense that it is sort of a language that has had multiple iterations of every single component.
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.
(Both are bands I really enjoy)
Like ruddfish, rockfish, etc.
https://kupidonia.com/list/alphabetical-list-of-fish/letter/...
In other words, it sounds like the Good Stuff (tm)
Was awesome due to the MDMA drought at the time!
Also had London Underground Doves which were 4-MMC capsules as well.
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
Time will tell.
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.
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.
It's also part of fuchsia which is shipping in all those nest devices. I wonder when folks will decide it's really "made it".
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.
Existing projects for sure
New projects from scratch reaching for C++ off the shelf? Probably just video games maybe?
Name the last green field Cobol development however.
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.
If they truly have a green field to develop on, nobody will pick COBOL.
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.
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.
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).
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?
If anything, I'd think a browser is prime real estate for Rust, where the security guarantees are just that much more important.
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.
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.
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++.
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!
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.
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.
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
Which part of the following example is hard:
program(mynewproject LANGUAGES CXX)
add_library(libfoo STATIC foo.cpp )
add_executable(bar bar.cpp main.cpp )
target_link_libraries(bar libfoo )
Edit: and this message was downvoted? Seriously?
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.
Not really. When people talk about setting up a new project, they talk about starting a hello world project and build up from there.
Anyway, I'll bite. What would it take to add a dependency? If it exports a cmake config file which exports targets, all it takes is this:
find_package(MyDependency),
target_link_libraries(bar MyDependency::targetA MyDependency::targetB ... MyDependency::targetZ )
If it doesn't and it is instead a system library then you can even pass the library instead.
add_library(bar systemlibrary )
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.
Alternatively, you can even bolt on something like Conan and just follow step A all the time.
> Differently put: a phrase "metabuild system" has (...)
Sorry, but do you actually have any concrete example of any difficulty setting up a C++ project?
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!)
Taken straight from Qt's page on OpenGL support:
find_package(Qt6 REQUIRED COMPONENTS OpenGL) target_link_libraries(mytarget PRIVATE Qt6::OpenGL)
https://doc.qt.io/qt-6/qtopengl-index.html
Do you feel this is too hard to setup?
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
What exactly do you think is your point?
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.
That said... Rust and OpenGL have quite an impedance mismatch, don't they?
The options are there to be used.
Take a look: https://stackoverflow.com/questions/75270938/thread-pool-wit...
Options that are barely supported, severely limited in features, are only reasonable for tiny side projects, etc.
If your project doesn't take long to compile or test anyways.... I can see getting annoyed.
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.
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
What is wrong with Maven or Gradle?
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.
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++.
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.
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).
Modules: GCC and clang will eventually get there, I am already enjoying them on VC++
#define RANGE(type, name, last) type name = 0, last__ = (last); name != last__; name++
for (RANGE(i32, i, foo->count))
...
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).
C++ has lots of problems, lack of expressiveness isn't one of them.
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 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?
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).
Rather marginalized but https://waf.io/
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.
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.
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).
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#.
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?
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.
it's still dominating and gaining.
> but they’re limited by compatibility with existing feature
no, they deprecate features as well. this is why the auto keyword of pre-c++11 doesn't work anymore
> 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).
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.
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.
- Number of people searching Google - https://trends.google.com/trends/explore?date=2012-07-31%202...
- Number of questions asked on StackOverflow that month - https://insights.stackoverflow.com/trends?tags=java%2Cc%2B%2...
A far cry from the claim that it's "dominating and gaining", as you said.
FWIW, I've been a professional C++ programmer, and I like C++.
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.
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)
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?
All language communities care about their language. It boggles the mind how anyone could imply that only Rust cares about this stuff.
The Rust community is renowned for being problematic. Time and again it's called out on the grief it creates.
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
Or this this use case considered legacy now?
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.
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.
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
Now imagine if the linter is not optional.
Oh, yeah, that is Rust!
* up to implementation bugs in the compiler
"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."
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 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.
That is surely a win, no?
Here's a recent patch I wrote "Improve E0308: suggest user meant to use byte literal, w/ tests and fix" which adds a suggestion for Rust's diagnostic when you write for example '*' the literal char, Unicode U+002A but it needed a single byte and that's not what a char is. My code suggests adding the prefix b, so writing b'*' here, meaning the ASCII code for that symbol 0x2A which is a single byte ::
https://github.com/tialaramex/rust/commit/130d02b62e65c5f2a4...
I wrote that code but I don't understand the internals of how self.tcx.sess().source_map().span_to_snippet(span) works. Not my problem, we're in the diagnostics code so even if this is perhaps slightly slower than optimal it doesn't matter because a human will need to read this output and act on it - E0308 is a type mismatch, the program does not compile as written.
Does my reviewer know? Maybe, I didn't ask them, but they don't really need to, it's clearly fine here to call this stuff, there won't be a nasty surprise "Oh, make sure you restore the FQ5 when setting Z due to calling sess() in this code" because that's not how Rust works whereas in a language like C++ of course such traps may exist.
Now there is some risk I made a logic mistake, but, I wrote tests for this of course, unlike with subtle memory safety bugs, logic bugs are often caught by proper testing. My tests 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.
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.
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?
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.
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.
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.
> 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.
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.
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++.
int oops[10];
oops[69] = 420; 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];
^
int idx = atoi(argv[1]);
int oops[10];
oops[idx] = 420;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.
int x = 0x7fffffff;
x++;
std::array<uint32_t, 2> x = {1, 2};
uint64_t *y = (uint64_t *)&x;
*y;
std::optional<int> x;
*x;
std::variant<std::string_view, int> x;
x = "foo";
auto &y = std::get<std::string_view>(x);
x = 42;
std::cout << y;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?
Just go around open source projects from well known ISO C++ members.
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.
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.
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.
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.
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.
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!
1. How do you propose to handle changes to fish while the re-write is in progress? Should fish/C++ stop evolving? See https://www.joelonsoftware.com/2000/04/06/things-you-should-...
2. Wouldn't this be better handled by a fork of the fish codebase with a shared language specification and test suite?
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.
[1] https://github.com/search?q=repo%3Atwpayne%2Fchezmoi%20fish&...
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.
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.
Here's what he said way back in August of 2016, just barely over a year after Rust hit 1.0 in May of 2015. https://www.infoworld.com/article/3109150/linux-at-25-linus-...
> 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 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.
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.
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.
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.
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.
This article explains things well, IMHO: https://mdwdotla.medium.com/using-rust-at-a-startup-a-cautio...
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.
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.
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.
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.
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.
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.)
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.
Maybe Rust is equally hard and slow to write, but at least the result generates fewer CVEs.
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.
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.
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.
The comment you're complaining about was made by the fish devs. It is them saying that.
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.
I wish them luck!
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.
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.
I've worked on enough CMake projects to where I won't willingly do it again. Give me Cargo any day.
can't agree more.
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++.
It has been said that democracy is the worst form of government except for all those other forms that have been tried from time to time
C++ is the programming language equivalent of democracy. Nobody is thrilled with it, but it's still better than the alternatives.
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.
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.
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.
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 love golang and rust equally. :)
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.
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.
Delphi versus VB, VB vs C++, Pascal vs C, C vs C++...
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.
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.
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.
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.
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.
Yeah you don't say, it's huge! Like maybe just a little bigger than C runtime. Unacceptable!
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.
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.
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.)
It just ruins you over time and makes you wish you never had to work in this business.
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).
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.
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.
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.
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.
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.
`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:
https://old.reddit.com/r/zfs/comments/10pdspe/take_your_zfsb...
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)
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.
For myself and many that I've interacted with, Rust's Borrow Checker and memory system saves me from the PTSD of segfaults and null pointers.
I'd love to see the idea of borrow checking and scoped based memory extended to other languages, but that's what makes Rust great for now.
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.
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’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.
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.
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.
> Nobody really likes C++ or CMake, and there's no clear path for getting off old toolchains. Every year the pain will get worse.
I do like C++ and CMake. Get off 'old' toolchains? Why is 'old' here 'bad'? Both are continuously evolving. 'Old' = proven = works.
> C++ is becoming a legacy language and finding contributors in the future will become difficult, while Rust has an active and growing community.
How is it becoming a legacy language? This is completely false and unsubstantiated. Yeah, finding good C++ devs is hard, the thing takes skill.
> Rust is what we need to turn on concurrent function execution.
https://en.cppreference.com/w/cpp/language/coroutines
You don't need Rust here. Good try, though.
> 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.
However, that doesn’t mean it’s always super easy. C++ interoperated with C even more easily: just compile your code with the new compiler! With Rust, it’s more like FFI.
https://cxx.rs/ is at the forefront here.
> 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!
The best time to start rewriting everything in an ML-family language was 20 years ago; the second-best time is today.
Edit: I assumed that "ML" here stood for Machine Learning, it appears that was not the case.
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)
As of a year ago, 10% of FireFox had been ported over (https://news.ycombinator.com/item?id=30744057). This is the overall effort started in 2014 https://wiki.mozilla.org/Oxidation
This can show you certain data. I’ve linked to Q4 2022, specifically PRs opened. You can see C++ at #4 with 9.7% of PRs, and Rust at 14 with 1.6%.
Rust users are also going to be biased towards GitHub over other places.
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.
Fish porting itself to Rust makes me more likely to contribute to it in the future.
/anecdata
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.
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
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.
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.
than cloak it with some weak sauce reasons.
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.
That said, maybe this is too negative a perspective and maybe useful contributions will outweigh the noise
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.
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
I'd rather have really good defaults and the option for configurability rather than not great defaults and really advanced configurability.
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.
What article? It's a pull request by the maintainer.
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.
And that's basically the reason most projects do it.
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.
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?
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.
(I kid, I kid)
More seriously, good! Should be a fun exercise. Would love to see thoughts on what went well and what was hard to do.
sigh
https://old.reddit.com/r/rust/comments/10pf7m8/fish_shell_po...
But I agree that they are actually doing the work and not just tossing out a suggestion and that’s great.
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.
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 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.
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.
A language stops being "new" when debian stable's previous release supports it as fully as Arch's current beta.
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.
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.
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.
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.
It also probably isn't in their interest to split the community (Also, as a fish user, I also personally wouldn't like if the community split)
Edit more here: https://github.com/ridiculousfish/fish-shell/blob/riir/doc_i...
I've not had problems with latency in fish, but the promise of rust is that there is so little latency that it heralds a close to the metal feeling I've not seen in decades.
I think that feeling is visceral and laudable, regardless of the actual runtime profile. It's under-appreciated in the design community. IPC latency is as big a problem in operating systems and programming languages as RPC latency is in cloud systems.
I have no experience with rust, but I do depend on helix daily:
https://github.com/helix-editor/helix
and helix is rust.
I think this kind of open source experiment is exactly what we should be encouraging because it's forward-looking and straightforward to test.
I think the fish community could decide easily by A-B testing the Rust and C++ builds with real users and see how they compare in terms of reliability, performance, regressions, time-to-fix, and so on, assuming the team has the bandwidth to absorb the sideways nature of the work without derailing fish.
To me, rust is more than trendy and I can remember the first time I touched Walter Bright's work decades ago, so I'm open-minded about D too. A simple KLOC or cyclomatic complexity as a proxy to abstraction would be an interesting lens.
> 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.
Anyone else notice this unique phenomenon? I can't think of any other language community that does this.
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.
Is it really?
> Anyone else notice this unique phenomenon?
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.
Where does motivation like this come from?
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 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.