Rust vs. C++: Fine-grained Performance
cantrip.org
cantrip.org
> Many variations [he's talking about Rust] that seemed like they ought to run the same speed or faster turned out slower, often much slower. By contrast, in C++ it was surprisingly difficult to discover a way to express the same operations differently and get a different run time.
This is an insidious pitfall that may earn Rust the "slow" label, akin to what happened to Common Lisp.
Could it just be that the language is still young and all the edge cases in the optimizer haven't been implemented yet?
I suspect what the author was seeing was random performance differentials between iterators and loops, which often boils down to little missed optimizations in LLVM. If you find them, please file them in the Rust bug tracker--we've fixed many of them and will continue to do so in the future!
Note that when MIR lands, progress on which is well underway, we'll have the ability to do optimizations at the Rust IR level in addition to the LLVM level. This should make it easier to do these kinds of things.
It's impressive that the filter and map methods produced such good performance. The lazy evaluation scheme must be well setup, shout out to the Rust team!
Are the lazy iterators are combined and effectively stripped out at compile time?
foldl (+) 0 [1..1000000]
Then the obvious way to do it is to simply keep a running total, but haskell doesn't do that, it constructs the expression:
(...((1+2)+3)+4)+5)+...)+1000000)
foldl' (+) 0 [1..1000000]
for example: https://news.ycombinator.com/item?id=11060566
In my experience profiling and optimization is usually sort of like a victory lap - low hanging fruit for substantial differences.
This doesn't match my experience at all with Rust, for what it's worth. Not having copy constructors makes up for any difference in that regard: in C++ it's way too easy to accidentally deep copy a vector and the entire object graph underneath it--all it takes is "auto a = b" as opposed to "auto& a = b"--with very bad performance consequences. Rust, on the other hand, doesn't let you deep copy unless you explicitly ask it to.
C(const C &) = delete;
C &operator=(const C &) = delete;
C(C &&) noexcept = default;
C &operator=(C &&) noexcept = default;
struct MakeCopy {
const C &src;
MakeCopy(const C &src) : src(src) { }
};
MakeCopy make_copy() const { return *this; }
C(MakeCopy src) : field1(src.src.field1), (blah blah) { }
This isn't really clean, because it's too easy to add a field to C and then forget to add it to the "manual copy constructor", but so far I found it good enough for me.
Edit: I should point out that deep copies can only be explicit in Rust -- there's no implicit deep copy AFAIK.
Qt even takes it further by providing automatic copy-on-write. Methods that read data operate on the shared copy. Methods that change data cause the object to deep copy and detach first. This allows writing programs using values rather than references, while retaining the performance of references.
I'm curious if the author considered comparing clang vs rustc since both use the LLVM backend. (I'm guessing the more mature C++ code generation would still win the benchmark but one could study the intermediate code emitted by clang/rustc instead of the final machine code emitted by gcc.)
[1]https://github.com/ncm/nytm-spelling-bee/blob/master/Makefil...
I haven't looked at the code yet (time for bed) but this note from Agner seems like it might be relevant:
3.8 Branch prediction in Intel Haswell, Broadwell and Skylake
The branch predictor appears to have been redesigned in the
Haswell, but very little is known about its construction.
The measured throughput for jumps and branches varies
between one branch per clock cycle and one branch per two
clock cycles for jumps and predicted taken branches.
Predicted not taken branches have an even higher throughput
of up to two branches per clock cycle.
The high throughput for taken branches of one per clock was
observed for up to 128 branches with no more than one
branch per 16 bytes of code. If there is more than one
branch per 16 bytes of code then the throughput is reduced
to one jump per two clock cycles. If there are more than
128 branches in the critical part of the code, and if they
are spaced by at least 16 bytes, then apparently the first
128 branches have the high throughput and the remaining
have the low throughput.
These observations may indicate that there are two branch
prediction methods: a fast method tied to the μop cache and
the instruction cache, and a slower method using a branch
target buffer.
At a glance, the symptoms seem like this might match. Separately, I think there is still a limit of 3 branches per 16B before the branch prediction starts to fail. It's rare to hit this in normal code, but something this optimized might.
So what happened with my standard benchmark on Haswell (GCC 5.3, -march=native -O2)?
Old version, without PGO: ~8 minutes (baseline)
Old version, with PGO on: ~9 minutes (yes, PGO made it slower)
New version, without PGO: 11 minutes (60% slower)
New version, with PGO on: 7 minutes (~15% faster)
All of these benchmarks were replicated with a common set of functions tagged noinline, and I inspected the assembly to see if there was a difference with regard to loop unrolling. Nope, no unrolling. Afaict it appeared to be entirely to do with the way GCC had laid out code with respect to branches. The differences were minor in key areas and seemed like arbitrary compiler choices.
I eventually narrowed this down with callgrinds branch-predictor simulator to a few hot spots. I added a redundant if-statement to check for and short-circuit a common case, even though it shouldn't have mattered, and a few __builtin_expects, and suddenly I was getting the 15% speedup without PGO.
Which choice is fastest on the depends on the runtime word list, and thus there is no reason to fault the compiler for either choice. For the processor, the difference is simply that a "branch not taken" is faster than a branch taken. The fast version involves a loop that executes in a single cycle:
77.21 │210:┌─→add $0x4,%rcx
0.66 │ │ cmp %rcx,%r8
│ │↓ je 260
4.20 │219:│ mov (%rcx),%edi
0.88 │ │ test %r9d,%edi
│ └──jne 210
The solution (as the author mentions in a parenthetical) is to give more information to the compiler with "__builtin_expect". I wasn't able to test on Sandy Bridge or earlier, but my strong guess would be that Haswell and Skylake have a potential speedup, rather than a regression. I'll try to add a comment to the bug later tonight.
let fname = &*env::args().nth(1).unwrap_or("/usr/share/dict/words".into());
Why is there an .unwrap() on writeln! ? To force a panic if the write failed?
The &* converts a String to a &str. I would have done it in the match rather than here, personally.
> Why are they necessary for the compiler?
(We do have a very small and very specific set of conversions that will happen, they don't here, though.)
> Why is there an .unwrap() on writeln! ? To force a panic if the write failed?
Is this because args() ultimately gives you a String, and you need to get that and the string literal out of a single expression?
Why does args() give you String rather than str? Couldn't command-line arguments be static more-or-less constants?
Would there be any way to turn the output of args straight into a &str, so you didn't need to .into() the literal?
Why are String and str separate types, rather than different uses of a single type? Are there any other examples of pairs of types with the same relationship? Arrays and slices? Any others? Is there something like this for maps/dictionaries/hashes?
I realise i've asked a lot of basic questions about strings here, and that you (and any other knowledgeable people reading this) are probably pretty tired of explaining this over and over again. I would be equally grateful for a link to some relevant documentation or whatever as for a detailed answer!
> Is this because args() ultimately gives you a String
> Why does args() give you String rather than str?
> Would there be any way to turn the output of args straight into a &str, so you didn't need to .into() the literal?
> Why are String and str separate types, rather than different uses of a single type?
> Are there any other examples of pairs of types with the same relationship?
Don't forget other string types too: There's OSString, CString, and external crates provide other types as well. Strings are not simple.
> Is there something like this for maps/dictionaries/hashes?
> I would be equally grateful for a link to some relevant documentation or whatever as for a detailed answer!
"foo" in Rust has the type &'static str. That is, a pointer and a length to an immutable piece of memory that never goes out of scope, which in the case of a literal is allocated statically. Because Rust tracks ownership of memory, this kind of a reference is of a different type than a heap-allocated owned string.
Rust also does no allocations or conversions without you telling it to do so. The programmer wanted a heap-allocated String, so he had to call a conversion function, which allocated memory and copied the string.
And .into() seems to be used as a &str -> String (allocating) conversion for brevity only.
The more idiomatic form would therefore be:
let fname = &env::args().nth(1).unwrap_or(String::from("/usr/share/dict/words"))[..];
let file: Box<Read> = match fname {
"-" => Box::new(stdin.lock()),
_ => Box::new(fs::File::open(fname).unwrap_or_else(|err| {
writeln!(io::stderr(), "{}: \"{}\"", err, fname).unwrap();
process::exit(1);
}))
};
date.if_weekday(|day| { ... })
Hopefully the setup of closures that probably won't be executed isnt't too expensive. Do those require a heap allocation and release when not used, or is this all on the stack? The run time variation for small changes indicates that some constructs are more expensive than others, but it's hard to know which ones are bad.
I understand the rationale behind the Rust approach to error handling, but it's just painful to look at. After seeing the gyrations people go through in Go and Rust to deal with the lack of exceptions, it looks like leaving exceptions does not make a language simpler. From a compiler perspective, the compiler can generally assume that exceptions are the rare case, and can optimize accordingly. Rust has no idea which closure a function will call, if any.
[1] https://doc.rust-lang.org/std/result/enum.Result.html [2] https://doc.rust-lang.org/std/option/enum.Option.html
To expand: No closures require heap allocation. If you pass the closure as trait object, calling it will require a virtual function call, which is more expensive than a normal one.
We just merged an RFC for ? syntax, which should make error handling less verbose.
Creating a closure with |...| { ... } is literally as expensive as creating a tuple containing (references to) the variables it captures. That is, they're on the stack by default like everything else in Rust, and there's no implicit heap allocations. For more details, see, for instance, http://huonw.github.io/blog/2015/05/finding-closure-in-rust/ .
> Rust has no idea which closure a function will call, if any.
It does. As my link above discusses, each closure has a unique type, allowing monomorphisation to kick in and hence the compiler can easily optimise and inline calls to closures (as long as the author of the closure-taking function doesn't opt-in to only allowing virtual dispatch).
I don't think that this ever was the claim. Rust leaves exceptions out because they make code hard to work with and because it prefers errors be acknowledged. I don't think monadic errors are "simpler" than exceptions.
(Though I suspect they are simpler to teach than exceptions to people who have learned neither)
Once `?` lands in Rust I expect these "gyrations" become much simpler.
> Are we going to see > > date.if_weekday(|day| { ... }) > > and similar cruft for every type? I hope not.
Not sure where this comes from. As the others have mentioned, closures are pretty cheap, but anyway you don't need to use the control flow primitives. There are many ways of dealing with errors, including using `if let`, `match`, `unwrap_or_else`, `try!`, and the upcoming `?`.
Incidentally, I don’t know why I can write
let (mut word, mut len, mut ones) = (0u32, 0, 0);
but not
(word, len, ones) = (0, 0, 0);
And it does strike me as a little weird as well to only be able to take advantage of the pattern match destructuring on initialization, but I'm sure there's a good technical reason.
https://github.com/rust-lang/rfcs/issues/372
I think one of the main reasons this isn't done is because of the grammar issue. I dimly remember that one of the goals of Rust was to be parseable with a LL(1) grammar.
looks like a cleaner version that works in F# (and I am not sure in Rust). This is extremely useful when initializing values from a function that returns a tuple and do not want to change them (unlike the mut word etc.)
let (x, y, z) = GetStartPoint3d()
(And thanks for the idiom note, makes sense. F# is pretty cool.)
Why write:
> std::vector<unsigned> counts; counts.resize(sevens.size());
When you can write:
> auto counts = vector<unsigned>(sevens.size());
Doesn't seem like a fair comparison to me.
For an even shorter init:
> std::vector<unsigned> counts(sevens.size());
It should: we're comparing to Rust, whose namespace system seems very similar to a "using namespace std".
Not at all; only if you use globs ("use foo::*"). D's namespace system is like that, but not Rust's.
But again, personal opinion - it can definitely be used in some contexts (just be consistent in your project!).
What is idiomatic is explicitly importing individual symbols into a name peace.
#include <iostream>
#include <vector>
#include <string>
using std::cout;
using std::vector;
using std::string;
int main() {
vector<string> v {"explicit ", "is better ", "than implicit\n" };
for (auto p: v) cout << p;
return 0;
}
I don't write code in either language, but as an outsider my impression is that rust was created to make programming for parallel execution, easier.
If that's the case, why are we comparing a use case c++ is optimized for against a use case rust isn't optimized for?
This is a good thing, but is orthogonal to single threaded performance (which from what I've read, the Rust team definitely cares about).
The rayon library is an exciting example of some of the possibilities http://smallcultfollowing.com/babysteps/blog/2015/12/18/rayo...
Rayon, being a multithreading library, is of course itself not so trivial to write. What it lives up to is that users of rayon can use the regular rust type system rules to ensure that their use of rayon is thread safe if it compiles.
What Rust does have is that once your code compiles in safe mode you're very confident.
Overall, I like the complexity and I have been enjoying my time with Rust. I began using for bare metal ARM programming. After using Rust in "no standard library mode", I'm now convinced there are no more valid reasons for using C in this century. To me, Rust is a no-brainier replacement C.
It's not however, going to effect the adoption of modern C++, which has a slightly higher level niche in performance critical applications. It's the libraries that make C++ awesome, definitely not the language itself (although the core is improving).
Also there is Microsoft REST SDK which includes task based programming. https://casablanca.codeplex.com/wikipage?title=Programming%2...
Also there is async++ https://github.com/Amanieu/asyncplusplus/blob/master/README.... which is an implementation of the proposed c++ concurrency TS.
In January 2016 the concurrency TS was accepted so we should start seeing implementations from the compiler vendors. https://gist.github.com/StephanTLavavej/996c41f7d3732c968ede
The problem is more that Rust is going to be automatic in your security more often, while C++ would require more thorough review.
But the code in this article is micro-optimized, and overlooks the common trend of micro-optimization in C++ often leading you into the twilight zone of unexpected undocumented behavior and "luck" when getting desired results rather than granularity well defined syntax. You basically compare the two with artful precision which means you do not get to notice the very common trend of what is safe Rust is often unsafe C++ in the default design.
No, the entire point of Rust's "fearless concurrency" is guaranteed data race freedom by the compiler, something C++ doesn't even try to enforce. Modern C++ can still easily have data races.
I would love to know more about this; how curious indeed.
I would be curious to know if there are plans like Swift to simplify the language syntax in the future or if it is just something to get used to.
Dependencies / headers / modules: - C++ is better precisely because it's more grained on the initialization side. The paragraph starting with 'Rust wins, here', is just a general turnoff to read the rest of the article. When I read the title 'Rust vs. C++: Fine-grained performance' I was honestly expecting either a table with performance times across various algorithms, or a savvy optimization guide. I wasn't expecting a LoC duke-it-out.
Input file processing - Both are conceptually boilerplate code. There is more for Rust apparently. - There is an interesting &⊛env:: in there that makes the language looks like it needs a bit more work. Three operators just to do something with the first object? - Are they intentionally trying to copy C++ with the :: operator but removing visually arbitrary semicolons? Just replace the :: with something else.
Data structure and input setup - Remove the 'let' from the language, and it does look cleaner than the C++.
Input state machine - Why isn't "(0..7).rev()" "(7..0)" - On the bottom part, lamba-like usage will makes in less comprehensible (and probably undebuggable the way it's written)
General lack of performance numbers - "I found that iterating over an array with (e.g.) “array.iter()” was much faster than with “&array”, although it should be the same..." "Curiously, changing scores to an array of 16-bit values slowed down (earlier versions of) the C++ program by quite a large amount – almost 10% in some tests – as the compiler yields to temptation and forces scores into an XMM register. The Rust program was also affected, but less so."
Edit: Unicode
> Semicolons inconsistent usage
> C++ is better precisely because it's more grained on the initialization side.
> There is an interesting &⊛env:: in there that makes the language
> looks like it needs a bit more work.
> Just replace the :: with something else.
> Remove the 'let' from the language, and it does look cleaner than the C++.
> Why isn't "(0..7).rev()" "(7..0)"
> On the bottom part, lamba-like usage
With the above in mind:
> You've asserted this, but not demonstrated it: semicolon usage is consistent in Rust. Rust is not C++, so it doesn't necessarily follow the same rules, but it is consistent, even though it may be different.
Writing code is consistent and unaffected, code comprehension (debugging, integration efforts, etc) by third parties will be hampered.
>Can you elaborate on this? I'm not exactly sure what you're saying.
Not importing the entire library will result in faster compilation. Unless rust has a concept similar to precompiled headers, etc. I apologize at this point. I'm not sure what Rust does in that respect, but my initial thoughts were that as the project grows, the parser will slow on includes. The internal symbol resolver will slow on lookups because too many things are included.
All of the above is only if you are trying to match what C++ does for large teams. I guess it's up to the developers of the language what direction they want to take it in. More agile or more enterprise oriented.
(From personal experience: I was on a team looong time ago, where codebase took 12 hours to compile on a powerful cluster. Any gains, even by few hours, changed schedules drastically)
>See above: this kind of thing is about how Rust views coercion and heap allocation: explicit, not implicit.
I understand your viewpoint, however three operators on a single object still seems conceptually excessive to me.
>Because ranges always iterate forward, from start to end. rev() reverses the direction.
Since both are supported, maybe the parser can be made smarter?
> I'm not sure what you're referring to here.
Well this piece of code:
let scores = words.iter()
.filter(|&word| word & !seven == 0)
.fold([counts[count];7], |mut scores, &word| {
for place in 0..7
{ scores[place] += (word >> bits[place]) & 1; }
scores
});
Outside of minor things like this, I like what Rust is trying to do. I think it's a great effort and I do look forward to where it will lead.
> I get the feeling that Rust design is concerned more about write-ability
> of the code than readability.
> code comprehension (debugging, integration efforts, etc) by third parties will be hampered.
> Not importing the entire library will result in faster compilation.
> where codebase took 12 hours to compile on a powerful cluster.
We also have a lot of compiler performance improvements coming down the pipeline, including incremental recompilation within a single crate.
> Since both are supported, maybe the parser can be made smarter?
> Is not easily read or debugged ( on which line do you set the breakpoint, etc).
Thanks for taking the time to reply. Skepticism is good! Constructive criticism is the only way things move forward.
The compilation time problems associated with headers are problems with headers: avoiding headers makes it easy to avoid the problems. The crate system of Rust is somewhat similar to precompiled headers, and C++ is in fact in the process of putting something similar (modules) into the standard.
Interestingly, this makes the Rust compiler easier to work with: the basic things of lexing, parsing, name resolution etc. are not at all bottlenecks (any particular file is only parsed once, there's not megabytes and megabytes of headers to parse for every invocation). This means these parts don't have to be micro-optimised, and hence don't get hit by an increase in complexity due to those optimisations.
Concerns about internal symbol resolution aren't a problem: hashmaps give (expected) O(1) access no matter how many elements they hold, and even using a tree has O(log n) access (i.e. going from 1_000 symbols to 1_000_000 only doubles the time for a look-up, and the next doubling happens at 1_000_000_000_000 symbols).
> Since both are supported, maybe the parser can be made smarter?
Not sure what this has got to do with the parser (7..0 parses fine, it just creates an empty iterator), but implicitly reversing ranges are on of the most annoying features of R: it makes it annoyingly hard to do things like `x..y - 3`.
> Well this piece of code:
Two things: the author is effectively golfing here (they say they want the code to fit on a single page), and, the Rust version can be written just like the C++ version, with a loop:
let scores = [counts[count]; 7];
for &word in words {
if word & !seven == 0 {
for place in 0..7 {
scores[place] += (word >> bits[places]) & 1;
}
}
}If Swift had structural references (for all intents and purposes in Swift, all structs are value types and all classes are automatically reference counted pointers) and move semantics Swift would absolutely kill it.
It's an exciting time to be a PL nerd.
(There's also the fact that, as of the hypothetical Swift 4k, none of the library ecosystem will be leveraging the borrow checker and so Rust will still have a substantial head start for people who want thoroughly static ownership.)
Other than that I'm a bit dismayed that Swift just punts concurrency to GCD, given how many other new languages make concurrency such a major focus (especially Rust).
Like what? Given the constraints that Rust has, I don't see much that could radically be changed. Little things like the ? operator (equivalent to try!()) can improve the common tasks, but how do you ensure memory safety in the absence of a garbage collector without the programming being explicit about what he wants to do?
And what, exactly, does Rust sacrifice for safety?
The article compares Rust vs C++. No surprise that the [potential] language in the middle of these two extremes is mentioned....
> And what, exactly, does Rust sacrifice for safety?
Clarity, usability... Here is Alexandrescu's quick overview of it:
https://www.quora.com/Which-language-has-the-brightest-futur...
Rust's borrow checker is its single most distinctive feature, and that is inspired by the work done in the Cyclone language.
http://youtu.be/Y1KOuFYtTF4 (starts at 29:00)
C++ template meta programming language is such a powerful and expressive tool for writing libraries and safe abstraction. Imagine if all the effort of 8 years of Rust team went into a modern C++ safety library.
Such a library would have been more useful contribution and more people would have benefited.
We made Rust because you can't actually retrofit it's guarantees on C++ without breaking backwards compatibility. The CPP Core Guidelines are an example of this: Herb said that data race prevention is a non-goal, and in general, how it interacts with concurrency is not yet understood.
Curious why you think using const functions doesn't prevent data races after watching
at 29:00 he says the C++ standard guarantees const member functions are data race free.
What I meant was something like "const itself is not a panacea against data races generally." It is a useful tool.
But in C++ if you have a const member function F() then F() can only change member variables that use the "mutable" key word.
If you default to all methods are const you have much much safer C++. As safe as rust? not probably but combined with liftimes proposal and static analysis rules we have a language good engineers can sufficiently work with.
struct Foo
{
mutable auto a = 4;
auto increment() const -> void
{
this->++a;
}
};
As C++98 PTSD begins to fade and C++17 becomes the cultural mental image of the language, the argument for switching to rust will become less and less compelling.
Eventually, the only "advantage" will be ML influenced syntax.
The reason is there are only three languages that can easily call into C++ code. Objective-C (swift by proxy), D, and of course C++.
Why rust didn't prioritize compatibility with C++ like C++ did with C boggles my mind. Why do you think C++ became so popular? Near perfect C compatibility (until recently) is literally the only reason. Instead of focusing on pragmatisim Rust focused on language purity.
At what cost?
This is not nearly enough. See the examples I gave in my other post.
Besides, all "const" means is "I won't mutate 'this'". It doesn't mean someone else who has a non-const reference to your object won't mutate your object. That makes it largely useless for reasoning at a local level.
> If we train engineers to use const member functions, then the programmer is forced to think about state and mutation.
The programmer may think about it, but the compiler doesn't enforce it at all.
> As C++98 PTSD begins to fade and C++17 becomes the cultural mental image of the language, the argument for switching to rust will become less and less compelling.
Only if you don't understand how Rust works.
> Why rust didn't prioritize compatibility with C++ like C++ did with C boggles my mind.
Because C++ compatibility is impossible without being a derivative of C++, and C++ is hopeless in the safety department. I believe it is impossible to make C++ memory safe without making it not C++ anymore.
> Instead of focusing on pragmatisim Rust focused on language purity.
No, Rust focused on what is possible.
Do you consider D to be a derivative of C++? I don't. They have a near perfect C++ interface. D can even catch C++ exceptions. It's pretty sweet. You can hear about the black magic Andrei used to get that to work here:
http://cppcast.com/2015/10/andrei-alexandrescu/
Side note: I'm actually thinking the Rust and C++ comparison misses the mark. First of all, C++ cannot be obsoleted by rust, it's economically impossible. Secondly, I don't even think they compete in the same domain space. Rust is actually lower level than C++, in that it does lower level stuff in a more natural way. It's C, that Rust makes obsolete; which is something C++ totally failed to do (because of it's RTTI, exceptions, and other runtime features -- all things you and the rest of the Rust team intelligently scrapped). After trying embedded Rust, I'm completely done using C (and the C parts of C++).
IMO the advantages C++ still has over Rust are:
- libraries, libraries, libraries
- C++ has so many great libraries
- *writing* C++ libraries with SFINAE sugar is the bees knees.
- template meta-programming feels like a different language, it's dynamic, functional, and the difference is refreshing. I like the mental switch you have to do to go from writing a C++ template to writing a C++ model.
- as much as header files suck, they let you skim an API much more easily than Rust or Swift.
- performant, memory safe data structures:
For example, it's trivial to write a low overhead pointer that can't dangle, throws an exception on nullptr deference, and that safely points to an object it doesn't own (even if that object is its owner). With this and a unique_ptr composed with similar safety mechanisms you now have the primitives needed to write any data structures or algorithm so that it is protected from undefined and unsafe behavior, yet remains performant. This solution has significantly less overhead than using reference counted pointers like shared_ptr derivatives or Rc. The performance tradeoff over using raw pointers is minuscule and totally dwarfed by the gain in safety guarantees. From what I've observed, you can't do this in Rust, if you try to write a doubly linked list you either have to use C-pointers that can dangle inside unsafe blocks, or eat the Rc overhead.
EDIT: How could I forget to mention the glory that is constexpr?
Advantages of Rust over C++ (again, IMO):
- the correct defaults (aka opposite of C's insanity)
- best C++11 features built in and defaulted (move semantics, unique_ptr is Box<T>, Rc is shared_ptr etc..)
- Bad ass embedded capabilities. You don't nearly feel as crippled like you do in C++ without the STL.
- the safety guarantees are real, and they're awesome
- move semantics into closures looks so goddamn elegant. I love it
- inline assembly doesn't feel like a hack
- modules and cargo rock
- secretly and surprisingly similar to ruby in a lot of places :)
- it wants you to think functionally, and unlike Swift, it means it. This is a good thing.
Just to reply to this individual point, rustdoc is fantastic. Personally I much prefer having an HTML-rendered "header file" for a crate's API. Even if they aren't hosted, it's trivial to generate one yourself using `cargo doc`. To be maximally useful, the author needs to have made doc comments, but at least there's a standard format for that, and you might not have anything like that in a header file anyways.
It's not a near-perfect C++ interface, because D can't instantiate C++ templates on its own.
> First of all, C++ cannot be obsoleted by rust, it's economically impossible.
Rust can make C++ obsolete in a technical sense. But I agree of course that C++ is immortal.
> For example, it's trivial to write a low overhead pointer that can't dangle, throws an exception on nullptr deference, and that safely points to an object it doesn't own (even if that object is its owner)
Wrong. You can't write a pointer that can't dangle in C++. Think iterator invalidation, "this" invalidation, etc. I've given innumerable code samples to prove this in the past.
It's hard to argue about this abstractly, so let's do this. If you give me the C++ code for a smart pointer that you claim is safe, I will construct you a code example showing use-after-free using that pointer.
> From what I've observed, you can't do this in Rust, if you try to write a doubly linked list you either have to use C-pointers that can dangle inside unsafe blocks, or eat the Rc overhead.
Yes, you can't do this in Rust. You also can't do it in C++.
C++ is good at making you think that you're using pointers that can't dangle, as evidenced by posts like yours. It's not good at actually preventing things like use-after-free.
> - template meta-programming feels like a different language, it's dynamic, functional, and the difference is refreshing. I like the mental switch you have to do to go from writing a C++ template to writing a C++ model.
I much prefer the static approach of Rust's generics to the untyped templates of C++--the fact that templates feel like a different language is a disadvantage in my view--but this is a huge tradeoff and it largely comes down to taste. This is unlike the memory safety guarantees of Rust pointers, which are not a matter of taste; safety is a formal property that C++ references simply do not satisfy and cannot satisfy no matter what.
https://github.com/martinmoene/observer-ptr/blob/master/incl...
I'm using a modified version in a personal library. It throws an exception on a nullptr dereference. I'm not sharing that version here because A. it's not ready, and B. You're definitely a better programmer than me and I don't feel like getting totally shit on today :)
I thought the whole point of the "world dumbest smart pointer" was that it's automatically nullptr'd for you so it can't dangle. I'm looking forward to hear why this isn't true. I've actually been brooding over this perceived advantage of C++ for a while now.
std::vector<std::string> strings;
strings.push_back("Hello");
std::observer_ptr<std::string> p(&strings[0]);
strings.clear();
std::cout << p; // use after freeTo use the header I linked it should be `nonstd::observer_ptr<std::string> p(&strings[0]);`
You also need to dereference p to use the stream operator.
I'm disappointed you presented such a contrived example. You also deliberately avoid const-correctness. That's a little insidious. You need to const everything manually in C++, so as a good C++ programmer you should const everything as you write C++. Only carefully omit const when you need mutability.
We all know C++98 is dangerously unsafe. Let's write your example in C++11.
#include <iostream>
#include <string>
#include <vector>
#include <memory>
#include <utility>
#include "observer_ptr.h"
// kill the noise
using std::cout;
using std::vector;
using std::string;
using nonstd::observer_ptr;
int main() {
vector<string const> const strings { "Hello" };
observer_ptr<string const> const p(&strings[0]);
strings.clear(); // not gonna happen
cout << *p;
}
» clang++ -std=c++11 immutable.cpp
immutable.cpp:11:5: error: member function 'clear' not viable: 'this' argument has type 'const std::vector<const std::string>' (aka 'const
vector<const basic_string<char, char_traits<char>, allocator<char> > >'), but function is not marked const
strings.clear(); // not gonna happen
^~~~~~~
/usr/local/Cellar/llvm/HEAD/bin/../include/c++/v1/vector:735: 10: note: 'clear' declared here
void clear() _NOEXCEPT
^
1 error generated.
So now using const is some kind of difficult task? Not much cognitive overhead there. I thought everyone was onboard with immutability these days.
My point is that safe low-overhead data structures with non-dangling, pointers protected from nullptr dereferencing ARE possible in C++ and not Rust. Yes, you have to put const after every type. Call that vigilance if you want. It's a really small price to pay IMO.
Edit: Down voted again. What's wrong with my point or code? I'm curious.
The fact that if you make everything totally immutable you can write safe C++ is (a) not true; (b) even if it were true, a totally irrelevant point in practice since not everything can be immutable. "C++ is memory-safe if you don't mutate anything anywhere" is a completely uninteresting point to the real world (even if it were true).
> My point is that safe low-overhead data structures with non-dangling, pointers protected from nullptr dereferencing ARE possible in C++ and not Rust. Yes, you have to put const after every type. Call that vigilance if you want. It's a really small price to pay IMO.
No, it's completely wrong. You have no protection from dangling references in C++.
I'd love to see an example without globals or an undefined behavior factory function.
Also, consider this:
std::observer_ptr<std::string const> const foo() {
std::vector<std::string const> const strings { "Hello" };
return std::observer_ptr(&strings[0]);
}
std::cout << foo(); // use after free, even with const!
If your contention is that observer_ptr is completely safe, then we could have easily added it to Rust. We didn't for a reason: it's unsafe in Rust and unsafe in C++.
They are protected from undefined behavior, performant, and are excellent middle ground between reference counting or raw pointers.
I like Rust I just don't understand how I'm wrong about this single little pro C++ has over it.
Are you talking about how you can write data structure abstractions in C++ using unsafe feature (like std::observer_ptr) that are themselves safe to use? If so, that's exactly Rust's model! Rust's linked lists, for example, are written using unsafe code internally and present a safe interface.
> I like Rust I just don't understand how I'm wrong about this single little pro C++ has over it.
Because it's not a pro that you can write unsafe code in C++ without saying "unsafe"!
It's fine, I get you're very invested in this. I'm gonna go back to making stuff. I like the work you guys are doing and I don't want to give the impression I do not.
I understand I sound irritated here, but that's because we went through a lot of work to make Rust safe. It is irritating when people claim that languages that didn't even try to do any of that work somehow did it better than Rust did.
That being said, Rust is definitely a language I will continue to study. I have no doubt it's making me a better programmer.
EDIT: I find it funny that I'm always defending C++ here. C++ is like that kid at school who's not really your friend but you always get stuck doing project with. You end up spending a lot of time with him, so when the time comes that you hear someone talk bad about him you feel obligated to point out that he's a actually pretty alright dude.
Tell me how to use const functions to enforce that I take a lock before accessing data guarded by a mutex. Or how to mutate data local to the current thread only, while forbidding mutation of shared data.
> Imagine if all the effort of 8 years of Rust team went into a modern C++ safety library.
I imagine our 8 years would have been wasted chasing the impossible.