News for hackers. Stuff that matters.
Re:I Want Off Mr. Golang's Wild Ride by pcwalton on Friday February 28, 2020 @01:51PM (#22445244)
Go doesn't ensure that you handle errors, if the function doesn't have a return value other than the error. The compiler will happily let you silently drop the result of os.Mkdir() on the floor.
Re:I Want Off Mr. Golang's Wild Ride by munk-a on Friday February 28, 2020 @02:37PM (#22445634)
I also generally think that writing boilerplate code is unproductive - golang's error system relies on people pedantically writing boiler plate code constantly among their logic - the result is to obscure the actual logical drive of the code.
Re:I Want Off Mr. Golang's Wild Ride by Thaxll on Friday February 28, 2020 @02:13PM (#22445422)
I'm no Rust expert, but Rust doesn't enforce that either.

There is no language that enforce error checking afaik.

Re:I Want Off Mr. Golang's Wild Ride by pcwalton on Friday February 28, 2020 @03:36PM (#22446093)
You get a compiler warning.
Re:I Want Off Mr. Golang's Wild Ride by typon on Friday February 28, 2020 @02:39PM (#22445655)
You have to either propagate the error up the stack or face a panic. Rust does force you to deal with the error.
Re:I Want Off Mr. Golang's Wild Ride by Thaxll on Friday February 28, 2020 @02:58PM (#22445794)
I didn't make myself clear enough, if something returns an error in Rust and you don't check it will it compile or not?
Re:I Want Off Mr. Golang's Wild Ride by typon on Friday February 28, 2020 @03:00PM (#22445815)
It will not compile. (As I said earlier, you can always fallback to a panic aka "I don't wanna deal with the error so let my program crash", but an error will not silently propagate through the stack)
Re:I Want Off Mr. Golang's Wild Ride by cjhopman on Friday February 28, 2020 @07:42PM (#22447769)
That's is completely false, stop spreading misinformation.

This code will compile (see https://play.rust-lang.org/?version=stable&mode=debug&editio...):

  pub fn foo() -> Result<(), i64> {
      Err(1)
  }
  
  pub fn bar() -> Result<(), ()> {
      foo();
      Ok(())
  }

It will provide a warning, but there's a ton of stuff in c++ that would throw a warning and you wouldn't say that it "will not compile".

A trivial change that still doesn't handle the error would get rid of the warning.

  pub fn foo() -> Result<(), i64> {
      Err(1)
  }
  
  pub fn bar() -> Result<(), ()> {
      println!("{:?}", foo());
      Ok(())
  }
Re:I Want Off Mr. Golang's Wild Ride by eddyb on Sunday March 01, 2020 @04:10AM (#22455954)
I wonder if people upthread meant the warning, or e.g. getting the `Foo` in `Result<Foo, BarError>`.

(EDIT: nevermind, just looked again and pcwalton was referring to the warning and specifically `Result<(), E>`; oh well)

Because the latter is impossible in Rust and probably more relevant to the usual cited issue with Go's pair approach (i.e. using the null/zeroed `Foo` without checking if there was an error).

I do agree though that the warning isn't to stop you from not handling the error at all, it's more of a hint that maybe you forgot something.

Printing a `Result` may be the legitimate way to handle it in that case, it's largely left to the user to decide what propagates and what doesn't.

Re:I Want Off Mr. Golang's Wild Ride by connerruhl on Friday February 28, 2020 @03:11PM (#22445894)
All languages which uses Result or Either types...?