Unwraps aren't bugs, they're unhandled errors. When you start writing Rust, you write programs for yourself and when invalid input is passed, you just use the panic report for info. You don't fix "the bug" for unwraps, you handle the error to remove them.
Giving a talk is not easy, and the best delivery comes when you plan ahead and know exactly what you’re going to say and demonstrate. I think this one would have benefited from more prep, and less wandering around in the editor dealing with irrelevant compiler errors.
100% It would have been nice to have had more than 2h of notice before talking, but sometimes you get asked to fill in a slot for a speaker who pulled out.
@@ArmandoDoval they do not, why we still allow hidden control flow a la GOTO in our codebases several decades after decrying the very same for its faults is beyond me
I think Rust's support for exceptions is well handled via panic_any. It's for truly performance critical code where any failure means aborting the whole task and only hot-path performance matters. You really barely ever want to use it, but it's available for the extremes.
Exceptions work in C++ without GC. They also don't have to be "hidden"; the point of checked exceptions is that they represent exceptional cases that can arise even when using an API within its contract People make a fuss about checked exceptions (the initial Java class library didn't use them particularly well) but they're not dissimilar to specifying the Err side of a Result in terms of verbiage.
Nothing wrong with exceptions. As any tool, can be used in right or wrong way. If you volunteer to shot your own leg and use them as goto (as mentioned in comments) nothing can help you, really. You will find your way with any tool you have. I’m new to rust, but error handling looks like a pain. Though, I have an impression I maybe missing something. It looks unnecessary complicated. In the most of the cases I would like to have just something generic were I just can return an error, all receiver needs to know is if that was failure or success. I do not want new types. I also want to be able to handle all library errors in the same way - again in the most of the cases I just want to know if things failed or not, do not need specifics. All in all, analogue of “throws Exception”, in Java world.
Excellent talk!
Unwraps aren't bugs, they're unhandled errors. When you start writing Rust, you write programs for yourself and when invalid input is passed, you just use the panic report for info. You don't fix "the bug" for unwraps, you handle the error to remove them.
Giving a talk is not easy, and the best delivery comes when you plan ahead and know exactly what you’re going to say and demonstrate. I think this one would have benefited from more prep, and less wandering around in the editor dealing with irrelevant compiler errors.
100% It would have been nice to have had more than 2h of notice before talking, but sometimes you get asked to fill in a slot for a speaker who pulled out.
Wait, who's on first?
Not a hit on the speaker, oc. It's just another part of rust that's a bit wonky atm.
The lack of exceptions is a sign of quality. Exceptions should've never been a thing.
Exceptions do their job well, they just don't work without garbage collection.
@@ArmandoDoval they do not, why we still allow hidden control flow a la GOTO in our codebases several decades after decrying the very same for its faults is beyond me
I think Rust's support for exceptions is well handled via panic_any. It's for truly performance critical code where any failure means aborting the whole task and only hot-path performance matters. You really barely ever want to use it, but it's available for the extremes.
Exceptions work in C++ without GC.
They also don't have to be "hidden"; the point of checked exceptions is that they represent exceptional cases that can arise even when using an API within its contract
People make a fuss about checked exceptions (the initial Java class library didn't use them particularly well) but they're not dissimilar to specifying the Err side of a Result in terms of verbiage.
Nothing wrong with exceptions. As any tool, can be used in right or wrong way. If you volunteer to shot your own leg and use them as goto (as mentioned in comments) nothing can help you, really. You will find your way with any tool you have.
I’m new to rust, but error handling looks like a pain. Though, I have an impression I maybe missing something. It looks unnecessary complicated. In the most of the cases I would like to have just something generic were I just can return an error, all receiver needs to know is if that was failure or success. I do not want new types. I also want to be able to handle all library errors in the same way - again in the most of the cases I just want to know if things failed or not, do not need specifics. All in all, analogue of “throws Exception”, in Java world.
The Scammer. 😂😂😂