A really interesting trend I've noticed is even people who hate Rust far prefer other people write in it if they need fo work together. It's all well and good to have some other language (C, Python, Zig, Java, anything) that you might be faster in, hut your 20% extra productivity is immediately lost in how you work with other people. And when you consider that you from fhe future is a different person, Rust becomes a complete no-brainer.
How does writing in Rust help with not having to update the code? It's not clear from this video that there is any maintenance gain other than saying the code is just easier to understand which is highly subjective. Libraries will change. APIs will change. Hardware will change, so why would your rust code require less updates?
There are quite a few angles to answer this from. It all comes from the strong type guarantees. Having a strong type system with low-cost enums and exhaustive branching means you can get compile-time guarantees about whether you've properly changed all the places that would need to know about this new update. I don't write modern C++, so I can't speak on it too much, but my understanding is that it lets you make changes not backed by strong type signatures, so you can have what feels like "dynamic typing" of enumerated values. You can add a new option, but you don't need to exhaustively handle this new enum case in different parts of your code.
@@brukts3361 Thanks. Interestingly I reached out to the creator of the video and he snarkily refused to answer me. I appreciate not everyone in the Rust community is like him.
@nickjunes well, you are putting words in his mouth that he never said (he did not say rust code needs fewer updates, his main point was that rust code is cheaper to update). So what do you expect?
So like is Rust just the best shit ever invented or what… I’ve made a few loaders and a PE parser as my first rust projects and like I’m not convinced this is the savior language.. performs the same, if not slower than my c code… and takes 10x longer to complete due to its insanely freaky deaky syntax and the base language it self outside of third party crates is extremely bland… I don’t even think you can natively interact with Windows process using rust without installing another crate lmao
@@ClearerThanMud a bunch of stuff in the std? You mean having a native way to interact with the OS without installing third party crates, then yes.. I want that
@@Quarkss Third party crates in rust are, compared to in other languages, a fairly trivial matter in this ecosystem, and there are many benefiis to *not* immediately upstreaming them (moving them into the language). Without, the compiler has less surface area for bugs and less surface area also means higher iteration speed for compiler devs. Perhaps more importantly, it allows breaking changes without a whole compiler edition change. Upstreaming a crate into the standard library or even spiritually into the language itself is something that continues to happen as these third party crates that are deemed invaluable continue to stabilize on a long term API and do not need further updates. I am aware this is not exactly what you have said, but your comment is related to another common complaint that the language is not stable and settled. You cannot *both* complain that rust is not "stable" enough to use compared to virtually unchanging languages (C) and also complain that it doesn't have enough in it when it already has so much compared to everything but the one language that everyone agrees has way too many bad things in it (C++). Rust aims to be reasonable for most purposes, which is obvious if you pay attention to its development.
lol, in the case of the C++ code you're using a low-level API (poll() syscall directly) yet, in teh Rust you're using high-level APIs that wrap all that. Comparing these two is idiotic. That is NOT idiomatic C++ - that looks and smells like C code. Not C++. There's plenty of high-level wrappers for this in c++ yet you use low-level C-style code. Nice one.
Your critic is targeted at whoever wrote that code, but that's just valid and common C++ code (unfortunately? still, we don't know the reason it's that way) I'd also add that in Rust the main abstraction to poll is made by the async runtimes which C++ lacks, what C++ abstraction do you have in mind?
@@NotherPleb asio is the main one and it has decent async abstractions. C++26 is getting senders/receivers as an async abstraction together with co-routines. Async in modern C++ is really nice.You can already use it in C++23 via the reference implementation.
You seem to have successfully anɡered people on the internet, seeinɡ as you ɡot ThePrimeaɡen to speculate on your comparison methods without watchinɡ a sinɡle second of your ɡreat talk :p
Theprimagen still wasn't wrong though. It's all anecdotal still. Fresh rewrite of a legacy codebase is easier to read? Shock. You could rewrite that in c++ and people would say the same thing, the language had less to do with the readability. Probably the skill issue of colleagues.
Kotlin mentioned.
Good Talk. Missed a proper comparison with Go though
Lars please go to Nvidia Next and make them use Rust
and force them to open source it
No. We need them to have more memory safety bugs in the firmware so that we can exploit them and RIIR on our own
@@RenderingUser I doubt they will do that as they are market leader
A really interesting trend I've noticed is even people who hate Rust far prefer other people write in it if they need fo work together. It's all well and good to have some other language (C, Python, Zig, Java, anything) that you might be faster in, hut your 20% extra productivity is immediately lost in how you work with other people.
And when you consider that you from fhe future is a different person, Rust becomes a complete no-brainer.
Is he comparing new development in go to a rewrite in rust?
sure seems like it lol
He's comparing rewrites in C++ with rewrites in Rust.
"Go Forth" lmao
powerpoint is so small
How does writing in Rust help with not having to update the code? It's not clear from this video that there is any maintenance gain other than saying the code is just easier to understand which is highly subjective. Libraries will change. APIs will change. Hardware will change, so why would your rust code require less updates?
There are quite a few angles to answer this from. It all comes from the strong type guarantees.
Having a strong type system with low-cost enums and exhaustive branching means you can get compile-time guarantees about whether you've properly changed all the places that would need to know about this new update. I don't write modern C++, so I can't speak on it too much, but my understanding is that it lets you make changes not backed by strong type signatures, so you can have what feels like "dynamic typing" of enumerated values. You can add a new option, but you don't need to exhaustively handle this new enum case in different parts of your code.
The point is you can fearlessly refactor it with compiler making sure you don't break anything (logic errors may exist obviously)
@@brukts3361 Thanks. Interestingly I reached out to the creator of the video and he snarkily refused to answer me. I appreciate not everyone in the Rust community is like him.
@@joaodiasconde thanks.
@nickjunes well, you are putting words in his mouth that he never said (he did not say rust code needs fewer updates, his main point was that rust code is cheaper to update). So what do you expect?
So like is Rust just the best shit ever invented or what… I’ve made a few loaders and a PE parser as my first rust projects and like I’m not convinced this is the savior language.. performs the same, if not slower than my c code… and takes 10x longer to complete due to its insanely freaky deaky syntax and the base language it self outside of third party crates is extremely bland… I don’t even think you can natively interact with Windows process using rust without installing another crate lmao
It sounds like you consider having a bunch of stuff in the std library a good thing. There are good arguments against that, no?
@@ClearerThanMud a bunch of stuff in the std? You mean having a native way to interact with the OS without installing third party crates, then yes.. I want that
@@Quarkss Third party crates in rust are, compared to in other languages, a fairly trivial matter in this ecosystem, and there are many benefiis to *not* immediately upstreaming them (moving them into the language). Without, the compiler has less surface area for bugs and less surface area also means higher iteration speed for compiler devs. Perhaps more importantly, it allows breaking changes without a whole compiler edition change. Upstreaming a crate into the standard library or even spiritually into the language itself is something that continues to happen as these third party crates that are deemed invaluable continue to stabilize on a long term API and do not need further updates.
I am aware this is not exactly what you have said, but your comment is related to another common complaint that the language is not stable and settled.
You cannot *both* complain that rust is not "stable" enough to use compared to virtually unchanging languages (C) and also complain that it doesn't have enough in it when it already has so much compared to everything but the one language that everyone agrees has way too many bad things in it (C++). Rust aims to be reasonable for most purposes, which is obvious if you pay attention to its development.
lol, in the case of the C++ code you're using a low-level API (poll() syscall directly) yet, in teh Rust you're using high-level APIs that wrap all that. Comparing these two is idiotic.
That is NOT idiomatic C++ - that looks and smells like C code. Not C++.
There's plenty of high-level wrappers for this in c++ yet you use low-level C-style code. Nice one.
Your critic is targeted at whoever wrote that code, but that's just valid and common C++ code (unfortunately? still, we don't know the reason it's that way)
I'd also add that in Rust the main abstraction to poll is made by the async runtimes which C++ lacks, what C++ abstraction do you have in mind?
@@NotherPleb asio is the main one and it has decent async abstractions.
C++26 is getting senders/receivers as an async abstraction together with co-routines. Async in modern C++ is really nice.You can already use it in C++23 via the reference implementation.
@@NotherPleb asio
You seem to have successfully anɡered people on the internet, seeinɡ as you ɡot ThePrimeaɡen to speculate on your comparison methods without watchinɡ a sinɡle second of your ɡreat talk :p
avatar checks out.
Theprimagen still wasn't wrong though.
It's all anecdotal still. Fresh rewrite of a legacy codebase is easier to read? Shock.
You could rewrite that in c++ and people would say the same thing, the language had less to do with the readability. Probably the skill issue of colleagues.