As with other Rust presentations, I like Rust's features but am disgusted by how it looks in the editor. Still enjoying writing Ruby in all its object-based goodness and arbitrary-precision data types; only rarely extracting any hot spots into external binaries written in clean C. Ruby + C >> Rust (at least for me). Great vid though. Subbed, cheers!
This was a nice video, which I didn't expect given the baity title. I'd also like people to mention more often zero "runtime" cost. Rust and c++ take far longer to compile because of all this. It has cost every time you hit build, which is important to me too
This is not true at all. Actual performance comes from good cache utilisation, good cpu utilisation, and good utilisation of dead time while processing io. None of which the compiler can do for you. Good cache utilisation comes from understanding what data you need to process and when. Packing said data into as small a space as possible, to get as much as possible into the cpu cache lines. See data oriented design. Good cpu utilisation comes from using threads and SIMD. And making sure there are as few synchronisation points as possible. Good dead time utilisation comes from async in Rust and many other languages.
Sorry, but no. The compiler can do quite a lot of it by generating code that makes best use of the concepts the target architecture provides (that's mostly LLVMs job). As I have presented, the compiler can also make use of SIMD on its own in some circumstances. And the most important part is: in 99% of use cases, hand-optimizing code is a severe waste of time and resources.
Theres no such thing as a "compiled language" Theres only "languages with a native compiler via direct or indirect means". Also worth noting that performance doesnt matter for 99% of uses that dont produce video. They can all be handled by using cloud machines instead of user machines and streaming down the content since non-video content is tiny and cloud bills are way way smaller than engineer bills. Especially with VPSs and coolify. Performance is mainly a "get the 5% right". As long as you arnt doing the abysmal things any further thought about performance is a huge waste of time unless you are doing it because you find it fun.
@@oliverjumpertzmeFirst of all something being on wikipedia doesnt mean its correct. And second that artical in itself says that the colloqueal usage is illdefined and vague. My statement is litterally backed up by the wikipedia artical. The wikipedia artical says there isnt a firm definition, the definition is vague. Id say under most usages of "exist" people are refering to firm and real. For example a "vaguely human" thing isnt a real human. And even if you want to argue about what "real" is and if a word without a firm definition is "real" or not, you still use the term in your video to no benefit.
Some of my professors from university then want to disagree with you, together with me. ☺️ Oh, and I don't want to argue here. You made an _absolute_ statement, which was just wrong. That's all I am saying.
Thanks for the tip! 💛 If you are curious now: Some things are super difficult to model in Rust because they actually are usually difficult to get right. Try to implement a LinkedList for example. You'll lose a few nerves, but learn A LOT about the language, the borrow checker, and how Rust gives you rails. 😁
I'm still in favor of Rust for the majority of applications BUT... Aliasing is a difficult topic. In Rust presence of aliasing *usually* excludes mutability. It is good for performance but cases where you need to share mutable data are difficult. Rust relies a lot on macros, compile-time checks, and optimization. So you're paying the cost for abstractions at compile-time instead of debugging-time and runtime. Some may feel less productive because they end up waiting for the compiler instead of debugging. However, it's usually an illusion because the computers are doing compile-time checks really fast. Rust has many facets, which may make it difficult to learn, if you try to learn *everything*. In practice, you don't need to know everything about Rust to write correct code. Rust's lifetimes are invasive (because they reflect the complexity of software). Raw pointers are simpler but also introduce lots of ways to shoot yourself in the foot. Rust just formalized the rules about pointers, and created a safe abstraction over them. Rust inherited the mistake with sizeof in C and C++. In Rust, just like in C and C++, there's no easy way to get the size of the struct without trailing padding. Rust doesn't have variadic generics, unlike C++. You can somewhat circumvent the problem with procedural macros but it's still a PITA. Rust's expressiveness limits what its generics can do compared to C++ templates. For example, there's no way to express that type F that implements Fn(/*args/*) -> /*output type*/ does not capture variables and is safe to coerce/cast to a function pointer. Currently, the bounds of lifetimes are not expressive enough, because they can express only ">" (outlives) requirement but not ">=" ("lives at least as much as"). In Rust there's an implicit assumption that rustc makes that expression of type &'a &'b T carries a proof that 'a outlives 'b but it's not the case for a and b being 'static lifetimes. This caused the creation of cve-rs. Luckily, Rust can create a breaking change that would fix the problem (unlike C++) but it's a huge deal in my opinion.
One zero-cost abstraction that wasn't mentioned that managed to really impress me was coroutines (the underlying mechanism behind async/await and generators). I already knew that Rust compiles coroutines to a completely normal state machine, consisting of an enum and a method that matches on said enum, but needing to "await" the completion of a separate coroutine abstracted into another function would still have a lot of overhead... _right?_ Nope. Even though my code had multiple levels of coroutines awaiting each other, and at the top level two separate coroutines being weaved together, when I actually looked at the assembly, I didn't even see a single call instruction. The entire thing had been inlined into a single massive state machine, exactly as I'd hoped it would, but was surprised to see anyways.
Technically, I didn't even leave it out because Rust is special regarding async/await. It has no own implementation but instead delivers the primitives necessary for external libs like tokio to implement their own runtimes. ☺️ So, the state machine you're talking about is (I assume) Tokio being compiled down to super simple code by the Rust compiler. 😁
@@oliverjumpertzme I specifically said "coroutines", because this wasn't using async/await, though it did use a manual macro implementation of await. This project was more interested in making two threads of execution run in perfect lock-step with each other. As a complete side effect of this, it forced a very elegant way to transfer information to and from the coroutines, since every synchronization point aligned with one of these information transfers (whether it was necessary or not :P).
@@oliverjumpertzme Regarding the topic. You still have to think about code very carefully. I'm currently working with Rust legacy codebase, it's insane what people can write.
@@GillesLouisReneDeleuze didn't deny this. You surely have to take care and pay attention to the context around you. The essence of this video is just: no need to micro-optimize because you think the compiler will not create the best result possible. There are cases you have to hand-optimize, but these are rare. ☺️
i know i probably don't need to know this to get started, and i came here because i like learning about the complicated details, but programming seems to have the unique effect of being very quick to make me realise how out of my depth i am, that astrophysics or rocket science takes a lot more effort to do.
I’m learning rust, and studied some C and Java in high school. I think it mostly comes down to literal language. Eventually the video lost me too, when the rhetoric leaves the scope of terms I know. I think about it like video games. Once you are experienced in a game you often use language that is completely foreign to outsiders.
Hehe, don't worry. Many of us feel this way. ☺️ I think the great thing about programming languages and programming is that we build on many abstractions. You don't necessarily need that low-level knowledge for many use cases. It's nice to have and comes in pretty handy when you really need it, but otherwise, things still work if you don't know every little detail. ☺️
It probably doesn't matter (much) because Rust is typed and compiled and throws away everything unneeded. Scripting languages are different story, not knowing the full context, they have to keep all abstractions and metadata and thus are really, really inefficient with lambdas and closures.
Yep! Although some JIT compilers can also do quite a lot. But if they assumed a path wrong, they need to throw that away, run the interpreted script again and gather more data before they can JIT compile again. ☺️
a good follow up is “there is no such a thing as a zero cost abstraction” by chandler carruth, a lot of the essence of the cpp lectures also apply to rust
To be truly the same as an int, I think you should be deriving `Copy` on Duration & co, and using "self" instead of "&self". Although, in these simple cases the compiler will assumedly figure it out.
Afair, yes, the compiler should be able to figure that out. But you don't need Copy for Duration, as i64 is already Copy and transparent directly inherits that i64. ☺️
Rust iterators and iterator pipelines are really amazing. I found them more efficient and versatile to use than what C++ is bringing to the table here (even more so given that most C++ toolchains do not even implement C++20 ranges to the full extent). And in optimised builds the rust compiler beats the hell out of them and delivers code that runs at least as fast as an imperative solution, if not faster - even if that imperative solution is written in C. Great video.
Everyone claims claims as fast as C and every single time I look at a benchmark it's like 2x to 3x slower lmao. If being almost as fast as C or C++ means being anywhere from 2x slower to like 8x slower, then it's not close lol, I really dislike this cope
Nah, it depends. There are no absolutes in this. Sometimes Rust is faster, sometimes Rust is slower. Often Rust is on par. There is, however, still a long way to go and quite a few things rustc, as well as LLVM , can still improve.
I personally feel like I'm in the "Make it readable spectrum" where whatever performance gain and nut cracking you get from trying to get performance with "clever" code is not worth the future issues
I get you. But that is where comments in code eventually become useful. To learn Rust, I did some leetcode problems, and I worked on my solutions until they run at least as fast as efficient C or C++ solutions of the problem, as I was really interested to see what Rust is bringing to the table here. With one problem (the "trapped water" problem) I had three iterations of the solution, and each one looked very different from the one before - and the final one needed extended comments to make me still understanding it after a break for the weekend as it exploits some not obvious properties of the problem to run fast. Now, you can get away with less then optimal solutions for many computing problems, but if you are in for e.g. algorithms for image, video or sound processing (or automatic trading), performance is key. And in the systems programming domain, where OS kernels, drivers, compilers and interpreters and .... are written, you do not want to waste performance on that low level. Keep headroom for all those poor JS or Python guys to make use of their favourite language instead of forcing them to actually learn something good. Otherwise they may come after you and blow your poorly written interpreter out of the water. Furthermore in times where much code is run in the cloud and gets you billed for CPU and memory usage, efficient code will save you money. There are some quite impressive success stories of "rewrite it in Rust" for cloud-executed code on the Internet, reducing costs by 90%.
I don't really understand how we got to the point of blaming the code for architectural failures. Or how we got to the point where we 'always' do it 'insert slogan' way no matter the problem domain. Writing more efficient code should be the objective. Unreliable architecture is not the fault of the efficiency of the code or how many lines it is. Complexity is not the issue. Not understanding what you've built is. When speaking to friends, specifically, or rather most often, those who work in corporate environments, always push clean code and things like composition over inheritance, and it seems to be that their reasoning is because it's easier understand. This seems inherently flawed. The reason for this being that this argument is essentially claiming that the code should be lowered to a level that the least experienced developer can understand rather than to the level of the most experienced and bringing those less experienced to a higher level. I suspect this is why these companies are so bloated and inefficient, employing hundreds of developers that write very little code per day when it could be done by a much smaller team. I watched an interview with the founder of telegram and he spoke about a conversation he had with Jack Dorsey whe he ran Twitter. The guy from telegram asked him why he had so many developers he didn't need. Dorset said because if he didn't his company's stock would fall. I would then posit one should not adopt the practices of companies that knowingly choose quantity over quality and bloat over performance for their shareholders, not because it produces a better product more efficiently.
I basically left Twitter behind. The platform is not what it used to be anymore. :/ I loved it there but if no one sees your posts anymore while Elon says the algorithm is fine, doesn't make much fun.
Honestly, if you continue building real-world useful applications like this with Rust, you will be entered into the hall of fame. However, I've realized that Rust RU-vidrs often give up too quickly, after just one or two videos.
Yes, but it swallows any errors. From the documentation: ”It is critical to call flush before BufWriter<W> is dropped. Though dropping will attempt to flush the contents of the buffer, any errors that happen in the process of dropping will be ignored. Calling flush ensures that the buffer is empty and thus dropping will not even attempt file operations.” :)
Great video. Just came from reading your dev.to "how to read files in rust" article, then your personal blog and now your youtube channel. I like the way you teach and I'll certainly be looking forward to more of your videos. I would really like to know what areas of rust that i should really try to understand so that i can have a solid knowledge of the language. Thanks!
Hey, super happy to read that! <3 To answer your question: It fully depends. The great thing about Rust is that there is a variable set of features you need to know, mostly depending on what you want to do. I think the best general advice I can give is: Pick something (backend/micro service dev for example), build stuff, and learn along the way. :)
