Go subtleties

Post by furyofantares » Wed, Oct 22, 2025, 6:25 PM UTC

gethly wrote: post #130

furyofantares wrote: post #89

I balked a little when the article refers to format strings as "string interpolation" but there's multiple comments here running with it. Am I out of date and we just call that string interpolation these days? I also found this very confusing: > When updating a map inside of a loop there’s no guarantee that the update will be made during that iteration. The only guarantee is that by the time the loop finishes, the ma…

Mutating maps during iteration is a big red flag.

Post by eikenberry » Wed, Oct 22, 2025, 6:30 PM UTC

gethly wrote: post #127

jasonthorsness wrote: post #79

Great list! Reminds me to check out more of the new stuff in 1.25. The one thing I wish Go had more than anything is read-only slices (like C#). The one thing I wish more other languages had that Go has is structural typing (anything with Foo() method can be used as an interface { Foo() }.

Yeah, having mutability optional would be great. It would also allow a lot of data to pass through the stack instead of heap due to pointers, which Go is riddled with for absolutely no reason(imo). On the other hand, now that we have iterators in Go, you can create a wrapper for []byte that only allows reading, yet is iterable. But then we're abstracting away, which is a no-go in Go and also creates problems later on…

Post by DanielHB » Wed, Oct 22, 2025, 6:35 PM UTC

ttz wrote: post #122

DanielHB wrote: post #48

Earlier quoted context omitted.

I like to say this: "Only my code is allowed to be clever" But, on a serious note, I agree with you. Go lacks a lot of power, especially in its type system, that causes a ton of problems (and downtime) that in other languages is trivial to prevent statically.

out of curiosity (not meant snidely), do you have an example of a case where the weaker type system resulted in serious problems?

Post by kbolino » Wed, Oct 22, 2025, 6:52 PM UTC

aatd86 wrote: post #138

kbolino wrote: post #111

Earlier quoted context omitted.

Size classes would save some space and speed up like-to-like comparisons, but wouldn't really do much for unlike comparisons (especially vs. float or complex). Looking only at type pointers fails to account for custom types (e.g., type Foo int); remember that an untyped integer constant can be compared with these. If you want the same semantics at runtime as you get at compile time, I don't see how you can get much s…

But the LHS can determine how it compares to the RHS when the RHS is determined to be an untyped constant? Or instead of saying RHS (my mistake), let's say the typed side since comparisons are symmetric. A bit like having a special method attached to the type strictly for comparisons? That would be much less expensive than such a type switch if I am not mistaken. Would handle custom types as well. If promotable from…

  type intType interface { ~int | ~int8 | ~int16 | ~int32 | ~int64 }
  func equals[I intType](x I, y any) bool {
    switch val := y.(type) {
    case I: return x == val
    case untypedInt: return val.i.IsInt64() && val.i.Int64() == int64(x)
    default: return false
    }
  }

Post by ignoramous » Wed, Oct 22, 2025, 7:18 PM UTC

lelandbatey wrote: post #97

callc wrote: post #87

I had a “wtf” moment when using Go around panic() and recover() I was so surprised by the design choice to need to put recover in in deferred function calls. It’s crazy to smush together the error handling and normal execution code.

It's cause it's not normal error handling to use recover(). In smaller codebases, panic probably should not be present. For larger codebases, recover should be in place only in very very sparse locations (e.g. at the top level http handler middleware to catch panics caused by unreliable code). But in general, returning errors is supposed to be how all errors are signaled. I've always loved the semantic distinction be…