Видео

Hey, thanks a lot! 💛 Regarding your question: I think we need to distinguish between errors and bugs here ( once again :) ). The question, thus, is: Is your response not building correctly a real bug or something you should expect and handle? First of all, I'd make sure that your route handler either returns a Result<Response, SomeError> or something like Result<Response, (StatusCode, String)> (because the latter can easily be converted to a valid response by axum's buit-in converters). If you return a non-dynamic response, i.e. no dynamic contents or just little, mostly statically defined in your source code, I'd still use expect because if that Response doesn't build, that's a real bug. An example of the sole return statement of a handler function: Ok(Response::builder() .status(StatusCode::TEMPORARY_REDIRECT) .header("Location", "example.com/redirect-url".into()) .body(Body::empty()) .expect("This response should always be constructable")) There is nothing really dynamic in this response and building that should not fail if you do everything correctly. Or let's say: If something fails, that's a bug. If you have a highly dynamic response that you can't really control, I'd map to an internal server error, like so: Ok(Response::builder() . status(StatusCode::OK) .header("Cache-Control", DEFAULT_CACHE_CONTROL_HEADER_VALUE) .body(json!(response_object).to_string()) // given some Error implements IntoResponse, so axum can convert it correctly .map_err(|_| SomeError::INTERNAL_PROCESSING_ERROR)?) or Ok(Response::builder() . status(StatusCode::OK) .header("Cache-Control", DEFAULT_CACHE_CONTROL_HEADER_VALUE) .body(json!(response_object).to_string()) // given your return type is Result<Response, (StatusCode, String)> .map_err(|_| (StatusCode::INTERNAL_SERVER_ERROR, "Processing failed".into())?) But I think to have understood that you do something like this?: get_optional_value() .ok_or_else(|_| Response::builder().status(StatusCode::NOT_FOUND).body(Body::empty())...???) If that's the case, I think the same rules apply. If it is completely static, use expect. Your hard-coded response not building correctly is a bug: get_optional_value() .ok_or_else(|_| Response::builder().status(StatusCode::NOT_FOUND).body(Body::empty()).expect("Oops, bug!")) If it is highly dynamic, you have a problem because your return type basically needs a Response but building that response is fallible, which would lead to an infinite loop of map_err's with question marks (I hope you understand what I mean). So my suggestion: Either make your peace with expect, or change the return type of your handler function to something more flexible like: Result<Response, (StatusCode, String)> or Result<Response, impl IntoResponse>, which gives you a lot more flexibility to define your errors. Alternatively, create an error type that implements IntoResponse (which also carries the risk of having to build a fallible Response again that...yea...might end in the same infinite loop of error handling). Does this help, or shall we go over this in more detail? :)

Hey, glad to hear that! Yes, it is. ☺️

Agree. Some cost is always associated with something. But as said: zero-additional cost would also be okay, for me. ☺️

I am well aware of that, but that was not the main point of the video, which is why I used an example everyone would understand, no matter their experience in Rust. ;) And no, multiple equals signs never panic. They just return an err because for this particular example, we only allow key=value. If you really want equals signs to be allowed in either key or value, I’d actually involve quotes in the grammar, like most sane languages and parsers do.

If you REALLY know what you're doing…you're free to. 😂

You can well do that. A common impl I see (and also use) is From<&str>, for example, and even String implements From<&str>. :) The only thing From implies (by the docs is): The conversion MIGHT not be cheap, or you MUSTN'T rely on it being cheap. It does not specifically say anything about the base value, although in theory, From is meant to take ownership. But in the end, it's perfectly fine to do that. The docs just list a few requirements that are usually associated with the conversion: 1. The conversion is *infallible* 2. The conversion is *lossless* 3. The conversion is *value-preserving* 4. The conversion is *obvious*

Yep! The "really" best way to express the problem in Rust is probably this implementation (as already shown and discussed in other comments): fn try_from(input: &str) -> Result<Self, Self::Error> { let mut split = input.split('=').map(str::trim).map(str::to_owned) match (split.next(), split.next(), split.next()) { (Some(key), Some(value), None) => Ok(Self{ key: key.to_owned(), value: value.to_owned() }), _ => Err(ParsingError::MalformedRecord(input.into())), } } I generally agree that I'd do it this way. In this case, I just had to make an easy-enough example to showcase the problem, which also does not turn away complete Rust newbies. So in general, in this example, you CAN "implement the problem away" by using more advanced language features. :)

@@oliverjumpertzme That's a creative way of using pattern matching. Didn't even cross my mind. I guess the only downside is it's allocating a tuple. Might use that in my parsing implementations from now on actually Also, I agree, sometimes just using "match" is better. Especially if you need to treat errors as "warnings" and use a control statement such as "continue;"

No, it would result in a: Record { key: "key", value: "" } :)

”The guy” had a point to make which was not to optimize each and every bit of some code. 😉

Yes. As shown. But for many programs, even a secondary thread panicking can bring the whole system down. ☺️

Do you mean: if split.len() != 2 { return Err(ParsingError::MalformedRecord(value.into())); } Yea, that also works. :) There are several ways to do it. I chose this approach to illustrate the overall thing better. Optimization is a good thing, but it often costs additional explanation. View this just as example code to prove a point.

Awesome! 💛

Awwww, I am sure I still have a lot to learn, but this makes my day…so thank you! 💛

Thanks for watching and the feedback 💛🙏🏻

Yes, that works, and it's completely valid, probably even better than this example, but tbh, I had to find an example where it really makes sense to use something like unwrap (and these examples really exist), which is why I went with this way of doing it. 😁

Also valid ☺️👍🏻

Yes! I reckon this is the best way.

Why forbid the value to contain '='? Just use `splitn(2, '=')`.

I love Rust, and that's in no small part down to its community. I would not have even considered doing it this way before seeing this comment, and yet it becomes so obvious (and so expressive) that I immediately prefer it. Thank you.

It depends. We're not using a sophisticated parser here. We need at least the length check to enforce the notation "key=value". Otherwise "key=value=value" would be interpreted as: Record { key: "key", value: "value", } while completely ignoring that the Record, in our example with a strict notation, was indeed malformed. Replacing the existing length check with something based on calling .get(2) and then reacting based on the presence of a value like: // this is btw what Clippy will tell you to replace if let Some(_) = split.get(2) with if split.get(2).is_some() { return Err(ParsingError::MalformedRecord(value.into()); } is also no good alternative, imho. Yes, the vector API can do a lot, thanks to its Options, but the question always remains is: Is that code necessarily better? Imho, not, but how well someone likes a certain style of programming is subjective! If we already use one check, the other check also doesn't hurt and even reveals intention and serves as documentation. :)

@@oliverjumpertzme i disagree. It is not necessarily easier to read. But it is safer code as is doesn't rely on logical but not typed promises. Your version checks the conditions twice but panics if they don't uphold on the second check. In my opinion this is inferior to checking and getting in 1 go. Coupling extraction with handling of the lack of data is an innovation that your code doesn't use.

I think we can agree to disagree. I implemented your version, or what I assume to be your version, and it led to (imho) far less readable code (and a lot more of it). There is of course a way to convert from an Option to a Result, which allows us to do something like: let key = split.first().ok_or_else(|| ParsingError::MalformedRecord(value.into()))?; let value = split.get(1).ok_or_else(|| ParsingError::MalformedRecord(value.into()))?; in which I'd agree with you for this to be a better version. But it still leaves us with the length case of strict format enforcement, and I still advocate for: if split.len() > 2 { return Err(ParsingError::MalformedRecord(value.into()); } instead of adding something like either at the beginning (where it would be best suited) or after the other statements: if split.get(2).is_some() { return ...; } But once again, tastes are subjective. :)

I thought about this again, and I now believe that what you meant is code like this (also, someone else already posted it here): fn try_from(input: &str) -> Result<Self, Self::Error> { let mut split = input.split('=').map(str::trim).map(str::to_owned) match (split.next(), split.next(), split.next()) { (Some(key), Some(value), None) => Ok(Self{ key: key.to_owned(), value: value.to_owned() }), _ => Err(ParsingError::MalformedRecord(input.into())), } } This code is indeed superior because it completely avoids a panic at any time without changing the logic and completely stays within the warmth of Rust's advanced type system. I have even considered using it, but I have not used it in the video for two reasons: 1. It did not suit my case. You might not believe it, but there are still situations in which you can't optimize code to not use some form of unwrap. I have code of an RFC-9111-compliant parser in front of me that uses PEST to do the parsing of header strings. In there, I really have the situation that I cannot use advanced pattern matching because the absence of some AST nodes would actually mean that the PEG is broken. We can now argue that there MIGHT still be a way, but sometimes, you reach that point. We also have to take into account that sometimes, we all don't know the perfect solution for a problem, and for these cases, the main points of my video (imho) apply: Use expect, mark bugs explicitly. :) 2. I try to make my videos accessible even to Rust newbies, and the advanced pattern matching capabilities of Rust are often very difficult for them to grasp. I would probably have needed several additional minutes to explain what happens and why that is a great idea, while the main point of the video was a whole different. I hope this helps you better understand my point of view. :)

Rust has a lot of features that even I sometimes tend to forget about (and I use Rust daily 😂). It's like muscle memory. If you've just other languages for long enough, you first need to get used to new systems. Rust, eg. Has a pretty solid one, but that, admittedly, comes with many things to keep in the back of our heads. ☺️

Yes! 😁💪🏻

When there is no recovery possible, unwrap is ok

No, real men use unwrap_unchecked()

Hey, sorry to hear that. Let me think about that. To me, it feels liveless without them, but I can understand you. ☺️

@@oliverjumpertzme I appreciate the response. It could just be that the sounds seem too loud compared to your voice (at least with earbuds). Either way, thanks for the content 🙂

@@lukez8352 that's awesome feedback, thank you! I am still learning audio engineering. Maybe I need to tone it down further. Thank you again! 💛

@@oliverjumpertzme I agree with @lukez8352 on that the sounds was little too loud and I could only hear the effect in my left ear. I suggest you dont use stereo for them. I would keep the effects tho, they are great addition. Thansk for the video!

Please also consider making these sounds play on both channels. Currently, there's only a left channel and it's not pleasurable with headphones.

Thank you, Simon! And remember, you're my inspiration! 💛

Thanks a lot! 💛

Could you specify the question a little more? It's been a while since I created this video, admittedly. ☺️

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. :)

@@oliverjumpertzme so does using bump allocators

Damn, thanks a lot! 😁💛

💛 thanks a lot! Sehr gerne. 😁

Thanks a lot! 💛

Thanks a lot good sir! 💛🙏🏻

💪🏻😁

But wouldn't that make the language end ip being a lot like Rust? Most syntax it has is there for a reason. 😁

Even as a hardcore Rustacean, I agree, but I guess it also has to do with economics of finding and attracting talent. 🤷🏻‍♂️

@@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.

@@CallistoPilithat might be the issue then, yea. ☺️ And totally understandable you feel this way!

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. ☺️

​@@oliverjumpertzmeWhat about Carbon? Wasn't that going for a safe superset of C++? It's also backed by Google.

@@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. ☺️

😁

@@mdabdulaziz6589 Ada+Spark

Best idea 😂🙌🏻

In the end, it’s about safety 🤷🏻‍♂️

Ah! 🤔

You win today 😂💛

😄

Super happy to read that. Thank you! 💛

True! 😁

💛💛🙏🏻

K

@@oliverjumpertzme Sorry, I was a bit harsh there. I liked your vid, perhaps I'm oversensitive to these details.

@@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.

@@Heater-v1.0.0 thank you. Happy we could sort this out. ☺️

Davinci Resolve

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. ☺️

@@oliverjumpertzme Yes... a "nice" piece of example code is an art-form. :)

Yep, basically also a form of the new-type idiom to work around orphan rules. 😁