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.
I'm offering you an olive branch here. You can pile on the snark, or you can take my offer to issue a correction to my article.
Edit: found the hostility. Fine, I won't issue a correction. I didn't find Steve's arguments entirely correct and I was willing to add a note to the page letting him share his perspective so the reader could make up their mind. Now I'm less open to that.
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".
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.
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.
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.
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.
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.
> 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...
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?
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 :)
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.
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.
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.
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.
> 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.
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).
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 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. :-)
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.
> 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 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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
>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 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.
> 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.
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 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.
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.
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!
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:
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
> 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.
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.
> > 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.
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.
212 comments
[ 2.5 ms ] story [ 206 ms ] thread> 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
https://github.com/mesonbuild/meson/issues/2173
If you'd like to share a short summary of your thoughts, I'll update the article with your commentary.
Edit: found the hostility. Fine, I won't issue a correction. I didn't find Steve's arguments entirely correct and I was willing to add a note to the page letting him share his perspective so the reader could make up their mind. Now I'm less open to that.
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
Share for those following along at home?
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.
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.)
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...
http://nibblestew.blogspot.com/2019/02/why-is-cross-language...
http://nibblestew.blogspot.com/2019/02/on-possible-futures-o...
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.
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
> Speaking of, alternative crate indexes are something I think we need to do at some point for improved corporate support.
Absolutely! We accepted an RFC here, and there's an unstable implementation https://github.com/rust-lang/rfcs/blob/master/text/2141-alte...
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
Does Tokio use polling under the hood?
Tokio wraps epoll/kqueue/iocp.
Is this implementation going to wrap epoll/kqueue/iocp?
Would you say Tokio has any drawbacks/flaws/design choices yo aren't a fan of?
What are the popular choices other than Tokio?
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.
(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.
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.
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.
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.)
One of the goals of this year's roadmap is to significantly improve the reference, by the way.
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.
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.
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:
https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
Languages like Rust are making an effort to address these issues. What's the roadmap for reducing the number of security flaws in C software?
Thoughts and prayers.
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...
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'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.
https://lwn.net/Articles/763641/
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.
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
And we're talking about a bunch of people randomly clicking / trying things, so imagine what's really inside Redox.
> 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 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.
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.
https://github.com/rust-lang/rust/blob/master/RELEASES.md
I would argue that cpp, despite being much older, is still adding features that are kinda backbreaking e.g. ranges.
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...
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.
[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
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.
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.
[1]: http://plv.mpi-sws.org/rustbelt/
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.
By the way, there is a lot of polyglot library code out there that is both valid C and C++, which is the reason for using "C/C++" much of the time.
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.
Actually, since language servers like clangd, cquery and ccls, IDE support is not a C++ style problem anymore.
(I work on a C++ IDE.)
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.
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.
> 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.
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).
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.
That may be the source of the disappointment surrounding deployment of Rust - why is it behind and not ahead of other tools?
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.
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.
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.
[1] https://doc.rust-lang.org/reference/index.html
(Maybe it already is like that, but the disclaimers say it's not.)
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.
https://github.com/rust-lang/rfcs/blob/master/text/1636-docu...
As far as I can tell after adopting the rule they didn't proceed to enforce it.
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.
Only bigger C++ open source codebase I can think of is LLVM. What else did you have in mind?
Many enterprises, particularly software-focused ones, are likely to have 30 million lines of code or more.
According to Wikipedia it's 47 years for C vs 8 years for Rust (as of 2019) - it's not that surprising that a 6x older language is much more stable.
Erm...
> 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.
Ok this is nonsense.
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.
>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.
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.
https://itsfoss.com/a-floating-point-error-that-caused-a-dam...
That was the point of Java until people realized that JRE's were full of security holes.
https://www.cvedetails.com/vulnerability-list/vendor_id-93/p...
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?
> I wonder who this "we" is?
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).
https://www.tiobe.com/tiobe-index/
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.
https://www.cvedetails.com/product/19117/Oracle-JRE.html?ven...
> 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.
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.
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 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.
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.
Why? What do you prefer?
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.
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.
> 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.
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!
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.
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:
Not that that would be easy to do, mind you.This is a function of popularity and time.
> 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.
[1] https://doc.rust-lang.org/1.0.0/reference.html
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.
Aren't web browsers one of the most used consumer software today? I wouldn't call them niche.
I think even going by that metric C++ does pretty good.
Not exactly "number of projects", but here are some numbers:
GitHub statistic: https://octoverse.github.com/projects.html C++: 5th place C: 9th place
StackOverflow survey: https://insights.stackoverflow.com/survey/2018/ C++: 10th place C: 11th place
> Consider that most web browsers also depend on a dozen or more C libraries.
That just shows that C is a wild success, too ;)
Has it supplanted C? Definitely not. But in some areas it did (e.g. game development).
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++.
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).
If it's worse and less secure than C, why is it so popular? Why didn't all people continue to use C?
>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.
http://sml-family.org/sml97-defn.pdf