Funny you should mention that. Of course, you could compare what the libraries for C++ and Rust have to offer. And obviously they are restricted by what the language allows you to express. The existing libraries don't necessarily represent what's possible to express in the respective languages. But yeah, let's compare things like C++'s std::async/std::future/std::function against their Rust equivalent. I'll help you out as I'm already familiar with both, C++ and Rust. C++'s version of std::future and std::function has type erasure baked into its design which means indirections which means it's harder to inline stuff. Rust's futures and functions compose better with lower overhead. Composing futures in Rust using methods like "and_then" don't require extra memory allocations and end up being rather efficient state machines when compiler optimization is turned on. That's not really a difference between the power of C++ versus Rust. It's a design trade-off for some library component. You could build a C++ library just like that. But the C++ standards committee didn't.
Obviously, Rust, with it's run time checks, can't match the performance of C without those checks.
I get that it's tempting to brush off backing up your claim with the word "obviously" especially if the claim sounds so reasonable. But you're actually wrong here. I encourage you to look into the details. Most of the checks are done by the compiler at compile-time incurring no runtime cost. And with respect to array bounds checking... depending on what you do these checks can often be elided. What do I mean by that? I don't mean "opting out at your own risk"—though, that's possible, too—I mean that there are patterns that make bounds checking just unnecessary in a lot of cases. The Rust team would consider it a bug if a simple C for-loop iterating over an array would be faster than the equivalent idiomatic Rust code. With the help of Rust's zero-cost iterator abstraction and enabled compiler optimizations you'll get exactly the same machine code for the loop logic. People actually checked this because they care about performance.
I see no compelling reason to switch to Rust.
Well, with your attitude and preconceived notions, it doesn't surprize me. You don't really know what Rust has to offer.
If having those run time checks "built in" is desirable enough, I think it would make more sense to re-introduce those checks to C compilers, (Yes, I know, Rust has other features "built in", but most, if not all, of those features are available in libraries with many years of use and testing. (They might even be used by Rust.))
The magic is in Rust's type system. That's how it's possible to avoid dangling pointers without incurring any runtime costs or adding a garbage collector. Show me that C library that does it for C. Sheesh! Array bounds safety is probably the most boring thing about Rust. Everybody can have array bounds safety easily.
From all the programming language projects Rust seems to be among those with the most open developtment process. A lot of work is already done by people that aren't paid by Mozilla. To me this looks rather healthy. Good community, open and welcoming development process. Time will tell.
"Modern Coder"—we're in a thread about Rust—doesn't imply ignorance about how computers work. Being into a new language like Rust does not imply that one doesn't know how to write code that performs well. You guys need to ditch the preconceived notion that "new/modern" necessarily implies being more disconnected from the bare metal. It doesn't. See Rust. Yeah, C is kind of awful IMHO. I don't like the (lack of) type safety. It's very limited in terms of ways to express abstractions. It's just a "portable assembler" with objectionable defaults. Your sentiment makes me believe that you don't know what else is out there besides C, C++ and a whole bunch of "I-don't-know-what-I'm-doing-please-give-me-training-wheels" languages like those that are interpreted or run on cushy VMs.
Where do you draw the line, though? What does it mean to be able to handle C? How many memory safety and data-race bugs are you allowed to introduce by accident if you pride yourself to be among those able to "handle C"? Zero? How many coders do you think would be left after you ditched everyone who produced at least one memory safety issue in their life? Why risk security critical bugs to be detected so late by attackers instead of early at compilation? Where's the logic in that?
I don't see why that should be the case. While interfacing languages like Python and Rust typically requires a C interface—C being the lingua franca—Rust code could still internally make use of safer alternatives, effectively reducing the attack surface. I say that even without having checked how all those mentioned projects ease the Python/Rust integration.
What's your argument for the unavoidable performance regressions? Rust achieves most of its safety using compile-time checks based on better type system. Those don't incur any runtime penalties. The way abstraction works in Rust is pretty much the same as in C++ and sometimes even better than that. I can even give you multiple examples for that if you care to check it out off the top of my head:
In C and C++ functions decay to pointers. In doing so, the behaviour of the function is not preserved its type which makes inlining more difficult for the compiler. In Rust the name of a function is a unique type which preserves its behaviour in its type. Passing that to a generic Rust function easily allows the function to be inlined in the generic method.
The overhead of type erasure in C++ is higher than in Rust. See C++'s std::function versus Rust's Box<Fn>
C++ and Rust both offer "futures" as part of the standard library or a popular and easily installed crate. Rust's futures are lower overhead and don't require as many dynamic allocations when composing them.
Which of Rust's design choices am I missing that supposedly intrinsically imply a runtime penalty?
You overrate inheritance. Even in C++ the trend is to favour composition over inheritance. One good reason to use inheritance in C++ is to create something similar to what Java calls an "interface": basically an abstract base class which you can derive from using one or more concrete classes to do dynamic dispatch. In Rust you can get the same thing via traits -- no inheritance necessary for that.
I'm not saying inheritance is never useful. But in Rust you can get by pretty well without it because of composition and traits. That being said, The Rust community is open for suggestions for language extensions. If you feel something is missing, start a discussion and/or write an RFC for it.
Slashdot Mirror
Funny you should mention that. Of course, you could compare what the libraries for C++ and Rust have to offer. And obviously they are restricted by what the language allows you to express. The existing libraries don't necessarily represent what's possible to express in the respective languages. But yeah, let's compare things like C++'s std::async/std::future/std::function against their Rust equivalent. I'll help you out as I'm already familiar with both, C++ and Rust. C++'s version of std::future and std::function has type erasure baked into its design which means indirections which means it's harder to inline stuff. Rust's futures and functions compose better with lower overhead. Composing futures in Rust using methods like "and_then" don't require extra memory allocations and end up being rather efficient state machines when compiler optimization is turned on. That's not really a difference between the power of C++ versus Rust. It's a design trade-off for some library component. You could build a C++ library just like that. But the C++ standards committee didn't.
The abundance of kernels written in C does not prove the point you seem to be trying to make.
Obviously, Rust, with it's run time checks, can't match the performance of C without those checks.
I get that it's tempting to brush off backing up your claim with the word "obviously" especially if the claim sounds so reasonable. But you're actually wrong here. I encourage you to look into the details. Most of the checks are done by the compiler at compile-time incurring no runtime cost. And with respect to array bounds checking ... depending on what you do these checks can often be elided. What do I mean by that? I don't mean "opting out at your own risk"—though, that's possible, too—I mean that there are patterns that make bounds checking just unnecessary in a lot of cases. The Rust team would consider it a bug if a simple C for-loop iterating over an array would be faster than the equivalent idiomatic Rust code. With the help of Rust's zero-cost iterator abstraction and enabled compiler optimizations you'll get exactly the same machine code for the loop logic. People actually checked this because they care about performance.
I see no compelling reason to switch to Rust.
Well, with your attitude and preconceived notions, it doesn't surprize me. You don't really know what Rust has to offer.
If having those run time checks "built in" is desirable enough, I think it would make more sense to re-introduce those checks to C compilers, (Yes, I know, Rust has other features "built in", but most, if not all, of those features are available in libraries with many years of use and testing. (They might even be used by Rust.))
The magic is in Rust's type system. That's how it's possible to avoid dangling pointers without incurring any runtime costs or adding a garbage collector. Show me that C library that does it for C. Sheesh! Array bounds safety is probably the most boring thing about Rust. Everybody can have array bounds safety easily.
From all the programming language projects Rust seems to be among those with the most open developtment process. A lot of work is already done by people that aren't paid by Mozilla. To me this looks rather healthy. Good community, open and welcoming development process. Time will tell.
"Modern Coder"—we're in a thread about Rust—doesn't imply ignorance about how computers work. Being into a new language like Rust does not imply that one doesn't know how to write code that performs well. You guys need to ditch the preconceived notion that "new/modern" necessarily implies being more disconnected from the bare metal. It doesn't. See Rust. Yeah, C is kind of awful IMHO. I don't like the (lack of) type safety. It's very limited in terms of ways to express abstractions. It's just a "portable assembler" with objectionable defaults. Your sentiment makes me believe that you don't know what else is out there besides C, C++ and a whole bunch of "I-don't-know-what-I'm-doing-please-give-me-training-wheels" languages like those that are interpreted or run on cushy VMs.
Not sure what this has to do with "We need to ditch C". A safer C alternative doesn't necessarily imply a performance regression.
Where do you draw the line, though? What does it mean to be able to handle C? How many memory safety and data-race bugs are you allowed to introduce by accident if you pride yourself to be among those able to "handle C"? Zero? How many coders do you think would be left after you ditched everyone who produced at least one memory safety issue in their life? Why risk security critical bugs to be detected so late by attackers instead of early at compilation? Where's the logic in that?
I don't see why that should be the case. While interfacing languages like Python and Rust typically requires a C interface—C being the lingua franca—Rust code could still internally make use of safer alternatives, effectively reducing the attack surface. I say that even without having checked how all those mentioned projects ease the Python/Rust integration.
What's your argument for the unavoidable performance regressions? Rust achieves most of its safety using compile-time checks based on better type system. Those don't incur any runtime penalties. The way abstraction works in Rust is pretty much the same as in C++ and sometimes even better than that. I can even give you multiple examples for that if you care to check it out off the top of my head:
Which of Rust's design choices am I missing that supposedly intrinsically imply a runtime penalty?
but [Rust] lacks features such as inheritance.
You overrate inheritance. Even in C++ the trend is to favour composition over inheritance. One good reason to use inheritance in C++ is to create something similar to what Java calls an "interface": basically an abstract base class which you can derive from using one or more concrete classes to do dynamic dispatch. In Rust you can get the same thing via traits -- no inheritance necessary for that.
I'm not saying inheritance is never useful. But in Rust you can get by pretty well without it because of composition and traits. That being said, The Rust community is open for suggestions for language extensions. If you feel something is missing, start a discussion and/or write an RFC for it.