- Try compiling Rust in release mode with thin lto. It usually doesn't produce very large builds.
- Many optimizations, Or first builds. Incremental builds improve build time significantly.
- What do you mean? I didn't understand the question.
- No. In fact, in some cases it can actually out-preform c++.
so rust is more efficient and safe than any other language
When dealing with languages such as C and C++, they should probably be considered equally fast. In some examples Rust will be faster and other cases C++ will be faster, but it will not be a big difference, and it will mostly cancel out. As for safety, absolutely, it's safer than C and C++.
In my experience Rust produces massive binaries, but that's a matter of perspective. For server and desktop applications it's not really an issue. For tiny embedded applications you can use
no_std. But if you start getting to embedded systems like the Zynq-7000, which has 1GB physical RAM, and you want to fit the entire OS and applications in a ramfs, and your Rust application uses the standard library and a few crates, then even small applications built as release can be a couple of megabytes in size, which may be inconvenient. (A small x64 Rocket "hello world" application clocks in at 11MB for a release build, though I can get it down to 7.6MB using lto).
Though the binaries are certainly not inefficient.
For shrinking Rust binaries there are various possibilities. Some examples:
- Panic: abort: By default Rust does a stack trace to give a backtrace on panic. In production you may not want this information. Follow the given link to remove the trace-code when compiling.
Strip binaries: Rust also includes Debug-symbols by default, partly for the panic-unwind, you can use
stripto get rid of them.
A quick google search brings up further options.
It's safer and more efficient than most languages. Details depend on exactly what you do, and how you write your programs. Speed is similar to C and C++, but there are nuances: https://kornel.ski/rust-c-speed
I think others above have done a better job of addressing those four points than I can.
Except I have to say that as a long time C/C++ user and newbie to Rust my early ventures into Rust involved recreating some of my C/C++ ventures in Rust. I was happy to find that the performance of the resulting Rust binaries was on a par with C/C++. Sometimes a bit faster, sometimes a bit slower. Sometimes those rankings changed when running on ARM vs Intel x86. In my experience then, the difference between Rust and C/C++ performance wise is lost in the noise of compiler and architecture changes.
But what about that "productivity" thing in the thread title?
Is that about programmer productivity? In lines of code per day? Or what?
My experience there is that Rust really slows me down. The type checker is really fussy. The borrow checker is really fussy. It seems like it take forever to get anything to compile. So many rules to adhere to. Much like Ada back in the day.
But, those with the patience and persistence to get their code compiled have great rewards. No more mysterious memory leaks, and crashes in the night. No more endless hours and days with a debugger trying to figure out what the hell is going on.
May be your creation does not always produce the correct results. But they are normal logic errors that can generally be figured out from reading the code and having some tests in place.
The thesis then is that what you loose in productivity when churning out code in Rust you make up in not having down time due to bug hunting.
Many would argue the productivity gains are orders of magnitude greater. The cost of finding bugs at development time is ten or a hundred times less than fixing them after deployment. Or so goes the arguments of the "test driven development" guys.
Sorry "agile" people. You are barking up the wrong tree
Productivity, for me, does not mean "lines of code per day" or any similar measurement. (The fastest code is the code you don't have to write, and all that...)
Productivity is about refactoring. Getting the code "just right"; fixing bugs, adding necessary features, removing unnecessary ones. And Rust makes refactoring amazingly good. This is probably one of the most underrated features of the language.
In many cases, it is possible to completely rearchitect the underlying code while leaving the public API as-is, and without introducing new bugs. I've literally never had such a liberating experience with refactoring until Rust.
I have multiple decently sized (~10,000 LoC) apps written entirely in Rust. They liberally use dozens of large third party crates and the stdlib, and they were absolutely not optimized for small file size. Despite that, they produce binaries that are 500 - 1,000 KiB in size. I've never had any Rust app get even remotely close to 11 MiB.
So there's something wrong with your setup, or there's something wrong with your code, or there's something wrong with one of your dependencies. I'm having a hard time seeing how a hello world app could get 11 MiB in size.
[ghost@localhost message-on-screen]$ time rustc hello-world.rs
[ghost@localhost message-on-screen]$ time gcc hello.c -o hello
[ghost@localhost message-on-screen]$ time ./hello-world
[ghost@localhost message-on-screen]$ time ./hello
rust take more time to compile a simple hello world when compared to c
Because the rustc does more jobs than gcc. Rust's type system is sound so rustc check all the types to throw compile error if the code tries to assign invalid typed value, while the C compiler blindly compile them. Rust has type inference so If you omit the type definition the rustc tries to find correct type for it and throws compile error if single appropriate type is not found, while the C compiler enforces user to attach type to every variable, still not enforcing its soundness though. And also in Rust no references can be dangling and there's no UAF/DF/Iterator invalidation/Data race, while the C compiler happily accept those code and blindly produces incorrect code for the sake of Undefined Behavior.
And gcc takes more time to compile a hello-world.c than gas takes to compile hello-world.a - that's natural. The only thing your benchmarks show is that rustc does more work when compiling hello-world.rs than gcc when compiling hello-world.c
Which is to be expected, since
rustc does a lot of compile-time theorem proving to enable "zero-cost abstractions".
i notice one thing that rust compiler is slow to start or compile first program after the computer system is on , even if it is a simple hello-world
why it is so...?
Rust is generally rather slow at compiling programs due to its rather complicated type checking and extensive optimizations. That said the after-pc-is-turned-on thing is probably just that your OS will cache the files in RAM to enable faster access after first use.
i notice this same problem for other progamming language like julia but in case of gcc complier it is not a problem.
Julia is a JIT compiled language, so it needs to recompile everything every time you run it. Rust is not like that, it only needs to compile once per change to the files.
[message-on-screen]$ time rustc hello-rust.rs
[message-on-screen]$ time rustc hello-rust.rs
this is the difference i observed
As someone who has wasted several months trying to track down a spurious bug on customer machines (as in physical machines, weighing hundreds of kilos and cutting things at great speeds) I've got a healthy amount of respect for the "catching bugs later is orders of magnitude more expensive" attitude. Our company wasted about a man-year's worth of wages trying to resolve problems in poorly written C code which would have been completely avoided by using a language with
Send + Sync and the borrow checker.
So I'd argue that the productivity gains from lack of bug hunting related to misuse of the language language (i.e. UB and null pointers and data races, you can still have logic bugs in Rust) is quite tangible.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.