I thought so too, after years with Scala and Rust. Now I think (X, error) is fine, indeed I think it is great for it's simplicity. I might want to have a safe assignment

   // x() (X,error)
   x != x() 
   // x is X
   // return on error

But the urge is not very high.

The problem is indeed composition. How do I chain 3 calls that short-circuit on the first error? In Go that's verbose in the extreme. With exceptions it's easy to miss an error. Sum type errors have neither problem.

If you want to chain 3 calls and short circuit on the first error, don't use Go. I like explicit code without magic that I can't see.

   for a <- a()
       b <- b() {
       ...
   }

I don't know what is happening there. Is it summing up errors? Is if short circuiting? Does it have error handling? Is it async? Is it a monad stack with transformers? That code could mean anything. Good luck coming back to that code after six months. I think the Sum type solution focuses on the happy path, the Go solution assumes you need to focus on the things that go wrong.

Additionally you have that nasty dependency of the Result type of a() to b() to make it work. And I've spent hours creating the right Transformer stack to compose more than two monad types like Result, Future and IO.

The problem here is that if your style is not to return the error, but wrap it, you need a way to wrap it.

You could use special syntax

   x != x() ~ "x failed"

that would wrap the error and return it,

   x, err := x() 
   if err != nil {
      return fmt.Errorf("x failed: %w", err)
   }

is more verbose but less so compared to the "just return error" case.

If you want to get rid of that, you need to have some auto conversion magic. This the way Rust does it, but it adds magic, you can't see the error handling, Rust needs (slow compiling) macros for this etc.

I would be all over Go with a better type system or exceptions.

If Go ever adds exceptions[1] as an error handling mechanism, I'm out. Value errors are far superior to exceptions, even in their current state in Go.

[1]: assuming panics are not an error handling mechanism but a recovery mechanism

Checked Exceptions are nothing but errors as values with some syntactic sugar for the most common use case (bubbling up the error).

Gos version of value errors is just micrometers ahead of C style error codes. In both cases you get told "there could be an error", the error is a value of one single type (error/int), and you have to manually find out which different errors this value could represent.

If you want to know what you're missing, check out Rusts error handling.

I love Rust error handling and wish it would have been the default in Go (too late to shoehorn it), but it has nothing to do with exceptions.

Panics can be values and errors don't have to be values in go?

I think you are missing up concepts here

I’m not talking about the underlying model, I’m talking about the control flow. What I mean is errors are explicit values belonging to the signature of the functions.

Madness.

C#, OCaml, Java, Scala, Kotlin all fulfill these requirements, while targeting the same niche.

Go has insanely good tooling and very fast single binary compiling.

While all these languages (afaik) can reach similar levels of functionality (GraalVM e.g.), it's more work. As much as I hate the language Go, I can't deny how braindead simple it is to just make a tool with it. I don't need to choose a build tool, or a runtime version, there's a library for everything and most developers with more than a room temp IQ can immediately start working on it.

The only other language that currently comes close is Rust. If only they had stuck to using a GC, I'd be in heaven.

Is this that different from languages like Dotnet? I think one line in your config can make it Aot compiled.

Yes there are indeed lots of languages in existence.