You misunderstand the ownership system in Rust. It has checks, that is true, but they are all at compile time. Because of them, compiling is slower. But since the compiler proved that the code was safe, the checks are not present during execution, so there is no performance penalty for them.
I prefer the more specific syntax of c++ personally, just because I think it's cool to have that level of control over the program (as a c++ programmer). I think rust is really cool tho, not everything is about raw speed, sometimes you want a solution that works every time no matter what; that's a lot harder in c++
I also think Rust macro's are important part of the language. In C++ they are not that good, in Rust it can allow you to use a new language that is compiled to Rust and has all of the nice errors of Rust. And if speed is needed, unsafe Rust can be used to speed things up while creating safe abstractions.
It seems that the difference between compile time and runtime aren’t your strong suit, and I would recommend you learn about it since all of Rust’s checks happen at compile time and do not impact performance outside of Debug mode
2:58 there are options for game dev in Rust. Godot scripts can be written in C++ or Rust, and there are engines in Rust. I think best at the moment is Bevy, even if it is not 1.0 yet.
I noticied a slight error. Rust's ownership and borrowing model manages resources ((e.g.) a heap allocated memory, open file descriptors, network sockets, etc., ) and their lifetimes, which involves huge compile time validation. But in C++ they are left to the programmers to manage the resources. If programmer makes an error in the resource management (like dangling pointers), it will result in system instability and vulnerabilities. During runtime there is no performance overhead. Except may be for bounds checking in rust. In my opinion the performance difference is very insignificant, unless bounds check is present in a hot path. It can be easily disbled for specfic parts of the code using unsafe. I do C++ in my job.
Performance section is completely not true. Not even 1 %. Rust can compile code much more optimized for several reasons one of them is rust compiles all libs and program at ones stacticly linked hence rustc has more opportunities for optimization. And more such things are zero cost iterators etc..
Wrong, C++ is one the best OOP languages out there and the OOP features are very mature and overall good. Making abstraction is easy. In fact, Rust is horrible at OOP with its weird syntax. The issue is that most people who switch to Rust are coders who fail to even understand basic C++ and how memory actually works and Rust is a good option because the Compiler manages the memory for you. This is why experienced C++ programmers and C++ code bases don't switch to Rust, because there's no need to.
@@allObeserving I do agree that after mastering one tool, learning another one can be pointless. Rust can composition over inheritence which is good. But again OOP is inherently flawed; do you really have a neat hiarerchy where parent object talks only to direct children? Either you have some web of messages and/or pointers going everywhere, or you have to not let the different layers from the God object interact with each other without talking to a subgod objects..
@@yokulen545 from a quick search online, Tauri, Druid, Slint, gtk-rd, iced ect crates do already exist. Not sure why it would be impossible for gui framework to be decent just because it is written in Rust.
Rust is cool but it feels like it's all over the place with what it's trying to achieve. There seems to be no order to this madness. I tried to write an Actor Framework in it and it was absolutely painful. You would expect the users of you framework to do a lot of set up just to get things done unless you resort to macros.
You misunderstand the ownership system in Rust. It has checks, that is true, but they are all at compile time. Because of them, compiling is slower. But since the compiler proved that the code was safe, the checks are not present during execution, so there is no performance penalty for them.
There is a way to opt into runtime borrow checking if you use a variable in several threads, but yea by default it adds work to compiler
I prefer the more specific syntax of c++ personally, just because I think it's cool to have that level of control over the program (as a c++ programmer).
I think rust is really cool tho, not everything is about raw speed, sometimes you want a solution that works every time no matter what; that's a lot harder in c++
I too like C++ better. I somehow can't even look at Rust code.
I also think Rust macro's are important part of the language. In C++ they are not that good, in Rust it can allow you to use a new language that is compiled to Rust and has all of the nice errors of Rust. And if speed is needed, unsafe Rust can be used to speed things up while creating safe abstractions.
It seems that the difference between compile time and runtime aren’t your strong suit, and I would recommend you learn about it since all of Rust’s checks happen at compile time and do not impact performance outside of Debug mode
This is very biased
2:58 there are options for game dev in Rust. Godot scripts can be written in C++ or Rust, and there are engines in Rust. I think best at the moment is Bevy, even if it is not 1.0 yet.
I noticied a slight error. Rust's ownership and borrowing model manages resources ((e.g.) a heap allocated memory, open file descriptors, network sockets, etc., ) and their lifetimes, which involves huge compile time validation. But in C++ they are left to the programmers to manage the resources. If programmer makes an error in the resource management (like dangling pointers), it will result in system instability and vulnerabilities. During runtime there is no performance overhead.
Except may be for bounds checking in rust. In my opinion the performance difference is very insignificant, unless bounds check is present in a hot path. It can be easily disbled for specfic parts of the code using unsafe.
I do C++ in my job.
Performance section is completely not true. Not even 1 %. Rust can compile code much more optimized for several reasons one of them is rust compiles all libs and program at ones stacticly linked hence rustc has more opportunities for optimization. And more such things are zero cost iterators etc..
2:17 OOP is not that good. It's really hard to make good abstractions
Wrong, C++ is one the best OOP languages out there and the OOP features are very mature and overall good. Making abstraction is easy. In fact, Rust is horrible at OOP with its weird syntax.
The issue is that most people who switch to Rust are coders who fail to even understand basic C++ and how memory actually works and Rust is a good option because the Compiler manages the memory for you. This is why experienced C++ programmers and C++ code bases don't switch to Rust, because there's no need to.
because of no OOP in rust , rhst doesnt even have decent gui framework like Qt
@@allObeserving I do agree that after mastering one tool, learning another one can be pointless. Rust can composition over inheritence which is good. But again OOP is inherently flawed; do you really have a neat hiarerchy where parent object talks only to direct children? Either you have some web of messages and/or pointers going everywhere, or you have to not let the different layers from the God object interact with each other without talking to a subgod objects..
@@yokulen545 from a quick search online, Tauri, Druid, Slint, gtk-rd, iced ect crates do already exist. Not sure why it would be impossible for gui framework to be decent just because it is written in Rust.
@@allObeserving Hell yeah Rocky. 🤘🤘🤘👍👍👍 respect
Thanks for your video. I was looking for a bench mark where C++ beats Rust (I only found contents that go the other way around)
Rust is cool but it feels like it's all over the place with what it's trying to achieve. There seems to be no order to this madness.
I tried to write an Actor Framework in it and it was absolutely painful. You would expect the users of you framework to do a lot of set up just to get things done unless you resort to macros.