Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.27 Interactive Tour

victoriametrics.com

Post reply on HN
Print view View original

91–100 of 219 posts

Re: Go 1.27 Interactive Tour

#91

Post by teh64 »

baalimago wrote: post #42

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.

I think naming conventions might help:

    (b Box[InType]) Map[OutType any](transformFunction func(InType) OutType) Box[OutType]
Same in Python:

    def map[U](self, f: Callable[[T], U]) -> Box[U]
vs

    def map[OutType](self, transform_function: Callable[[InType], OutType]) -> Box[OutType]
and Java:

    public  Box map(Function transformFunction)
vs.

    public  Box map(Function f)

Re: Go 1.27 Interactive Tour

#92

Post by mxey »

spockz wrote: post #61
mappu wrote: post #47

Earlier quoted context omitted.

Go's http.Client will keepalive a TCP/TLS connection to save you handshake latency on second requests. But it can only do this if you completely finish reading the last request. Now in 1.27: > http.Response.Body drains itself on Close. For HTTP/1, closing the body now reads and discards any unread content (up to a conservative limit) so the connection can be reused. For most programs this is a transparent win [...] G…

Is “a conservative limit” a high limit or a low limit? If it is high such that many responses will still be drained it would keep reading those infinite streams for a long time. If it is low it might still not drain all normal sized messages. Anyway, this is why it pays off to read release notes closely and have a decent test suite.

The drain is asynchronous, so it won’t block. The limit is 256 KB and 50 ms.

Re: Go 1.27 Interactive Tour

#93

Post by rednafi »

I am all for using LLMs to generate value but a little more editorial review can't hurt.

> The quieter but bigger change: the classic encoding/json (v1) package is now backed by the v2 implementation under the hood.

This is fantastic content nevertheless.

Re: Go 1.27 Interactive Tour

#94

Post by fauigerzigerk »

hnlmorg wrote: post #89
fauigerzigerk wrote: post #69

Earlier quoted context omitted.

It's hard to avoid, because (naming aside) the cognitive load is caused by higher order functions, which are hard avoid without causing massive code duplication. I understand the desire to keep things concrete and avoid high level abstractions, but it's a decision not to automate stuff that can easily be automated. It runs counter to the basic instincts and purpose of our field/industry. That's why it never sticks.

Honestly, I’ve written some applications that, on paper, should be the perfect candidate for generics. And yet I can still count on one hand the number of times generics have saved me from massive code duplication. Most of the time generics might be useful, I’ve ended up needing reflection too anyway. And at that point, I’m really no better off for generics.

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.

Re: Go 1.27 Interactive Tour

#95

Post by teh64 »

phplovesong wrote: post #58
adrianmsmith wrote: post #50

Earlier quoted context omitted.

I never understood the convention of using single letter names for generic parameters. I guess this started in C++ and every language has copied that convention. I think that code would be a lot easier to read if the types were called IN and OUT or In and Out or TIn and TOut or something like that.

Im pretty sure it came from the MLs, where you usually have a/b/c instrad of the T,U etc combo. I dont find it confusing, as its pretty clear that it only an placeholder. In generics the name usually does not matter or is REALLY hard to name so that it makes sense. More specifically in Go where you have interfaces, concrete types and generics.

In ocaml (and I assume SML) it helps that the generic types have a `'` before them, so

    val map : ('a Box) -> ('a -> 'b) -> 'b Box

Re: Go 1.27 Interactive Tour

#97

Post by Hendrikto »

adrianmsmith wrote: post #84

One thing I think generics in Go is missing is the concept in Java. If you're taking a List[T] and all you want to do is to call list.size() then you don't care what type of list it is. In Java you can write a function which takes a List but in Go you have to write List[T] so then the question becomes what is T? You have to make the function (or type you're a method on) generic. If you make the type generic then ever…

Go Generics work differently than those in Java. They are specialized, meaning that they are not generic at runtime anymore. Instead, the compiler creates a different implementation for each type.

At runtime, there are only List[int], List[string], etc. List[T] is not a thing anymore.

Re: Go 1.27 Interactive Tour

#98

Post by wwalexander »

adrianmsmith wrote: post #50
baalimago wrote: post #42

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.

I never understood the convention of using single letter names for generic parameters. I guess this started in C++ and every language has copied that convention. I think that code would be a lot easier to read if the types were called IN and OUT or In and Out or TIn and TOut or something like that.

Swift generics tend to idiomatically use longer names, like Element or View or Content.

Re: Go 1.27 Interactive Tour

#100

Post by hnlmorg »

fauigerzigerk wrote: post #94
hnlmorg wrote: post #89

Earlier quoted context omitted.

Honestly, I’ve written some applications that, on paper, should be the perfect candidate for generics. And yet I can still count on one hand the number of times generics have saved me from massive code duplication. Most of the time generics might be useful, I’ve ended up needing reflection too anyway. And at that point, I’m really no better off for generics.

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 a library that’s expected to have any kind of performance, you’re back to code duplication and having a DoSomethingType() function signatures again.

Or you stick with reflection and take that performance hit PLUS the risk of compile time constraints being runtime errors; which is the a lose-lose scenario. And let’s also not forget that reflection can be just as verbose as code duplication, and harder to get right too.

Don’t get me wrong, I’m glad we have generics. But people on HN massively overstate the value of them in a AOT non-dynamic, strictly typed language like Go.

I guess you could argue that Go has other shortcomings that directly result in generics having limited value. But then you’re basically just arguing that you prefer coding in a different language paradigm, and at that point, you’re much better off using that other paradigm instead of complaining that Go isn’t JavaScript or Haskell.

Post reply on HN