hi! thanks for this... I'm fairly new to rust and low level programming in general, what does it mean to handle remaining bytes? And how can I do that?
it wont stop their devs from using their awful coding habbits. changing the tool doesnt change the quality of the people who use it. its not hard to write memory safe c. arena allocators are an easy way to do that. code conforming to raii is not ever going to be good. things like smart pointers are unnecessary when you actually properly manage memory. having a create and destroy pattern and dynamic allocation is not necessary in the way its being done.
Yep, you are right. Rust can't "solve" bad programming. That indeed. But it has guard rails that reduce the cognitive complexity of some tasks, and that frees an engineer's mind to think about more important things than whether they've correctly terminated a string or freed some of that memory they allocated on the heap. :)
Looks at title and thumbnail.. ah it's another basic beginner topic. Let's give the guy a minute to talk ... Video starts.. video ends.. liked and subscribed ❤ Thanks
How about going from C to Rust and back to C. Will a well formed code transcompiler do a good job of maintaining safety if you move from Rust to C. One step further, why not just take the Rust compile time checks and somehow put that in a c compiler say in a CLANG compiler.
@@oliverjumpertzme ADA devs are well paid, find them is gold. Rust will be cheaper in the long term due to mass adoption. Rust is young, I used a bit for internal R&D but I already use VHDL, so reading ADA is personally much simpler than Rust for me to understand.
It does not have all the guarantees of Rust, and a smaller community/ecosystem. Rust has marketed itself pretty well, imho, and it has a very active community. Those are plus points in a comparison. ☺️
@@falex3489yes, but it is way too young right now, imho. I think Rust has the luck to tick all the right boxes for the moment. As a Rustacean, I'm happy, but no one can tell how it'll be in 5 years. ☺️
Just because one can easily have sound effects as things appear and disappear does not mean that one has to or that it is a good idea. I find all these superfluous noises really annoying. As are the random images that flash up for no particular reason.
@@Heater-v1.0.0 the critique itself is right. I wanted to release it without any overly hefty sound, but someone convinced me not to. Watching other tech creators' content shows that most don't use effects because it probably distracts too much. I’m think I am better off without the sound effects, and I will tone down the animations. I won't go without them, but I will tune the ADHD level down a bit. 😉
@@oliverjumpertzme I feel that one of the most important things in a vid is the creator, their character, personality, style. That has to shine through. Almost as important as the actual informational content. The extra fluff of sound effects, animations etc is unnecessary. That's not to say some sprinkling of animations/sounds cannot be entertaining and useful. But I feel they have to be appropriate, imaginative, preferably unique, and reflect the creators personality. A difficult thing to pull off I'm sure. Anyway wishing you the best for your work.
I love the example code at 3:54! Is that actual real code, or something you have summarised, or something you've made up yourself just as an illustration???
It's demonstrational code, but how I would probably implement a naive version of an integer addition with inline assembly. ☺️ Or in other words: with all my examples, I try to spend a lot of time trying to come with something realistic, which doesn't feel too constructed. Admittedly, I don't always to succeed, but it makes me happy to read that you like this particular example. ☺️
If I want use trait functionality on a external data type I wrap it in a function pointer and in the trait I have a function to get the data type so that I can use it in the functions of the trait.
I can argue that the product of two 3D vectors should be neither a scalar, nor another 3D vector, but rather a _quaternion,_ but that's a whole can of worms. Technically, the ==, !=, <, >, <=, and >= operators are also overloadable, but their traits are stored in a completely different module, and their output type is _always_ bool, rather than being overloadable. There are 2 operators in Rust that I'm away of that are _not_ overloadable at all: && and ||. This is because they aren't actually equivalent to passing the two sides into a function call, since they only evaluate the right-hand side if necessary, which can have observable side-effects. Theoretically, it should be possible to make the override methods take functions for the right-hand side rather than values, but that means for more generic parameters and automatically boxing the expression in a closure... and it's just not really worth it when | and & are perfectly fine for most cases.
Regarding your first point: Yep, I specifically chose one way to do it to make my point. 😁 Regarding the other operators: I don't even consider them real operators, or at least not overloadable ones because their usage is baked into the language. Eq, PartialEq, Ord, and PartialOrd, etc. are all used by sorting algorithms and co. They are those operators you cannot change any meaning for. They will always have something to do with equality, or comparison, while for all the ones I have mentioned in the video, that's not the case. ☺️
going further with this, many libraries for geometric algebra (which contains quaternions as a subset of some algebras) have convention for when to use the inner (dot) product as | and exterior (cross) product as ^. there conventions exist across programming languages so I would argue in that sort of situation using those operators make sense.
@@ikhu6042 absolutely! If you can get a consensus on what to use when, that is absolutely fine. Code style is always a subjective thing bound to a specific context. If in a certain context, the rules are clear, you should ofc make use of what a language offers you! Thanks for adding this. ☺️
@@ikhu6042 I actually dislike this particular convention, since outside of GA, the same symbols have different but related meanings. The exterior product is ∧. In order theory, ∧ is instead the meet. The GA version of the meet is related to the intersection, which is ∩ and often defined in terms of AND, which uses the symbol ∧. Many programming languages when representing a set type already overload their operators to use the same symbols for both AND and set intersection. The result? The GA exterior product, _especially_ when using PGA / mirror-space, should use the & operator; same as AND. Similarly, the symbol for the regressive product ∨, which in mirror-space is also the join, is also used for the... join, as well as the OR operator, and visually resembles the set union operator. As a result, the regressive product should be implemented as | rather than &. As a cherry on top, the OR operator, the join, the union, and the regressive product are all dual to the AND operator, the meet, the intersection, and the exterior product respectively. This means that !x & !y = !(x | y), regardless of which system you're in. This one, GA libraries thankfully get right. Inner product honestly just gets the last option remaining, which is XOR / ^, which does make some sense, but it's less compelling than the other three. TLDR: choose operators based on their meaning, not based on the fact that ^ kinda looks like ∧.
Worth mentioning that the use of operators is kinda discouraged in Rust. Because they are not fallible. I.e. things like integer division by zero panic in runtime. Other arithmetic operators panic on overflowing/underflowing in debug mode. Index access panics on non-existing index. That's why it's encouraged to do 'n.checked_div(m)' instead of 'n / m', 'vec.get(n)' instead of 'vec[n]' etc.
Yea, if I think about it now, I could have mentioned that explicitly. :) That is why we have the system in place we have no, to prevent this uncontrolled spawn of operators and overloads that are, as you said, in no way fallible. Thanks for mentioning it here!
Hey, thanks a lot. Yes I did. Was my own stupidity as I still had the original recording under the audio-edited one. 😫 easy fix, but cost me the algorithm. Still great to see some people get to watch the video as it was intended to. ☺️
I often find after implementing these operators for my type T, on either side, then if T is not Copy then have to implement them for &T on both sides as well, for T and &T, and it just balloons out of control.
I've encountered this too, however some solutions I found in some popular crates (such as num) is to reduce such repetitions is to just macro-ize them instead and implement them for all of the derivatives.
@@oliverjumpertzme still learning Rust, I have just a basic idea about From, Try, Into… thank you concern! I will visit your video on future. So, you already helped.
ok.. - with the TryFrom you said it again, but now I understand what you mean.. You were talking about the blanket impls and not the type in itself.. So "a type that is Into implies it is From", but "implementing From" automatically "creates an implementation for Into", meaning "it implies the existence of an implementation of Into". But maybe my brain is wrong, or too nit-picky ;) Anyway, great videos!
more nit-picking... sorry :) 14:30 this is not the "newtype idiom", but standard struct composition newtype is a thin wrapper around a type, mostly a zero-cost abstraction, so most of the time a tuple type like: struct Bytes(u32); struct Kilobytes(u32); (with possible conversions implemented) to prevent accidental mismatches in fn copy_data(data: ..., length: Kilobytes) {...
@@oliverjumpertzme Not yet, I am still very much working on the core features. The parser and the code checker. And then I will work on codegen and stuff.
I have saved this video in watch later since it came. Today I completed this tutorial and I would like to thank you so much for such a golden content. I request you to make a fully fledge axum server with jwt authentication and user & role management please.
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
