Why Go Can't Try • Hacker News Board

Re: Why Go Can't Try

#21

Post by antonvs » Mon, Mar 02, 2026, 6:15 PM UTC

cryptos wrote: post #2

My takeaway is that Go almost always prefers simplicity and not so much good software engineering. `nil` without compiler checks is another example, or designing a new language without generics. However the overall simplicity has its own value.

I think of it as a bit like Python with stronger types.

I'm not convinced that you couldn't have good software engineering support and simplicity in the same language. But for a variety of mostly non-technical reasons, no mainstream language provides that combination, forcing developers to make the tradeoff that they perceive as suiting them best.

Re: Why Go Can't Try

#22

Post by andriy_koval » Mon, Mar 02, 2026, 6:21 PM UTC

sheept wrote: post #19

cryptos wrote: post #2

My takeaway is that Go almost always prefers simplicity and not so much good software engineering. `nil` without compiler checks is another example, or designing a new language without generics. However the overall simplicity has its own value.

I agree, its strength (beyond goroutines) is that anyone who knows one of the popular languages (Python, Java, etc) can easily translate their idioms and data structures to Go, and the code would remain easy to read even without much Go experience. That's probably one reason why the TypeScript compiler team chose Go. But this makes the language feel like Python, in some ways. Besides nil, the lack of expressivity in…

> he popular languages (Python, Java, etc) can easily translate their idioms and data structures to Go, and the code would remain easy to read even without much Go experience

disagree, they made many decisions which are different from mainstream: OOP, syntax as examples.

Re: Why Go Can't Try

#23

Post by qezz » Mon, Mar 02, 2026, 6:26 PM UTC

In Zig you need an allocator to allocate anything, so whenever you need to add some extra information to an error, you pass a diagnostics object as an output argument to a potentially failing function. In this case it becomes a bit harder to compare it to Go's errors, each with pros and cons. I think comparing Go errors to Rust errors would be more fair.

There are some articles about the diagnostic pattern in Zig, e.g. [1], [2]

[1] https://github.com/ziglang/zig/issues/2647#issuecomment-5898...

[2] https://mikemikeb.com/blog/zig_error_payloads/

Re: Why Go Can't Try

#24

Post by sheept » Mon, Mar 02, 2026, 6:30 PM UTC

andriy_koval wrote: post #22

sheept wrote: post #19

Earlier quoted context omitted.

I agree, its strength (beyond goroutines) is that anyone who knows one of the popular languages (Python, Java, etc) can easily translate their idioms and data structures to Go, and the code would remain easy to read even without much Go experience. That's probably one reason why the TypeScript compiler team chose Go. But this makes the language feel like Python, in some ways. Besides nil, the lack of expressivity in…

> he popular languages (Python, Java, etc) can easily translate their idioms and data structures to Go, and the code would remain easy to read even without much Go experience disagree, they made many decisions which are different from mainstream: OOP, syntax as examples.

Sure, the syntax is unique, but it's fairly easy to get over that. I guess I'm comparing to Rust, where not only is syntax different, but data structures like a tree with parent references aren't as straightforward (nor idiomatic), and there's a lot more explicit methods that requires knowing which are important and which are just noise (e.g. unwrap, as_ref).

I would argue that after a short tutorial on basic syntax, it's easier for a Python/JavaScript programmer to understand Go code than Rust.

Re: Why Go Can't Try

#25

Post by a-poor » Mon, Mar 02, 2026, 6:32 PM UTC

What is broken about the go error type? If anything the fact that it is a simple interface makes the `try` syntax sugar more doable – right?

Let's say you have this:

``` part, err := doSomething() if err != nil { return nil, err }

data, err := somethingElse(part) if err != nil { return nil, err }

return data, nil ```

Then as long as your function followed the contract 0+ returns and then 1 `error` return, that could absolutely be turned into just the 0+ returns and auto-return error.

The fact that the `Error` interface is easy to match and extend, plus the common pattern of adding an error as the last return makes this possible.

What am I missing here?

Re: Why Go Can't Try

#26

Post by saynay » Mon, Mar 02, 2026, 6:37 PM UTC

sheept wrote: post #19

cryptos wrote: post #2

My takeaway is that Go almost always prefers simplicity and not so much good software engineering. `nil` without compiler checks is another example, or designing a new language without generics. However the overall simplicity has its own value.

I agree, its strength (beyond goroutines) is that anyone who knows one of the popular languages (Python, Java, etc) can easily translate their idioms and data structures to Go, and the code would remain easy to read even without much Go experience. That's probably one reason why the TypeScript compiler team chose Go. But this makes the language feel like Python, in some ways. Besides nil, the lack of expressivity in…

> But this makes the language feel like Python

From what I remember of a presentation they had on how and why the made Go, this is no coincidence. They had a lot of Python glue code at Google, but had issues running it in production due to mismatched library dependencies, typing bugs, etc. So they made Go to be easy to adopt their Python code to (and especially get the people writing that code to switch), while addressing the specific production issues they faced.

Re: Why Go Can't Try

#27

Post by chis » Mon, Mar 02, 2026, 6:37 PM UTC

These AI written articles carry all the features and appearance of a well reasoned, logical article. But if you actually pause to think through what they're saying the conclusions make no sense.

In this case no, it's not the case that go can't add a "try" keyword because its errors are unstructured and contain arbitrary strings. That's how Python works already. Go hasn't added try because they want to force errors to be handled explicitly and locally.

Re: Why Go Can't Try

#28

Post by pie_flavor » Mon, Mar 02, 2026, 6:38 PM UTC

Everyone compares Go to Rust. This AI-generated slop mentions Rust at the top, then launches into an explanation of how Go is not like Zig, where Rust is also not like Zig, but instead is extremely like Go. This answers no questions at all about the argument people actually participate in.

Re: Why Go Can't Try

#29

Post by andriy_koval » Mon, Mar 02, 2026, 6:38 PM UTC

sheept wrote: post #24

andriy_koval wrote: post #22

Earlier quoted context omitted.

> he popular languages (Python, Java, etc) can easily translate their idioms and data structures to Go, and the code would remain easy to read even without much Go experience disagree, they made many decisions which are different from mainstream: OOP, syntax as examples.

Sure, the syntax is unique, but it's fairly easy to get over that. I guess I'm comparing to Rust, where not only is syntax different, but data structures like a tree with parent references aren't as straightforward (nor idiomatic), and there's a lot more explicit methods that requires knowing which are important and which are just noise (e.g. unwrap, as_ref). I would argue that after a short tutorial on basic syntax,…

to me Rust syntax is less alienating, they adapted ML syntax which is probably second most popular(scala, typescript, kotlin) after C style syntax, while Go from whatever reasons got something totally new.

Re: Why Go Can't Try

#30

Post by n_u » Mon, Mar 02, 2026, 6:39 PM UTC

seethishat wrote: post #14

The programmer is explicitly throwing away the error returned by ReadFile (using the underscore) in the criticism of Go. data, _ := os.ReadFile(path) Saying that is not explicit is just wrong.

I think the argument is that the compiler does not enforce that the error must be checked. It's just a convention. Because you know Go, you know it's convention for the second return value to be an error. But if you don't know Go, it's just an underscore.

In a language like Rust, if the return type is `Result`, the caller cannot access the `MyDataType` without using some code that acknowledges there might be an error (match, if let, unwrap etc.). It literally won't compile.