This tries to sound profound but it really just misunderstands basic sum types. In Rust/Haskell/etc you're free to return multiple values if that's even potentially useful. If you have a function that can completely fail, partially fail (in this example, opening a file but then something else fails), or entirely succeed, you can encode that in the type system. In Go you cannot define this in the type system, you just have comments explaining how it works and hoping both that you implement it correctly and callers of your code read and understand them. If your code does return both files and errors in some cases, chances are callers are going to handle it incorrectly, especially if, say, the caller is responsible for closing files/responses/streams/etc.

In Rust/Haskell I can write a type with three values like Success(file), PartialSuccess(file, error), or Failure(error). Callers must then handle all of these. In Go I always have four cases for a simple function including those three and the final case of neither file nor error. Most Go callers will not handle the case where err != nil and file != nil and often the case where err == nil and file == nil will cause a panic and crash the program.

There was a tradeoff for this, but in this case the tradeoff was entirely in making the Go compiler simpler at the cost of making the Go language weaker and Go code more error-prone.

> But doesn't know how the return values will be used by the caller. What is perhaps lost in this is where Go says that values should always be useful?

It doesn't matter how it will be used by the caller. If I'm writing a function that can fail, no magic in existence can create a success object out of nothing, especially one that "should always be useful". At that point you're stuck either returning a nil pointer or a zombie object (along with the error).

> Exactly the current way is what is said to be deficient, though.

It's deficient because it's modelling the wrong (in the common case) thing. I'm saying if you're in the uncommon case and that actually _is_ what you're trying to model, then you still can.

> A function of this type is naturally going to return a file every time because a file is always useful, even when there is failure.

What? No. It's not useful if there is no file, if the error is "wtf, that file doesn't exist".

> A function of this type is naturally going to return a file every time because a file is always useful, even when there is failure.

You might want to look at what Go does with zero-valued File. At best it ignores them and returns an error, at worst it panics.

There is no situation where a zero-valued file is useful.

But in Rust you can do the same, I do this all the time:

  let _ = fs::mkdir_all() // Error ignored, Rust will not complain because you explicitly assigned to _

Or if the function returns something I need but I don't care about the error:

  let Ok(file) = get_file() else {
    file_unavailable();
    return
  }

  upload_file(file);

Or this:

  let file = get_file().unwrap_or_default()

> Idiomatic Go says leave it to the caller. Like above, when only wants to know if there is "file or no file" without concern for why there is no file, then:

>

  file, _ := getFile() // The second return argument is an error.
  if file == nil {
    fileUnavailable()
  }

That very often doesn't work in Go. Most functions which return errors offer no guarantee whatsoever about the return value if there is an error. No one would consider it a breaking change to modify the return in case of error. And many functions return a struct, where Go offers no way to compare two arbitrary struct values for equality, or to check if an arbitrary struct value is that struct's "zero value".

So no, Go does not recommend (or even endorse) this pattern.

You mean file == nil.