Steve is too modest about the tests by the way. Lots of the conformance testing for Rust's compiler happens automatically. Herb mentions Perennial https://www.peren.com/ and Plum Hall https://plumhall.com/ for C++ and Steve says "I'm not saying that functions as a conformance test suite" when it comes to Rust's own compiler tests. But, while the Rust project itself does not perform conformance testing, Ferrous Systems does and so yeah, analogous conformance test suites exist and are run automatically.
So when Herb says "And in Rust's case, that's going to need to be built out" if the interview was taking place five years ago that's an important point. But it wasn't five years ago, it was only a few weeks ago.
> analogous conformance test suites exist and are run automatically
I'm not clear on how this is even possible. "Conformance" for C++ means adherence to the published ISO/IEC 14882 standard. In the case of Rust, it's "this is what the compiler does this week". Sure, a third party has built out a CI system for Rust and uses it provide evidence that Rust does what Rust does, but that's nothing similar to having evidence any random toolchain conforms to an accepted, published, international standard of what the C++ language does.
When it comes to providing test evidence for functional safety (for example ISO 26262 or IEC 61508) I can point to Perennial or Sold Sands results and say with confidence that my toolchain does what it says on the C++ box. When it comes to Rust, I can point to Ferrous and say "the core Rust language when built using rustc does what the rustc developers claimed it should do last week, excluding any crates or libraries." To which claim are you going to trust the lives of you and your loved ones?
They aren't analogous at all. There is just reams of marketing spin here and eventually it's going to kill someone.
Here the conformance refers to the Ferrocene language specification [1], which is being developed to be something akin to ISO/IEC 14882 for Rust in the future. In fact, this specification and the Ferrocene toolchain is meant to be ISO 26262 or IEC 61508 qualified, so it directly addresses your concern.
The comment posted by jamesmunns will do much better job in describing the exact details than mine (both comments happened to be posted within 20 seconds, huh), so I'll just add that standards are meaningless by their own. Quite a lot of people criticizing Rust for the lack of formal standards seem to assume that such standards will immediately improve something, but that's never true. Standards are meaningful only when they are maintained and can be enforced; many historical standards failed to catch up and fell into the oblivion for this reason. It doesn't even matter much whether the specification is written in "formal" prose [2]. I feel they are missing the fundamental reason why language standards can be beneficial in principle.
[2] Which is never "formal" in the mathematical sense. (Mathematically formal language specifications are quite rare, examples include SML and WebAssembly.) In fact, such formal writing is slightly better than informal writing only because such writing also aims to be unambiguous, and the formality itself is not that important.
> Quite a lot of people criticizing Rust for the lack of formal standards seem to assume that such standards will immediately improve something
Formal standards aren't just for providing a spec to be used in alternative implementations or somehow proving that the syntax is logically sound.
They are also the process of international representatives vetting for new additions to the language or breaking backwards compatibility which is what I would be criticizing the lack thereof.
Most "international" standards are international only because the corresponding standard organization is ultimately operated by multiple nation-states. In reality the organization just appoints some experts to write the standard and brand it with their blessing, so the standardization process is hardly international. For language standards, those experts typically include original designers and whoever wanted to standardize the language. (Otherwise why would anyone want to join this tedious process?) A diverse group of experts is very rare for such standards.
It is another myth or fetishism that international standards have some inherent mechanism to ensure the compatibility. Such quality can be only maintained when standard editors take care of that and there is a comparable industry support. Missing any one, the compatibility can be easily broken, and conversely any specification---formally written or not---can maintain the compatability when both are satisfied.
It has been fast-tracked from the Japanese standard JIS X 3017, and I think there was a strong incentive to standardize due to Ruby being the only current mainstream language originated from Japan. (I recall even the Ruby Association [1] is supported by Matsue, where Matz was born.)
For each release of Ferrocene, this is kept up to date, and the same as C or C++, what is specified and stable can be relied upon, and implementation details are implementation details, the same as it would be if you switched from LLVM w/ SolidSands' SuperTest suite to IAR or GreenHills' toolchains which may have varying impl details but still maintain conformance with the specification.
The majority of safety critical teams will snapshot a single toolchain for the entire development lifecycle (sometimes updating if necessary, very rarely), but Ferrocene is releasing updates that are approaching the full Rust cadence (IIRC they've discussed going to every other release, so once every 12 weeks vs Rust's 6 week cadence), with all of the verification required to ensure the specification is still complete, and all tests are passing.
There's still work to specify and test more/all of the core/alloc/std library components, as well as third party crates, but from a toolchain perspective, it is much closer than you are giving them credit for. Unlike many proprietary C/C++ toolchains or verification suites, the majority of safety justification artifacts are publicly browseable here: https://public-docs.ferrocene.dev/main/index.html.
(I am a former founder of Ferrous Systems, and one of the people that pushed for the Ferrocene project to happen, but haven't worked there for a couple years and have no monetary stake in them anymore - I think they are just still doing the right thing, and doing it well.)
"What it says on the C++ box" is indeed enough for (parts of) 26262
And that's a problem, because what it says is vague and not very helpful for the problem we actually wanted to solve. It's enough by fiat - the people responsible for 26262 wanted to be allowed to write C++, so the bar has to be low enough to be cleared by C++. This problem grows in magnitude as the software in a safety of life critical system grows.
To be clear: I don't think either of these general purpose programming languages is appropriate for use in safety of life applications. I think a provably correct program ought to be table stakes - But, a bar set low enough that you can write C++ is always going to be low enough for Rust to just step over it like it's barely even there.
If I’m being too generous in this discussion (and I was trying to be), saying “whatever the compiler does this week” is far too harsh. The Rust Project has a commitment to stability that they’ve followed through with for almost a decade now. The amount of times my existing code has broken has been very, very low.
Note that although this is a really good transcript (remember that awful auto-generated transcript for an interview (podcast maybe? I don't recall all the details) with tptacek way back? Not like that) it isn't actually written by a Rust or C++ programmer (or if it was they aren't paying attention) so e.g. it says "mute" because that's how you pronounce the keyword "mut" in Rust, just as C++ people often pronounce their "char" keyword "car".
That does seem to be also auto-generated; "Graden" instead of Graydon, "Rust Go-ish" without a comma, "Steve, of adding" with an excess "of" etc. I would say it is very good nonetheless, but those errors don't really feel humane.
I've been a long time considering that I should learn Rust. I am using Python as main language (for Machine Learning tasks) so I am at the edge:
Go with:
C++, because I used to code in C (for embedded, 8-bit microcontrollers) when I was younger and also for its possible advantage for learning some CUDA (this last thing is mostly for fun)
or
Rust, because I have some trauma for kernel panics with bad memory management back in the days with C, and because I want to build some tooling in a nice, efficient way
Learn both. Rust first, because it's a lot more approachable. Modern C++ doesn't really have much in common with C to be honest.
Also, you'd probably have found these quickly, but cppreference.com is the nicest C++ reference (!cppref on DuckDuckGo) and doc.rust-lang.org (!rust on DuckDuckGo) has the Rust standard library documentation.
In some way I am stuck because I don't want to dismiss any of these (kind of Buridan's donkey) but planning this in a sequential way seems smart and would end the inner monologue
Coding in C++ is very different than it is for C and you should not consider them similar in any way. They are now two very different languages and nearly all the idioms in common use in C are considered bad practice in C++. It has been many years since these two languages could be considered similar.
Exactly this. I've felt it while checking some C++ OSS projects, thinking "wow I am more Java than this, and I don't do Java". This prevented me directly jumping into C++ which would be the natural step coming from C (because in reality it's not the natural step)
One thing that surface tutorials in either C++ or Rust won't get at, which might worry your residual C programmer is: how the fuck can any of this be implemented efficiently on the machine ?
In C it often (too often actually but that's a different rant) feels as though what you wrote just translates directly into what the machine does, no surprises, so then it seems intuitively to make sense that this delivers good performance. And it's not anywhere close to obvious in idiomatic C++ or Rust, where yeah, "more Java" in some sense.
One option is to trust it, it's the fastest option as it's no work but you may find you can't bring yourself to do that.
Another option is to satisfy yourself by measuring, time it, or measure how big it is, now and again when you find something that seems like it ought to be dramatically worse - is it really worse? Huh.
The final option, which is very time intensive, is to learn the depths of how this actually works. That probably means learning assembly language, and a bunch of things about how CPUs work, how memory works, etc. If you never did this for C, I'd suggest not starting now as it's a huge time sink and is often going to shake what you thought you knew. But it's an option if you aren't satisfied by the other options.
You are forgetting yet another option which is widespread and common practice among serious C++ developers, which is to use the Compiler Explorer to see how the code directly translates into machine instructions. It is almost normal to always have this open next to your IDE if you care about performance.
Note that most people who use Compiler Explorer don't actually know assembly that well, but you don't need to know it to see what is happening at a basic level, which usually suffices.
However, it is not necessary to care so much about performance in most cases. The language is generally fast compared to other languages, even if you don't try to make it fast -- the compilers and the language spec usually have that outcome. But when you really want to squeeze out the most efficient code, Compiler Explorer is the way most people do it.
IMHO Rust is between C and C++: more secure and powerful than C, simpler than C++, but it has the potential to do everything.
If you already know C and Python, it would be a better and faster choice. I’m more a C++ expert, but I’ve written a few small command line tools in Rust and it looked a bit like the Python equivalents.
If you would have just learned it in the time you’ve spent considering learning it then you would not need to decide. Go download the rust book or lessons in the terminal. They’re great resources.
Imo C++ only makes sense if you commit enough time. If you are not planning to work with it as an expert I would look somewhere else.
I dont want to comment about rust, but personally I just don't like ideological people. Also some people seem to not understand, that the set of all valid computer programs is greater than the set of all programs that can be proved correct. It is a fact and can be proven.
Imo C# is a well designed language and would be the best start to learn more about a modern statically typed language. Swift is also interesting, but its mostly apple and has similiar ideologic problems like rust (e.g. pointers are evil).
Rust, the language can not push any politics. For me, technical stuff and politics are disjoint sets. I do not care at the least what the political leanings of people I work with are. To me it sounds as none of my business as what car they drive or what perfumes they like.
IF you learn C++ I'd suggest to use it as a nicer C, without any std:: or the million other complications. Write your own List / String classes for fun, they can't be much worse than the std ones.
Be aware that this is Microsoft/FAANG camp echo chamberly discussion lacking self criticism, very shallow and "safe" (pun intended) chain of though that sums up to basically here we are maintaining stuff for Microsoft, only mentioning c++ and rust, C# and Carbon.
In similar vein, just so happens that yesterday I listened to discussion to folks outside of bigtech camp and it was much more insightful and introspective, although it is with creator of Zig and Odin language themselves instead of mere evangelists and methodologist book sellers. "Boundaries of Language Design" with Andrew Kelley & Ginger Bill [1] https://www.youtube.com/watch?v=3K8znjWN_Ig
Not necessarily because they are in an echo chamber, but both languages are much younger than C++, C# and Rust. (I don't think Carbon even has a significant footprint to be mentioned by now.) I appreciate both languages but they have much long road to go, including the initial "production" version which Rust reached a decade ago.
I don’t want to have a fight, but this was recorded a few weeks before the safety thing became a big issue in the C++ world again, so that’s why it didn’t come up.
Rust isn't complex, low level and systems level concepts are complicated. Rust does a fantastic job at exposing you to the lower level with a very articulate syntax and philosophy of how to handle things in a fast and safe way.
I think C++ and Rust are just fine. What you call verbosity is actually essential information that some other languages are missing and by doing so, force terrible inefficiency upon the user.
> Ofc, the guy pushing rust in the kernel was from msft... obvious flashing red sign.
Rust is already in the Windows kernel for the code behind some syscalls, and there's a kernel driver framework for Rust. It's proven work that's already shipped to hundreds of millions of devices.
The metrics here, which seems to be alien to many real people or AI bots here, is that the syntax complexity is directly correlated to the difficulty to write an alternative _real life_ compiler of such language (not to mention the other issues...)
The thing with c++,rust and similar syntaxes, is they are at an absurd and grotesque scale in complexity compared to, for instance, C99 syntax with some bits from c11+ for modern architecture programming (dodging all the ISO tantrums like _generic, typeof, asset on steroid, etc).
Yes those words are fair, and not aknowledging them, or trying to dodge this reality, is bluntly hypocrit or you are the victim here, brain-washed, and I advise you to take a deep breath and reflect on that matter in order to get a better perspective.
Do I say C99 + bits of c11+ is "BETTER", certainly not, I am just saying this is a less worse compromise. And its syntax is already waaaaay too complex and should be simplified already... then c++, rust and similar, owww!
There is no argument or questioning here, only aknowledgement of a disturbing
absolute truth and fair critism.
And if fair critism means bad karma here, the problem is not with me, but with the karma.
> The thing with c++,rust and similar syntaxes, is they are at an absurd and grotesque scale in complexity compared to, for instance, C99 syntax with some bits from c11+ for modern architecture programming (dodging all the ISO tantrums like _generic, typeof, asset on steroid, etc).
The syntax is a tradeoff, almost always. For example, without the lifetime type in Rust, compiler cannot identify even in theory, what is the intended lifetime of that specific type and it cannot guarantee that use-after-free will not happen.
> which seems to be alien to many real people or AI bots here
Take personal attacks somewhere else. They're against the site rules here.
>Yes those words are fair, and not aknowledging them, or trying to dodge this reality, is bluntly hypocrit or you are the victim here, brain-washed, and I advise you to take a deep breath and reflect on that matter in order to get a better perspective.
I have to see it your way, or I'm either brain-washed or a hypocrite?
> There is no argument or questioning here, only aknowledgement of a disturbing absolute truth and fair critism.
There's no questioning, only absolute truth?
The world is more complicated than you think, with more trade-offs and less black and white. You need to take a deep breath and get a better perspective.
> they are at an absurd and grotesque scale in complexity
I'm sure you can understand, though, that other people will prioritize different factors in the pros/cons of each language.
For instance, as a dev that's well versed in type systems but with little experience of handling memory, Rust is basically golden compared to C or C++, because I can write code without fear, knowing that all of the discipline C/C++ devs is baked in a type system I'm used to.
> I am just saying this is a less worse compromise
In that sense, when comparing languages with different tradeoffs, people in different contexts will make different choices.
A compromise is necessarily context-bound, and saying which compromise you promote is just another way to talk about your own context.
Exactly, and my point is critism of those tradeoffs by shining light on some of their "cosmical scale"(the word is fair) costs... somehow completely ignored in this articles of this type... how convenient...
People are not equal in experience and knowledge, and it is very important to ring a different bell here to give them a significant other perspective which will impact their own choices... those very choices which other people will have to suffer if it happens they code critical open source software...
So when Herb says "And in Rust's case, that's going to need to be built out" if the interview was taking place five years ago that's an important point. But it wasn't five years ago, it was only a few weeks ago.
reply