With agentic coding you can just use Rust. AI agents are really good at Rust and the good error message the compiler and or borrow checker gives makes it easy for the AI agent to adjust its code and fix it.

For non agentic coding Go has terrible error handling. It does not have exceptions or monadic error handling. Some call that a feature but many avoid Go or that specific reason. This will not change because that debate has been settled so if you can live with if err != nil after each function call (almost) then you are fine.

Things that is beautiful with Go are: * Its simplicity * Superb cross compilation support and excellent support for many different OS/arch combos. Not sure if anything comes close to this level of easy way of compiling to Many targets and target support.

I personally avoid Go because if the if err != nil But I love the fact they have no exceptions. Rust handles this very well but it's way more complicated in general. I feel like we miss a middle ground. Maybe when Gleam becomes really popular, it could be the one?

> Not sure if anything comes close to this level of easy way of compiling to Many targets and target support.

Cross-compilation has been a standard feature of every compiled language toolchain for the past decade at least.

Also a big plus for Go: no async.

After a few years of Kotlin, I recently ran into what I consider to be some shortcomings here as well, with respect to returning errors. As we know, Kotlin does not have checked exceptions. Ok, but ...

The KEEP for Result<T> goes into details, but basically there are a few ways of handling return values + errors:

1) throw exception if something goes wrong

2) return null if something goes wrong (stdlib XXXorNull)

3) Use Result<T> in some cases, its error type is not paramerized and catches CancellationException

4) Use Arrow if Result<T> doesn't meet your needs

5) Return Sealed Classes / Interfaces with all the possibilities.

Right now, I am going the Sealed Class interface route, but its such a verbose pain in the ass, so I only use it at certain levels of abstraction (like from a Repository, or library API, etc).

The code I needed to write was calling into okio, and it was not straightforward to figure out what kinds of exceptions would be thrown by the JVM layer underneath (docs just say IOException, but sublasses can be thrown).

Its sad to see they still haven't figured this out. Rich Errors was mentioned a year ago but its not even in preview yet. Its also not clear how it will work with Java interop.

Exactly, I don’t know why we are even arguing over this anymore. People basically don’t write code today so why not use the best languages?

Go is handicapped in significant ways which were specifically designed so that it was easier for humans to write. People pushing for Go code in this age either don’t understand the future or the past