Go and Rust have a similar way of handling errors: (T,error) and Result
They are similar looking but Rust forces you to handle this Result type by considering error or it wont compile at all. (unless you use unwrap() which is basically handling it somehow).
In Go, its not forced to handle the errors. You can easily skip errors and have them pop up in production without you ever knowing
For example in here I ve skipped error handling and the program still compiles.
data,_:=os.ReadFile("/tmp/data")// use data anyway
But in runtime, this can panic the program without the programmer ever knowing.
In Rust, this is a different story
letdata=fs::read_to_string('/tmp/data').expect("Something went wrong reading the file");// data is present always
In here without expect or proper error handling, program wont even compile.
So in my opinion,
Having to handle error where it occures is a Plus point in Go, its very easy to spot an error
Not having a way to safeguard against skipped error handling is a fatal mistake(i know IDEs can help, but still that can lead to problems in Prod)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
They are similar looking but Rust forces you to handle this
Resulttype by considering error or it wont compile at all. (unless you useunwrap()which is basically handling it somehow).In Go, its not forced to handle the errors. You can easily skip errors and have them pop up in production without you ever knowing
For example in here I ve skipped error handling and the program still compiles.
But in runtime, this can panic the program without the programmer ever knowing.
In Rust, this is a different story
In here without expect or proper error handling, program wont even compile.
So in my opinion,