131–140 of 219 posts
Could someone take the example, reduce it to a non-generic version for two types I DO understand, then show that with the new feature I can collapse them into the Box/Map example in the doc?
I have 10+ years of Go experience and I can't make heads or tails of "(b Box[T]) Map[U any](f func(T) U) Box[U]"
Earlier quoted context omitted.
Swift generics tend to idiomatically use longer names, like Element or View or Content.
I’ve always done that in my typescript code bases too, and I’ve never regretted it
Earlier quoted context omitted.
Lisp manages it. Even if you do use type annotations.
No. This cognitive load is conceptual. You can't avoid it by using slightly different syntax.
In Haskell as well, you can let the compiler infer a lot of things but that doesn’t appear to be the case with this example.
I’d want the compiler to infer things, but that - I think - is at odds with Go desiring a fast compiler, which I also understand.
Earlier quoted context omitted.
I understand that this is true for a lot of application code. It's not true for library authors though, and every language needs libraries.
I’ve written a lot of libraries too. The problem is generics only solve a very small part of the equation: compile time checks for composite types. But to use composite types in anything non-trivial in Go, you then need reflection. Which is slow. And if you then need reflection, you’re already passing interface types anyway plus you’re back to having to handle type-handling errors in the runtime. So if you’re writing…
"The best way to teach something new is to compare it to something the audience already understands." Could someone take the example, reduce it to a non-generic version for two types I DO understand, then show that with the new feature I can collapse them into the Box/Map example in the doc? I have 10+ years of Go experience and I can't make heads or tails of "(b Box[T]) Map[U any](f func(T) U) Box[U]"
Earlier quoted context omitted.
Indeed, we're now one step away from monads. I know https://go.dev/doc/effective_go hasn't been updated for while, but it also seems to have been forgotten. "Go is an open-source programming language that focuses on simplicity ..." the page begins.
You've already been able to badly implement monads in Go for 10+ years. Why wouldn't you be able to implement them in a way that the compiler can enforce correctness of? If you don't want it don't use it. It's that simple.
This release also fixes runtime.findnull() to be compatible with MTE on Android ([1] and [2]). This was the only thing preventing MTE from being enabled for apps that use gomobile on MTE-compatible Android OS's like GrapheneOS. [1] https://go-review.googlesource.com/c/go/+/749062 [2] https://go-review.googlesource.com/c/go/+/751020
This: "(b Box[T]) Map[U any](f func(T) U) Box[U]" is the type of cognitive weight I was happy that Go avoided.
(b IntBox) MapToStringBox(f func(int) string) StringBox
(b IntBox) MapToBoolBox(f func(int) bool) BoolBox
(b StringBox) MapToIntBox(f func(string) int) IntBox
The T, U, and f names are the cognitive load here, because they are meaningless variables. For a specific solution, those would have meaningful names that would make it easier to understand.