There's a lot of stuff I could say here, but I'll stick to
> Attempts to integrate it with other build systems have been met with hostility from the Rust & Cargo teams.
This is very much not true. We've put in a ton of work to support this. Arguably, we've put in too much design work and not enough implementation work; we've had a few different attempts at making this work even better than it does today, and we haven't finished them up. But this is very much something that is cared about and desired by the team.
> Rust should integrate easily into large build systems. Plans include working with large companies incorporating Rust to understand how best to equip Cargo to smooth the process.
It does sound a little snarky but at the same time it's a real good point -- the article says "... met with hostility from the Rust & Cargo teams" and yet you cite "largely based on this discussion [of some other team using Rust to develop their project]."
So if this is an error on your part, maybe you could issue a correction without a specific comment or rebuttal from anyone.
EDIT: your edit makes you seem a little rash. I get that it might be overwhelming because the Rust Evangelism Strike Force (†) has showed up here but take some time to appreciate what folks are writing. Your article regarding Rust is naturally controversial and is filled with good points and bad ones. People will naturally pile on the bad ones.
(†) Tongue in cheek, I'm probably a charter member
It's a pretty wild world where someone makes a claim about an entire project charter based entirely off of a single random comment on github, and then the folks who claim that's wrong and cite project documentation are "the Rust Evangelism Strike Force," even in jest.
Your article includes a fully unsubstantiated claim based on a discussion from an unrelated project. Asking someone else to do something to fix your mistake is ludicrous and is in no way "offering an olive branch".
This is a very bad look, actively looking to punish others because they didn’t “accept your olive branch” after pointing out a mistake. I’d recommend you rethink your approach here.
I didn’t read the entire thread, but if I understood the gist of it, it seems like an anti-pattern is being asked for, and it would be an anti-pattern when mixing any languages. What it seems they want is the ability to mix Rust and C in the same build chain, not treat each as a separate build artifact and link at the end.
I’ve never had a problem modeling things with Makefiles, having the Rust artifact target be built by Cargo and then linking with the standard toolchain for C in the Makefile.
I’m clearly missing some context, as this works really well.
Yes, there's a ton of ways that you can do this. Most successful integrations thus far have done exactly that: you have a target for your Rust code, it calls out to Cargo and does its thing, and then links it in. I believe that you're right that the Meson folks want to use rustc like they use cc, and use Meson for all of the stuff that's not "compile this, please."
This can work well as long as you're writing all of your own code. The issue is that most people like Cargo, and like using Cargo, and so virtually all open-source projects are built around Cargo. This is not unlike if you're a Meson fan, but you want to use an open source project that uses CMake for its build, and so it's only really set up to use CMake. (At least, in my understanding.)
Well, then the comment they made about essentially rewriting Cargo is probably accurate.
Doesn’t seem like it’s a valuable contribution to their end goal though.
I do want to point out (for others, you know this) that Cargo has a lot of environment variables that can be used to improve its usage inside other build systems, e.g. using a shared target directory for reusing compilation of dependencies: https://doc.rust-lang.org/cargo/reference/environment-variab...
Right, that's why we introduced the build plan feature, so that you don't have to re-implement Cargo, you can use Cargo to spit out the stuff you need instead. :)
Thanks for posting that. I understand what they’re getting at, but they didn’t quite convince me in the opening that this isn’t a build structure problem vs. a build tool issue. There’s a lot of work to do what they’re trying to achieve, and at best you’ll possibly get a faster build? Maybe it’s easier to configure? Though that also wasn’t obvious to me that there would be a large gain there.
There's another post explaining why Meson is trying to do what it is trying to do. My takeaway was that having a single universal build system is easier to deal with than multiple splintered ones, full of duplicated effort:
I don't see anyone in that discussion who is on the Rust/Cargo teams.
I see a bunch of disagreement from people involved in gstreamer/meson (and some other non-team folks), which makes sense, disagreeing with something on your own project isn't external hostility, it's how decisionmaking works.
Does build-plan help with the case of including an artifact from another build system (e.g. data file for code-generation like SVD or libs to link against)? What about someone not using build-plan but publishing crates, whether external or internal?
Speaking of, alternative crate indexes are something I think we need to do at some point for improved corporate support. It'll be interesting to explore the requirements. Some I can think of include
- Publish internal-only crates
- Some companies might want purely internal mirroring (for secured systems)
- Some companies might want a read-through cache to self-host what they use (for life-cycle management)
- Some companies might want to exclude crates (for extra-cautious licensing validation) which could make it hard to use anything unless we can also transitively exclude things
build-plan is meant to be able to expose to an external build system the stuff that Cargo would want to build; it's not meant to talk about artifacts from other build systems. It's meant to help Rust fit in there, not to control other parts of the build.
> Speaking of, alternative crate indexes are something I think we need to do at some point for improved corporate support.
not a great article, but also not a great response
articles like what was posted are frustrating and can clearly hit a nerve, but instead of being defensive, try to use the feedback as indication that the work that's been done may just not be recognized, instead of it not being done
There are constructive comments and then there are very opinionated rants. Eventually you just have to realized that you cannot always make everyone happy, in this case, a grumpy C programmer who tries to start a flame war.
> Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows. I especially refuse to “rewrite it in Rust” - because no matter what, rewriting an entire program from scratch is always going to introduce more bugs than maintaining the C program ever would.
And that is why we can't have nice things.
"I don't really care" if someone overflows my buffer to execute code...
And:
"going to introduce more bugs" - false. Empirically complete bollocks...
I wish the article had started with “I don’t really care” about safety, and by extension, security issues.
It’s putting your head in the sand to hold this perspective in modern computing. The funny thing is, I don’t disagree with the author’s contention that Rust derived from C++, but this completely ignores the fact that C++ directly derives from C!
C++ wanted to make certain patterns in C easier, and to reduce certain foot guns. Rust is in essence, a reimagination if that same effort, but includes the next 30 years of language research in its design to overcome those same problems.
So Rust does derive from C. But who cares? It’s a different language, if you like Go more because it’s closer to what you think of as C, then use that. But don’t kid yourself that C safety concerns don’t have practical implications in the real world.
I would say if you rewrite it and have more bugs, you must have no understanding of the existing codebase, or understand so little of it you shouldn't be the one rewriting it regardless.
All the rewrites I have done have resulted in leaner codebases with fewer potentials for bugs. I think people take some article one software developer wrote almost two decades ago as gospel, but "second system syndrome" doesn't have to be a syndrome.
This "rewrite" fear is exactly why our banks are stuck on 1970s and 80s code with an almost 60 year old programming language and no one left to take over maintenance. Eventually we need to get over this fear.
Absolutely, and some people _really_ care about these things. Especially in my domain where things are safety critical like avionics/robotics we absolutely do not want to segfault and fall out of the sky or have degraded capabilities. I have found a lot of interest in using Rust in this domain exactly because of the safety. Especially with the awesome work that RustBelt[1] has done.
Further a compiler that verifies memory safety for you can save an incredible amount of money when otherwise you would need to manually prove memory safety.
Yeah that's what stands out to me as well. I wish the author had put that sentence at the top. The biggest feature of Rust is it's safety. If you don't care for the biggest feature of a language then it shouldn't be a surprise that you don't like the language.
Having written Rust code for 4 years, I'd say it's not the biggest feature of Rust. It's just one of many good points. Among my favorite are the explicit & rich APIs, high level concepts (ADTs, pattern-matching, trait-based generics), and Cargo. The safety does play a big role in shaping some of the features though, and enabling some powerful APIs and optimizations.
I'm not sure why a programmer who is making something for others would even say 'I don't care'. Someone wrote a post saying that python was slow and they don't care.
Users do care. They care if something is fast, they care if it bloated and takes forever to load, or if it crashes or if it is insecure.
Sure you can have nice things, they're there - just use them to create the 'next big thing' and the nice things will hitch a ride on its fame. Trying to push others to use those nice things does not work as long as those others prefer to use what they consider to be their tried-and-true older but nicer things.
imho he probably meant for experienced engineers we don't really care because knowing what's underneath is way more expert than learning another language/funny syntax which tries so hard using name mangling type system to hide it.
> C has a spec. No spec means there’s nothing keeping rustc honest.
Agreed, language specification is critical. The language reference [1] is very detailed, though. I'm not sure what it would take to promote this to a "specification."
> That really cool feature $other_language has? Not interested. It’ll be more trouble than it’s worth
Binding to "editions" is a reasonable way to get stability, IMO. It's a shame that this wasn't adopted earlier.
> Concurrency is generally a bad thing.
So don't leverage it. Don't use fork() or clone() either and we'll all agree to ignore this point.
> Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows.
Here underlies the crux, you should have led with this. This is a sizable portion of rust's value proposition. If you don't value it then it's likely not to measure up well.
> Rust will eventually fail to the “jack of all trades, master of none” problem that C++ has.
We have to take the good with the bad in everything, right? If Rust's future is "spectacular failure like C++" then it's probably going to be a wild success.
> > C has a spec. No spec means there’s nothing keeping rustc honest.
>Agreed, language specification is critical. The language reference [1] is very detailed, though. I'm not sure what it would take to promote this to a "specification."
But even the C specifications is mostly informal, there are some parts of C that has formal specification but to my knowledge not everything is. Where as something like SML has a full formal specification. Which mean that you do not have any undefined behaviour.
Correct, both of which you have to take into account when picking a programming language today.
>We have to take the good with the bad in everything, right? If Rust's future is "spectacular failure like C++" then it's probably going to be a wild success.
I wouldn't call C++ a wild success. It's failed to supplant C for its entire life, and thrives only in a few niches.
> Correct, both of which you have to take into account when picking a programming language today.
Shrug, you're not really wrong. Early adopters of Rust will suffer (have suffered) some issues. Maybe you can try it out in 2060, when Rust will be around the age C is now. To Rust's credit, for this metric it's around ten years further along than any other language that we could propose to supersede C today.
> I wouldn't call C++ a wild success. It's failed to supplant C for its entire life, and thrives only in a few niches.
I disagree, but I'll admit my bias here having spent very nearly all of my career working on C++.
i disagree with the main article, but he is right. C++ was supposed to be more than just browsers, GUI and video games: it shuold have been a better C. It failed. It was supposed to be more secure than C. It failed.
Mostly the OOP failed part, because it wasn't that good of an idea (usefull in some case, to do geometry and grapic stuff, and for other, specific cases). And Java's "everything is an object" did not help C++, with countless students trained on Java then writing software with C++ and doing awfull things everywhere. C++15 is really fun to work with in new, clean projects, with either new or very ancient C++ devs, but i would get away from any proposition including a pre-2013 C++ codebase and any "rockstar"/"genius" C++ dev with 2-10 years of C++ experience as a lead.
And by the way, nowadays python and Js replaced C++ in the GUI usecase (yes, electron is written with C++, this is not my point).
The standard of success is not "we don't use C anymore", that's an insane definition of success. By that definition C didn't succeed in knocking off Fortran.
> But now you know why we are still writing C, and hopefully you’ll stop bloody bothering us about it.
I don't think anyone will stop bothering them about it until C software security improves. Microsoft found that 70% of security bugs in their software were memory safety issues:
A little controversial, but I would have liked the larger programming community to address this rather than write completely new languages.
Think of all the effort that has gone into rust. Compilers, package managers, libraries, etc. What would have happened if that same effort went into better analyzers, linters, compilers, etc, for C/C++? Rather than rewriting everything to be made "perfect" (which will never happen), this would be applied to the metric shit ton of existing code, making it better. Not perfect, but better.
Of course that work is dirty and necessarily political, and making a new language is sexy...
The reason that this wasn't done is that we believed (and it still seems to be true) that you cannot make C or C++ be memory safe at compile time. Or rather, you cannot do it without introducing backwards incompatibility, which means you're effectively making a new language anyway, and something that's a non-starter for those languages. (as it should be, IMHO.)
It had nothing to do with "sexy" and everything to do with engineering goals. I assure you, a lot of work in Rust is dirty, political, and not sexy too :)
There is already a metric shitton of work being poured into making C safer. Everybody realizes that most existing C code will be used for a long time. That's why we have a bunch of different sanitizers, fuzzers, static analyzers and so on. The problem is that these tools only find a fraction of the possible memory corruption bugs you have and many people don't even bother to use them. You can still find bugs in many open source projects with a simple fuzzer. Sanitizers are only as good as your testsuite, but except for SQLite, which project has extensive coverage?
As someone who has dabbled in the C++ program analysis space before: A _ton_ of effort has gone into this already. There's also a lot of promising stuff there already.
There's active research on how to best do aliasing/pointer analyses, both for optimizers and for linters.
I've often said that the holy grail of C++ program analysis is aliasing info that is perfect, local, and can be computed in a reasonable time. The current situation on this is basically "pick one", _sometimes_ "pick two" if you're good. Rust's design gets you all three by picking different defaults and asking for some extra annotations from the user. The kicker is: it's all based on existing research!
Firefox has its own static analysis and IIRC has looked into other static analysis stuff (the GC analyses are pretty awesome). C++ static analysis is good, but not good enough, in this case at least.
To me, it's quite clear: the target language would have forked from its base, creating of necessity an incompatible ecosystem (no one wants an improvement after which you still can still make the same old mistakes, and some mistakes are emedded in the C/C++ syntax), and we'd end up with something slightly worse than Rust, using somewhat more familiar tools.
I know the kernel is not the C language, but I think the efforts being undertaken to harden the kernel (use of syzkaller, etc) provide a good roadmap for C programs in general.
The Chrome team is working really hard to secure their program. They're also really good engineers. Yet there are still lots of memory corruption bugs in Chrome. That makes me believe that it's impossible to write safe C++ once your code is sufficiently complicated. I don't think C fares any better on that front.
> Static checking enforces the integrity of the bounds information and allows the eliding of some dynamic checking. Dynamic checking enforces the integrity of memory accesses at runtime when static checking cannot.
This is an OS problem, Rust won't save you there because you're going to use unsafe anyway, in Rust you would create wrappers for the unsafe part, they probably do the same in C/C++ for OS, you don't use unsafe / low level things for higher part of the OS.
Redox is an OS written in Rust and had kernel panic with bad arguments passed to a user space program so ... ( it was a community challenge from 2 years ago )
I think Rust has a good vision for security but it's clearly not bullet proof as people seem to think, especially not on the low level fields like OS.
> you're going to use unsafe anyway ... you don't use unsafe / low level things for higher part of the OS
It seems as if you contradict yourself here. Or are you trying to suggest that Microsoft's bugs were confined to the "lower part of the OS"?
> so ...
So, what, exactly? Your point is not clear. Redox used Rust and held a challenge to find bugs in Redox -- which was succesful at uncovering bugs in Redox. Ergo, what? "memory bugs still exist when programming in Rust"? Or "We haven't completely extinguished this kind of bug, therefore we haven't improved over C." It sounds bogus when I try to guess at what you're implying, so please clarify.
The whole unsafe escape hatch was designed to imbue the flexibility required to cover the design scope required for system software. Don't fault Rust for adding it. Credit Rust for Redox's stability after they did this challenge.
- Redox is built in Rust and had serious memory bugs triggered by userspace applications, people claim that we should build OS in Rust because it's "memory" safe, in reality it's much more complex than that
It did not have serious memory bugs. All of the unsafe code in Redox, of which only a small fraction is unsafe, is neatly compartmentalized so that it's easy to audit.
The main fallacy of this blog post is that he wants it to be one single programming language that replaces C.
C has actually been already replaced mostly. C++, Java, C#, Python, Ruby, Go, Rust, etc. have been chipping away for more than 20 years now at C's market share.
What kind of project can you seriously start today in C because there are no better options available?
My guess is embedded programming and kernel programming and for both of these usecases we feel the pain and would actually want something else.
> Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows.
Old C programmer yelling at clouds?
> Consider Go, which has had a lot of success in supplanting C for many problems. It does this by specializing on certain classes of programs and addressing them with the simplest solution possible. It hasn’t completely replaced C, but it has made a substantial dent in its problem space - more than I can really say for Rust
Go is IMHO a nice language and I would have been delighted to have it in the 90s. But nowadays it already feels outdated on arrival.
Lately I've been noticing more and more tools being developed with Rust. Some things take time, I wouldn't already write off Rust yet.
I like that go feels sort of quaint and outdated. It makes it easy for pretty much everyone to jump in and contribute to a code base without having to learn too much. Rust is great, but it is not a language you can just jump into.
>The main fallacy of this blog post is that he wants it to be one single programming language that replaces C.
That's not at all what I'm suggesting. In fact I thought this part of the article makes it clear that I feel the opposite way:
>C is far from the perfect language - it has many flaws. However, its replacement will be simpler - not more complex. Consider Go, which has had a lot of success in supplanting C for many problems. It does this by specializing on certain classes of programs and addressing them with the simplest solution possible. It hasn’t completely replaced C, but it has made a substantial dent in its problem space - more than I can really say for Rust (which has made similar strides for C++, but definitely not for C).
The keyword here is completely. Rust doesn't need to completely replace C, it only needs to cover those usecases other languages haven't already covered. Or maybe just some and a completely different language takes what is left.
You don't care that Rust is much more safe than C due to all the features it has that are unlike C. But the safety aspect is Rust's main raison d'être.
If you dismiss this outright, you could have written a much shorter article or at least written a much more interesting article by starting with this admission and from that working your way through Rust's feature and explaining how this doesn't alleviate the warts of Rust.
> But now you know why we are still writing C
I wonder who this "we" is?
I'm also still writing C but for quite different reasons. Mostly because of legacy code and to some degree even just to be able to claim that I'm working on 35 year old code.
> You don't care that Rust is much more safe than C due to all the features it has that are unlike C. But the safety aspect is Rust's main raison d'être.
Rust is still young. I think it's a bit naive to proclaim the language of the future is here. Why?
That was also the point of Ada until people realized that unhandled Constraint Errors could still crash missiles.
> Rust is still young. I think it's a bit naive to proclaim the language of the future is here.
I never claimed that Rust is the language of the future. I didn't say it directly but I think you can deduce it from my comments that I consider a multi language approach more sensible than using the same programming language for everything.
Using Rust is more safe than using C. That's valuable.
> So, what's the point of Rust again? To protect us from all these security holes? Wasn't that also the goal of other languages?
Are you saying that just because Rust doesn't solve all problems it isn't worth having? You're also conflating stuff.
The Ariane 5 explosion was not a programming error, it was a testing and specification error. The code worked exactly to the spec but the spec was for another piece of hardware. You can't use a fork and complain that it's not a good spoon.
How about quantifying the bugs in the JRE against all the buffer overflows in similar C code? 600 CVE worthy bugs in 10 years doesn't sound like that much if you put it that way.
> TIOBE says C is second most popular language after Java even with all the security holes. So there's a lot of "we" (though I don't code in C).
The TIOBE index has some issues. It is essentially counting hits for a search engine query for a specific language. I would rephrase it as "C has the second most webpages on the internet."
On PYPL it is only the 6th popular language, although coupled with C++.
Nevertheless there is still demand for C. Otherwise we wouldn't even have this discussion at all. But most people would rather see this demand decrease as we haven't been able to fix the language in the last 30 years.
> The Ariane 5 explosion was not a programming error, it was a testing and specification error.
What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unknown inputs in C, btw.
It's worth noting that this was one of the primary reasons that Ada got less and less traction in the US government, as Ada was supposed to prevent things like this from ever happening.
> What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unknown inputs in C, btw.
That's immensely different actually ... One is undefined behavior, the other is defined but crash. In the first case the problem can stay unnoticed almost forever until somebody exploits it. In the second case, if you actually test and cover your code, you will catch the problem.
Short for using a proof technology (which Ada enables and makes easy because of the large palette of constraints you can add on types), there is NO language that can statically guarantee that your program won't crash at runtime. Yes, Ada is not special in that regard. What Ada guarantees is that it will crash, so you can actually catch those kind of bugs in testing. Also nowadays you can use SPARK Ada to formally prove your code correct. https://en.wikipedia.org/wiki/SPARK_(programming_language)
Blaming on the language what is actually bad testing/architecture is pretty unfair.
> It's worth noting that this was one of the primary reasons that Ada got less and less traction in the US government, as Ada was supposed to prevent things like this from ever happening.
Do you have any source for that ? From my sources, Ada got less and less traction because of various reasons, one of them being the price of compilers at the time. I have never seen anybody saying that it was because Ada was "not safe enough", and even today it stays one of the safest languages out there in many aspects.
> Blaming on the language what is actually bad testing/architecture is pretty unfair.
I think we can both agree that a SEGFAULT and an unhandled CONSTRAINT_ERROR lead to program termination.
Your right in that at least Ada raised a CONSTRAINT_ERROR. But -- the cause for a CONSTRAINT_ERROR and a SEGFAULT in this case are the same: bad handling of inputs to a function.
So in this case the results would have been the same as well. In either case it comes down to design and proper handling of inputs.
So I don't buy your argument that it is different because of undefined behavior vs. defined behavior. Ada 83 had undefined behavior, too. It's just that Ada coders (well the good ones) knew to avoid it.
> Do you have any source for that ? From my sources, Ada got less and less traction because of various reasons, one of them being the price of compilers at the time.
Having worked in a Large Defense Corp(TM) during the height of the Ada popularity, it became pretty clear that the cost of a compiler for a $100mm program wasn't really the issue.
The GNAT Ada compiler came out in 1995, and I know smaller defense contracts used that as a viable solution to write software.
The primary issues with Ada were:
1. Ada was oversold and underperformed. The Arianne-5 was the kind of tragedy that Ada was supposed to prevent. Interfacing with external systems was a pain. Tooling was a pain. The resulting executables were HUGE at the time.
And then the development itself was expensive. Towards the end of my time writing Ada, our group was coding at the rate of 2 lines of Ada code / developer hour. Compiling took hours, running and testing took hours, etc. So a 20 line code change might easily result in 10 hours of a compiling/testing cycle.
2. No code reuse across defense contractors. Ada didn't have a package manager at the time, and while there were software libraries, there weren't a lot of them. Not like the C/C++ or later the Java world would have. So if you needed something, most likely you had to write it from scratch.
3. Java got popular around 2000ish and showed what a great software ecosystem looked like. Around 2005ish most new successful defense development was on java.
> What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unknown inputs in C, btw.
That's completely wrong. It was an integer overflow. One that could not happen on Ariane 4 but because of different hardware specs. But that was only the end of the chain of fails that lead to the crash.
Ada is of course completely able to handle such a problem. But the programmers evaluated this and consciously decided not to handle it for performance reason and because it shouldn't happen anyway. But it could happen, just only on the Ariane 5.
Sorry to be blunt but I don't think you know as much as you think you do. You should read up more on the incident. You could even read the post mortem report. It is available on the net.
That's certainly an opinionated opinion but Go feels like dragging C half-way to the 21st century. But unfortunately not all the way.
Besides the very good concurrency support it doesn't feel much different than a polished and somewhat modernized C.
Of course, depending on what you want that will be considered a feature not a bug. There's a reason so many C programmers jumped on it because even hardcore C programmers couldn't really ignore the language anymore.
Also look at the project management. The drama about the package manager was hilarious bad PR. I wouldn't want to invest too much time into a programming language that can't even agree on a package manager and needs 4 different tries to arrive at a solution with potential security implications.
I agree with the overall conclusion. Zig is aiming at being a C replacement. Rust is very much more in the C++ space. But a lot of the individual points seem off the mark.
> Concurrency is generally a bad thing. A program which uses poll effectively is going to be simpler, reasonably performant, and have orders of magnitude fewer bugs.
One of the benefits of Rust is that provides a lot of checks on concurrent code to prevent you doing stupid things, so you get the benefits without these costs. It's not perfect, but I've personally had zero issues with concurrent code in Rust. This is actually a benefit Rust provides even over other memory safe languages like Java.
> C has a spec.
Yes, C has a spec. But a ridiculous number of things (in a modern context) are left as undefined behaviour in that spec, meaning that it is very easy to accidentally violate the spec. Rust doesn't have a spec yet, but it has far more safeguards which make it much easier to avoid weird unexpected behaviours in practice. A full spec will come eventually.
> One of the benefits of Rust is that provides a lot of checks on concurrent code to prevent you doing stupid things
Well, here's the kicker. Nothing about rust forces you to use concurrency. Saying "Concurrency is bad, therefore rust is bad" makes no sense. There is nothing that forces you to spin off new threads in rust, just as there is nothing that forces you to spin off new threads in C.
In fact, it is pretty rich complaining about Rust's concurrency story while praising Go. A HUGE selling point to go was/is goroutines! The language was even given keywords for making concurrent actions!
Most of the author's points here derive from the fact that C has been around for nearly 50 years and Rust a mere 8. This post should really be titled "Rust is not a good C replacement _right now_".
Yes, Rust still has a long way to go to be the right tool for all the things you can do with C today, but that doesn't make it less. It clearly has benefits when writing concurrent and safe code. You pay for this with a learning curve, but the Rust team has been shaving this curve down through better tooling and documentation for the past few years.
> Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows.
I suspect that for the author's work, these things may not matter much. But to a programmer working on any software where security is paramount (many web infrastructure pieces), this feature is golden.
I expect that as Rust matures, we'll see a solidified spec, competing implementations, and expanded build tooling. C has a long head-start, not to acknowledge that is just wrong.
On the other hand, Go has a very readable specification that was written early and is maintained to always be up to date.
Why couldn't the Rust team maintain a spec and keep it up to date by changing it in the same pull request that changes a language feature in the compiler? This seems like mostly a matter of discipline.
> Why couldn't the Rust team maintain a spec and keep it up to date by changing it in the same pull request that changes a language feature in the compiler? This seems like mostly a matter of discipline.
It's not that, it's that we take the idea of a spec very seriously. We want to have a spec that's extremely solid, and so there's a lot of foundational work that needs to be done first. That work has been ongoing. Not all specs are created equal, and good ones take a lot of time.
For comparison, C was created in 1972, and the first specification happened in 1989.
Okay, but this seems like letting the perfect get in the way of the good? A maintained, readable, informal spec should be quite useful as a starting point for writing a more formal spec later.
It need not be definitive. It would be quite reasonable to point out areas that aren't nailed down yet - this is also useful for the reader.
It's useful but I'd like to see a bit more top-level completeness. Every feature should be listed and have at least a cursory description, even if it's not entirely nailed down.
(Maybe it already is like that, but the disclaimers say it's not.)
I don't know what the current state of affairs is, but this is something they have rightly delayed specing. The original borrow checking rules were quite byzantine compared to what we have today.
I don't know if there is active work going towards making them more relaxed (NLL landed I believe). However, a ton of work has happened to get them out of the way as much as possible.
The Rust team adopted a rule in December 2016 saying that all new language features must be documented in the language reference before landing on the stable release branch:
It's more complex than that. From a development standpoint, doing it this way was a real pain. This is due to the reference being in a different repo than the change itself.
We decided to relax this rule last year, and so instead, issues need to be filed. They then get filled in after. This has its own set of drawbacks.
Its not unreasonable to expect Rust to have looked at history, and improved upon it. To start out less than C means what? We don't want to wait 50 years for another language to 'mature'. Why can't it start out as good as, or even a step ahead of what came before?
That may be the source of the disappointment surrounding deployment of Rust - why is it behind and not ahead of other tools?
That doesn't make any sense. What do you mean "less than C"? Rust definitely looked at history and improved upon it, that's the whole point of the language! The author's gripe was that they feel Rust is evolving quickly much beyond C (like C++), not that it's trying to catch up on C. And do you really expect a language to just appear one day, fully grown, like Venus from a seashell?
The author's opinion of Rust being less is that, an opinion. It does have large advantages over C: memory safety, an incredibly powerful type system, a compiler that supports detailed error messages, a powerful build tool (Cargo), an expressive macro system, etc.
Others who have built applications with Rust seem to be coming away with a much different impression that the author. He does mention some gaps (lack of a spec, unstable ABI) but these are not hardstops for all usecases. The main thread of complaints appear to be from lack of choice of tooling and compilers.
I'd wager that the advantages outweigh the drawbacks for many projects, though not all.
I read through the article and I recognized the pattern of an old C cave bear that refuses to learn new things and understand why safety and type theory matters. Lots of arguments made in that post are either unfair (i.e. the Cargo team stuff) or completely wrong.
Also, if you think Go is a replacement of C, I think you are not a real systems programmer. Go has a GC, in the first place: how can you seriously state it’s a replacement of C? Also, you didn’t mention it (voluntary I guess), but Rust does have a community-based mechanism to make the language evolve (RFCs).
About the number of features, those are mostly non-breaking changes additions. Rust has editions now. Just… do your homework?
C++ is mostly used as a OOPL. Rust has no concept of OOP.
> Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows.
Easy speedup of processors ended. Not using system resources efficiently is not sustainable long term. Mozilla created Rust to be able to use the multi-core hardware (especially on mobile phones), thereby improving battery usage as well for rendering web pages.
Rust has it's C++ style problems (compiling time, not good enough IDE support), but the dev team knows about them, and hopefully improve them in the next years.
Have you used cquery for example (https://github.com/cquery-project/cquery)? In my experience performance is excellent and it can even be used with large code bases like Chromium. Accuracy is perfect since it uses the same information the compiler has.
Yes, as cquery's README states it has a huge memory overhead because it basically just builds the project and keeps the info around. This is rather like how Visual Studio's C++ IDE support used to work, and it was not fun to wait for re-indexing after making edits.
Alternative Clang-based solutions reduce the memory overhead by doing more on-demand computation, more in line with how C# or Java IDEs work, at the cost of much higher latency because Clang is not designed for anything but batch compilation.
This also isn't a complete solution for accuracy, as it only really works if you're also building with Clang (or something close enough that Clang can emulate it).
Like I said, things have improved for C++, but it's nowhere near what other, more IDE-friendly, languages can do.
My guess would be that in C# and Java, re-indexing is faster, because those languages have faster compile times in general. Therefore I would put this as a compile time problem.
> This also isn't a complete solution for accuracy, as it only really works if you're also building with Clang (or something close enough that Clang can emulate it).
Well that's a bit unfair, because we're talking about C++, not a GCC or MSVC extension to the language. And if there's some other compiler that isn't standard comformant, I wouldn't put this as a IDE support problem.
Of course there are cases were Clang fails to compile standard C++ code, but those are very rare.
Yes- but not only are C# and Java faster to compile in general, they're easier to process small pieces of in isolation. C++ requires everything referenced to be declared previously even just to parse. (Modules should help here, at least, eventually.)
But even then, parsing is often required to do complex Turing-complete processing of templates and constexpr, since that determines something's role in the grammar. This forces an accuracy vs performance tradeoff that modules don't help with at all.
So it's not just a compile time problem that happens to affect IDEs, but also an IDE problem, because they can't take nearly as much advantage of the fact that they're only trying to analyze the code, not build it.
And language extensions are hardly unfair. In practice they're used all over the place, and people expect them to work in their IDEs, especially when they're off in some header they didn't write. (Attributes help here, somewhat, when compiler vendors can move extensions into them.)
> And language extensions are hardly unfair. In practice they're used all over the place, and people expect them to work in their IDEs, especially when they're off in some header they didn't write. (Attributes help here, somewhat, when compiler vendors can move extensions into them.)
It's a C++-as-it-is-used-in-the-wild problem then, not a (ISO) C++ one ;)
Anyway: I myself never had any problems, but all my programs build fine with Clang (as all C++ programs should IMHO).
>Rust will eventually fail to the “jack of all trades, master of none” problem that C++ has.
He's talking about C++ like it's some kind of failure and not one of the most widely used languages in the world. Sounds like the author just doesn't like C++, so it's no surprise he doesn't like Rust either.
>Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows.
"I don't really care" isn't a good reason for ignoring one of Rust's strongest points. If you're not an expert in C like the author, then this would be one of the biggest reasons for choosing Rust over C.
That being said, I agree than Rust isn't a good C replacement, mainly because it's more similar to C++.
I think a better title for this post would be "Rust is not C".
I'm also not sure how stating the number of features recently added to a 47yo language is very small and the number of features added to a 8yo language is very large proves any point.
That you don't care about safety or concurrency has nothing to do with the title, and frankly betrays that this article is more about Rust not being last decade's systems language as opposed to Rust being a good candidate for future projects that would otherwise have chosen C.
I've been waiting so much for a way to use rustup (and Cargo, but that's beyond the pull request a bit further down) behind a MITM proxy.
And since Rust has always been Windows-friendly, I had high hopes when someone actually started to implement this support (basically pass "-k" to curl).
Because I had fought with all kinds of git and curl configuration files, until I realized that those don't mean anything to rustup.
The implementation was critiqued in a very civil way. The author fixed the issues. Everything was ready to merge and... in walk some busybodies who under the pretense of caring about security (having no clue about the issue or modern Windows workplaces, and despite clear refutations of their concerns) have seemingly been able to kill this patch: https://github.com/rust-lang/rustup.rs/pull/1624/
"We need to discuss this with experts". I don't know where, I briefly searched for any such discussion. I guess there was none.
So a drive-by shooting killed a very useful feature. The saboteurs can revel in the knowledge that they drove away a new contributor (I haben't seen any more activity on that GitHub issue). And users suffer.
Thanks a lot! Sabotaging corporate users must feel very good.
I don't know why back-to-back SSL proxies were never afforded an officially sanctioned mechanism for explicitly delegating trust. The alternative is this "I know you're lying, but I love you too much to leave you" mentality.
If you're asking package managers to facilitate such a morally compromised relationship, your best bet is to make user intent explicit and circumscribed. One way to signal that intent might be to adopt a trust-on-first-use approach:
> A program which uses poll effectively is going to be simpler, reasonably performant,
Only for newbie values of "performant". I work on data-storage servers. It has been quite a few years since I've worked on one that didn't absolutely need to take advantage of multiple cores to get competitive performance, and I'm very far from being alone in this need. Splitting one server into many separate processes is not a solution in these cases, as it just moves complexity from the in-process domain to the between-process domain where it's even harder to maintain good performance (or even validate correctness). As soon as I read "concurrency is generally a bad thing" the author lost all credibility.
> Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows. I especially refuse to “rewrite it in Rust” - because no matter what, rewriting an entire program from scratch is always going to introduce more bugs than maintaining the C program ever would.
Are they advocating for never rewriting anything? Like, programming language advancement should have stopped at C cause someone would have had to rewrite something and that would mean more bugs??
You don't have to care about memory safety, but if you don't you probably shouldn't speak for "systems programmers" as a whole. Systems need to be safe.
Thank you for that. Now that you've stated it so concisely, I can see how this is the thing that bothered me about the post. The author is implicitly trying to represent the C user base but doesn't seem to share that user base's concerns, priorities, or practices.
OK looking Just at the number of features seems disingenuous. Cpp features tend to idk, increase the level of complexity as there tends to be quite a bit of friction between them. Rust features definitely “work together”.
This post seems to have started with a conclusion and worked backwards.
Rust is such a breath of fresh air. Cargo is nuts. The community is nuts. I’ve been writing rust full time for a couple of months now and I’m not going back.
Also their development process is too slow. Like it would be impossible for me to pitch a new feature to cpp. I can imagine adding a new feature to rust (not that I would but I like that there’s the option).
I'm appreciating the irony of you complaining that "C++ features don't work together" but also saying that the process of putting new features into C++ should be faster. :-)
But isn't this how you end up with a 'bloated' language? Everyone has their own corner case, own little way the language can be improved. Over time, these will inevitability burden a language.
Adding features becomes necessarily bureaucratic as languages mature. You can't just add/change stuff without seeing how it interacts with everyone else, which gets difficult as languages grow and become popular.
I'm not sure why I'm being downvoted...I'd love to have an explanation from that person of how much diamond inheritance benefits our lives and makes it so much simpler to write maintainable code.
The current pace of development of C++ is questionable, but Rust is still a fairly young language, so the comparison to C seems unfair. Presumably, the rate of change in Rust will slow down. Although, if you are looking for stability today, the point does stand.
The converse is what I've heard with people at REN-ISAC and whom write and coauthor RFCs. (I'm not one, but trust the comments they've made to me regarding this.)
For a new dev to start writing internet-quality code, with C/C++ takes 10 years before they can make reliable code. The procedure takes what amounts to a journeyman style one-on-one until proficiency, 10k / 10 years later.
With Rust, it takes 2 years for a new developer to attain proficiency.
To me, those numbers are the ones that matter. Rust is stable and good, and gets out of the way of the developer... and gets in the way of the developer when coding anti-patterns.
Concurrency might be a dangerous thing but in microcontroller land, where I do my C programming, interrupts are a fact of life and just polling really isn't a practical solution.
Rust has no particular built-in model for concurrency or threading. The standard library currently exposes system threads, and we’re working on providing an API for pluggable concurrency models. The most popular of which is a wrapper around epoll/kqueue/iocp.
Rust has no particular built-in model for concurrency, but as soon as you want to do anything important with Rust (given the current ecosystem) you're going to run into Tokio, no? It seems to be the community-agreed-upon way to handle concurrency.
There are a number of different options. And today, yes, code is tied to one of them. But, and it’s not stable yet, futures and executors, the two traits, are being added to the standard library. This lets your code be generic over executors, and there are already more than just tokio. Including an embedded one, for example.
Traits are not implementations, just interfaces. There won't be an implementation of one in std, just the interface, so that the ecosystem can interoperate.
At the moment, I think Tokio is pretty great. I wish that there was more development bandwidth to help test out some cutting-edge stuff, but I think the design is sound.
It really depends, Tokio is the most popular at the moment. This is because most of the new ecosystem is built around these new, unstable interfaces. Tokio currently runs on the older, not in the standard library one. It's all a bit confusing at the moment, to be honest.
No. Rusts memory model allows for the program to be validated at compile-time. It means that broken concurrency code won't compile.
(In some cases, you may need to defer validation to runtime by using wrapper types such as RefCell or Mutex, in which case the usual cost of mutexes and the likes appear.)
However, what was referred to is using interrupts vs. polling on embedded hardware. This is very different from regular software development.
This just reads like the author was told to rewrite his code in rust one too many times, and he felt compelled to justify his own choices by bashing rust. Just say you like the simplicity and subtle bugs of C more than having to deal with the upfront complexity of low-level code at all times
My biggest quibble with the article is the idea that C will have a replacement. Many languages have already replaced C, in many domains. And yet C is still with us. I suspect it will remain indefinitely, shrinking in relative popularity but growing in the absolute sense. If for no other reason than that every language benefits from having a way of talking to libraries written in other languages, and the lingua franca is C. Rather than writing N^2 foreign function interfaces for N languages, each language can have one FFI library targeting C interoperability.
As long as you don't write software for computers that are connected to a network, it's fine not to care about security. For everybody else though, new software should probably be written in a safer language. That doesn't have to be Rust of course.
Personally, I think the C community is deeply infatuated with the idea that "we are in fact simple" mentality even though it's not well justified.
C isn't simple. C isn't simple to use.
On the implementation side, it has a complex calling convention. It relies on a memory management runtime without spec'd behavior. Tons of hardware implementation details leak up to the upper levels. C's error handling schemes are inconsistent, and thus complex to work with and to implement.
Being a C programmer isn't much easier either! C's memory managers tend to blow up if misused, but they don't blow up WHEN they're misused. They always cause problems, but it's not clear how or why. You have a bomb in your code that will go off in a random place. Even good debuggers with great tools can find it challenging to find the source of a double free. And that's alongside managing the weakly typed (not to be confused with static/dynamic) world, the pointer arithmetic, the inconsistent library conventions. Oh yeah, the libraries...
C's libraries aren't simple. They have to protect themselves from double inclusion, they can collide with each other, and have wildly different conventions depending on if they're loaded at runtime or compile time. Despite a constant derision of OO from the community, they often affect an "OO" discipline on methods. In reality this asks developers to create the impression of OO behavior by being very (very!) careful with call sequencing. And of course, the price of failure on most of these tasks is at runtime, on someone else's hardware, often with opportunities for remote execution.
When a C programmer says, "C is far from the perfect language - it has many flaws. However, its replacement will be simpler - not more complex," we have to read it very carefully and ask, "What does simpler mean?" Because despite the complexities of being a C programmer and the unstated complexities of the C runtime (and the large portion of unspec'd behavior so glibly ignored in this article to dunk on Rust), they still say "C is simple."
In this case, evidently it means: "Consider Go, which has had a lot of success in supplanting C for many problems. It does this by specializing on certain classes of programs and addressing them with the simplest solution possible."
Go isn't simpler. Go actually aims for a rather broad category of programs (it goes way up into the world of abstraction Python covers, and stops short of the embedded world where C is firmly entrenched because it's well-understood). Go has a sophisticated (and arguably, hard-to-use) concurrency model (didn't the author just say, "Concurrency is generally a bad thing?") and implementation. It has real garbage collection. Its stdlib is expected to have full SSL and networking support builtin.
But Golang is familiar to C programmers. I think that is why we see all the dunks on C++ and Rust in this artcile. C++ and Rust are weird. They're different. Go feels like C, so it's "simpler to learn" even if it requires a whole lot more core concepts and careful implementation than a C compiler.
Maybe Rust isn't your solution. Okay. Maybe C++ isn't your solution. Okay. There's still lots of other good languages to try. Languages that don't ask users to wade among a field of charged rails that the slightest touch can result in catastrophe. Nim or D maybe? There are others, and you can find them.
But continuing to use C with the attitude that, and I quote, "I don’t really care. In light of [the complaints leveled at Rust], I’ll take my segfaults and buffer overflows" is dangerous. It's unprofessional. It's reckless. It's also a false dichotomy.
The answer to C's problems is to stop using C. Not to start using something else specifically. This article makes it clear that the actual goal of this sentiment in the C camp is to keep using C. There isn't even a candid ownership of the problems with that strategy.
You can't overstate the importance of a specification. It is the most loathed thing to write, like unit tests, but in the end is essential. I think the OP romanticizes a bit: K&R C had a spec, a very very very loose spec. It took ANSI a decade to put some meat on it. Early C compilers weren't much help: Sparc had SystemV and AIX had POSIX which are OS specs but still defined C behavior in their compilers, and it made life so much easier in the early 90's when they converged on Gnu.
My favorite part of the article is the footnote. We really need to stop referring to C/C++ as "roughly the same" because they are so so so radically different.
K&R C had no formal spec. It wasn't until 10 years after its invention that it did, and that was after a lot of real-world experience.
I would argue that early specifications don't work out very well. In fact, they are often problematic. One example is that standard ANSI C had a proposal for a while that included an Alias keyword. This was such a bad idea, that Dennis Ritchie showed up to the meeting personally to help kill it.
Standards committees are not usually staffed with practitioners, who are busy developing the language and are quite expert in nuance, feasibility, and utility. Attendees to standards committee meetings are almost always not.
And reality does meet the standardization expectations quite frequently. Look at the number of "undefined" or "implementation choices" in C alone. Therein lie careers for security folks.
Should the HN rules be amended to discourage self-authored submissions? They seem to circumvent the natural filter that comes with peer-nomination, and suggests they were written with promotion in mind.
He's had some very high quality submissions of his own posts in the past, and contributes here regularly and to the benefit of most, I believe.
I don't necessarily agree with his conclusions, nor the way in which he defended some of them here, but it's pretty clear this whole comment section went to hell pretty early, and I don't think he deserves most the blame for that. I don't think most the Rust contributors or well known advocates do either. There was a huge amount of drive-by commenting where people seemed to sense the way the wind was blowing and thought it would be a good idea to pile on. That didn't help anyone.
Lack of a formal specification and/or an international standard is the real bummer. That's the biggest disadvantage in comparison to languages like Ada and C.
At this stage I'd settle for an informal language description, as long as it was a serious attempt to be basically complete and correct.
It's nearly four years since Rust 1.0 and the reference manual is still calling itself a best-effort document. It's surprising that a project which generally holds itself to high engineering standards is so sloppy in this one area.
> It's nearly four years since Rust 1.0 and the reference manual is still calling itself a best-effort document.
I'm curious what standard this is holding Rust to; C was 17 years old when a comprehensive reference emerged, and C++ was 13 years old for the same. If Rust manages to have a reference by 2030 (and I certainly hope it does) then it will be on track.
I think Go and Swift are natural languages to compare Rust to in this respect. Both of them seem to be doing a much better job of reference-level documentation.
In other circumstances the Rust people generally aim for higher standards than "no worse than C or C++", let alone "no worse than C or C++ in the 1980s".
(I mean, you don't see Rust people saying "It took 30 years for C++ to get any form of type inference, so as long as we have something by 2040 we'll be on track.)
(That's about the underlying pointer-aliasing model visible to unsafe code; the sort of questions that come up with C's "restrict".)
I don't think coming up with answers to those questions need have blocked writing that part of the reference manual.
One alternative would be to document what aliasing guarantees rustc currently does and doesn't pass down to LLVM, along with what (if any) promises Rust is making about which things that therefore currently have defined behaviour at the LLVM level will also do so in the final language model.
The point is that the current reference manual should document the compiler-writers' current understanding of what is allowed.
I think there is a gap in the market for small language which is just a "better C", but developing a new language is a great deal of work, and it would be hard to compete against the alternative of using a small subset of {Ada, Rust, whatever}.
Maybe the large languages should look at defining official subsets, to make life simpler both for programmers and validation. Ada used to have something of the sort (and still does for all I know).
I don't think they count as a "better C" for this purpose. I'm thinking of something aiming at the niche that C currently fills.
Having a garbage collector doesn't fit that, and Nim doesn't look small (anything with both destructors and exceptions is getting into complications rather beyond C).
It seems that the Rust community is already slowing down with new features. Have a look at "This Week in Rust" updates: the section "Approved RFCs" has the text "No RFCs were approved this week" almost every week now. There also was a discussion of designing 2019 as the fallow year and going more slow than before.
That's true, and personally, I hope it continues. However, there are some significant new features that have already been approved that are being worked on right now. e.g., Specialization, const generics and generic associated types. Each of these is somewhat significant in that they might alter how one might write some kinds of code today. But generally, they open new doors by adding more expressiveness to the type system.
from compiler's point of view, C++ doesn't really added that much features, and quite stable. imho i believe the C++ ISO committee does consider the possibilities compiler writers are able to implement these features.
e.g lambda expression, there's always operator() overloaded available in C++98; Variable template, only allowed in namespace, aka. static member data member in template type;
CTAD, take template function argument deduce mechanism and wrap-up for ya; auto, same as template argument, and C++'s template argument is the same as C's typedef, etc.
that is to say, to some extend, C++'s features are also written in C++. The new idea could think of is the r-value type, which invented to trigger move constructor, again, using the existing function overloading mechanism to do the job. This maybe not engineering friendly which the writer has to manually nullify the moved object's internal pointers as for Rust just using type system to prevent you from using it.
Sincere question, I didn't realize that Rust didn't have a specification. How can folk say Rust guarantees safety when it doesn't guarantee an implementation? I don't see how you could have one without the other.
Now, admittedly, the lowest level language I've used is Go!, so fairly abstracted (and no memory management), so I might be mistaken, but it doesn't seem like you can have safety without a specification.
> How can folk say Rust guarantees safety when it doesn't guarantee an implementation?
Just because there isn't a formal spec, doesn't mean that the underlying systems aren't built with some rules, grounded in computer science and math. We believe that the systems we've set up do guarantee those properties, even if they haven't yet been formally verified. And a subset of them have been formally verified, which also increases confidence.
Adding to that confidence level is empirical results: while people have found implementation bugs, which will always exist in any implementation, nobody has managed to demonstrate that the model is fundamentally broken. That it's been years, and many people have tried, also leads us to suspect that our conclusions are correct here.
Put another way: not all specs are equal. Some are formal, some are informal. Just having a spec doesn't actually guarantee anything either. Most languages don't have a specification at all.
Yes, it's basically about what you mean by "guarantee". Very few things are formally guaranteed. People tend to use "guarantee" to mean "I believe this is true with a very high level of confidence."
Totally agree with his observations but I disagree with the conclusion. C is a ok programming language. The first language that realises that simplicity above all is the most important feature of any language and uses the same safety measures like Rust is going to win over a huge user base.
Low level programming in a safe way is a complicated endaevor. The assembly language with a few instructions can be the ultimately simple language, but it doesn't offer the same features that Rust does.
While I am all for simplicity, I just don't think it's all that obvious that a language could possibly be simple, fast, and safe at the same time.
Taking a total shot in the dark, but I imagine AAA video games constitute a crap-ton of C++ codebases larger than Firefox, but I wouldn't know for sure.
> Attempts to integrate it with other build systems have been met with hostility from the Rust & Cargo teams.
This is very much not true. We've put in a ton of work to support this. Arguably, we've put in too much design work and not enough implementation work; we've had a few different attempts at making this work even better than it does today, and we haven't finished them up. But this is very much something that is cared about and desired by the team.
It was literally on the 2017 roadmap: https://blog.rust-lang.org/2017/02/06/roadmap.html
> Rust should integrate easily into large build systems. Plans include working with large companies incorporating Rust to understand how best to equip Cargo to smooth the process.
I don't know how this is framed as "hostility".
As one example of the work done here: https://github.com/rust-lang/cargo/issues/5579