Why Go Can't Try

Post by assbuttbuttass » Mon, Mar 02, 2026, 8:51 PM UTC

andriy_koval wrote: post #29

sheept wrote: post #24

Earlier quoted context omitted.

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.

Post by yndoendo » Mon, Mar 02, 2026, 9:32 PM UTC

xigoi wrote: post #54

sethops1 wrote: post #46

Earlier quoted context omitted.

When you see .unwrap in Rust code, you know it smells bad. When you see x, _ := in Go code, you know it smells bad. > But if you don't know Go, it's just an underscore. And if you don't know rust, .unwrap is just a getter method.

> When you see x, _ := in Go code, you know it smells bad. What if it’s a function that returns the coordinates of a vector and you don’t care about the y coordinate?

   x, _ := 

  func ParseStringToBase10i32AndIDoNotCare(s string) {
     i, _ := strconv.ParseInt(s, 10, 32)
     return i
  }

Post by tialaramex » Mon, Mar 02, 2026, 11:10 PM UTC

qezz wrote: post #60

tialaramex wrote: post #38

Earlier quoted context omitted.

How so? In Rust you also need an allocator to allocate anything. Zig's diagnostics idiom is just that, an idiom. It would be very weird to do this in Rust, but then it's a pretty weird choice in Zig, they've just decided to do it anyway.

What I meant by "you need an allocator" is "you need to explicitly pass the allocator of your choice to the function" [if you want to attach some data to the error]. In rust you can simply return anything as error, not only an enum variant.

Post by scuff3d » Tue, Mar 03, 2026, 12:12 AM UTC

BadBadJellyBean wrote: post #10

scuff3d wrote: post #8

"Here's the uncomfortable truth: a try keyword in Go without fixing the error type is just syntax sugar. You'd get slightly less typing but none of the real benefits - no exhaustiveness checking, no compiler-inferred error sets, no guarantee that you've actually handled every case." ... So what? From what I can tell that's all anyone has asked for in the context of something to just return nil/error up the call stack…

Exactly. I don't like that many people say "It's not perfect so it's useless.". I don't want to write or read the `if err != nil` statement over and over again. It is messy. It is tiresome. It could be solved by syntactic sugar.

Post by LovelyButterfly » Tue, Mar 03, 2026, 5:16 AM UTC

chis wrote: post #27

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…