Is it just me or is the error handling in Go and/or Rust just.. tideous?

Maybe I'm biased because I grew up on C# and error handling has always been Exceptions and try+catch for me, but I find having to manually check errors everywhere not only annoying to code, but also horrible to look at.

Am I alone on this one?

At least for rust, It all kind of ties into predictability, and generally a railway style of execution. I actually do similar things in C# with switch expressions. I'm a huge fan of exhaustive checks on branching and control flow.

There's also a mechanism to propagate errors so you can create a global-ish error handler and not have to deal with them in every function.

It might be difficult to look at, at times, but it has a higher average performance than try-catch.

Eg, CPP has zero cost exceptions, which actually cost nothing, as long as nothing goes wrong.
However, when something goes wrong the costs skyrocket, which could slow down your code like fuck, when used in something like an event loop.

In Go, a typical error check boils down to 2 pointer comparisons.
One for the err!=nil and one for the type assertion.

While it is really quite verbose to deal with those errors, this is exactly the feature we low level devs want/expect from a language like rust.

I don’t know how rust goes about it but I actually like Go error handling personally.

@SortOfTested I guess you mean rust's ? Operator
That one works kind of but I had situations where I had to call .unwrap() three times in a row, just to get the extension of a file path.
I get the reasoning behind having to handle these errors, but syntactically it looks rather awful a lot of the times. Especially having to return something like Result<(), Box<Error>>
I know verbose code is good in principle but a lot of this seems unclean to me, as well I'm not used to the language.

@metamourge I get that performance is the top 1 priority, and I know that there are use cases where it has to be, but can we make the code look a bit cleaner?
Rust's syntax already feels complex as a beginner...

@LotsOfCaffeine
I see only one unwrap when getting the extension from a std::path::Path.

Path::new() can never fail

And

Path has a 'fn extension(&self) -> Some(&OsStr) ' function that's needs unwrap as it can either return Some with the extension or None when the path has not extension.

Also these are not errors but the Option Enum

@fuckwit but then I need to call to_str and to_lowercase which both need to unwrap as well...

@LotsOfCaffeine yes OsStr is a osstring and therefore must not be valid Unicode. But a str must be. So that's why there is another option.

But to_lowercase on str is 'fn to_lowercase(&self) -> String' and does not need to be unwrapped as it can not fail.

@fuckwit yeah nvm on to_lowercase
The actual code I wrote a couple of days ago is this

let file_out_ext = output_file.extension();
if file_out_ext != None {
let ext_str = file_out_ext.unwrap().to_str().unwrap().to_lowercase();
// ...
}

And I just think it's a bit ugly. And you can't use the ? operator to tidy it up so it mostly just sits there.
In retrospect I could have used unwrap_or_default to make it a bit less obstructed

@LotsOfCaffeine

In Rust we would use match expressions and 'if let' to handle these cases.

Just using match and without any more error handling that would look something like this:

https://play.rust-lang.org//...

@LotsOfCaffeine

in the _ => ... arms you would usually throw your own error which then can be captured somewhere and dealt with properly

Both languages are nonsense, so yes.

@fuckwit using pattern matching for a null check seems a bit odd to me, but hey that looks a lot cleaner