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

111–120 of 219 posts

Re: Go 1.27 Interactive Tour

#111

Post by trueno »

nu2ycombinator wrote: post #9

Those Generics syntax in Golang seems so hard to read.

stared at it for a bit and im mostly certain i prefer it to java. at least writing other go = its not bad for me to break apart the signature line on a generic

java feels kinda unhinged the more that i look at it

    public static > T max(Collection c)
:x i wonder if anyones done something like this, would be super unhinged

    Map>, ? extends Map>>>>>> config;
go seems to get a lot of flack around these parts. i kinda lurv it though, just getting compiled binaries out of not much code and not needing a runtime to do shtuff. once i got a wrangle on goroutines i dunno i feel like its pretty solid for webapp backend which is mostly what i use it for

Re: Go 1.27 Interactive Tour

#113

Post by cpuguy83 »

asdf88990 wrote: post #108
Altern4tiveAcc wrote: post #96

>func (b Box[T]) Map[U any](f func(T) U) Box[U] {} That's completely unreadable.

Yes, thinking in higher order abstractions is hard for most people.

I'm pretty sure the issue is not "higher order abstractions". It is using multiple single letter references with no real grounding or relationship that the reader has to track.

For example, looping over a map with "k" and "v" vars is not that bad because the reader understands k=key and v=value, and that makes since for a map. If you do this same thing with different single letter vars, e.g. "a" and "b", it instantly becomes more difficult to read.

When writing a generic function and using these single character type references it can make sense, especially because the function/method doesn't care what those references are, however to someone trying to understand what's going on it can be extremely difficult simply because of the names.

Sure, if all you are going to do is call that method or function those type references go away and the call site may be relatively clean, but you still have to read the thing to understand what it is and how to use it.

Re: Go 1.27 Interactive Tour

#114

Post by HumblyTossed »

stingraycharles wrote: post #4

Am I the only one who’s absolutely shocked that Go finally is embracing generics? Does anyone have a bit of an inside view into what changed in the perspectives of the language maintainers? I’m not buying the “it took us 20 years to understand how to do it correctly” argument, as this is something you explicitly take into consideration when designing the language or not. And it was specifically not a part of language…

Surely it was pressure from devs to make Go look like every other language they begged to change then abandoned for the new hotness.

Re: Go 1.27 Interactive Tour

#115

Post by foldr »

whateveracct wrote: post #110
eager_learner wrote: post #37

Earlier quoted context omitted.

you mean like in Oberon?

ML's parametric polymorphism

Go lets you constrain type parameters with interfaces. To do anything analagous in SML you have to use functors, which is substantially less convenient. I think people who refer to ML's parametric polymorphism in this context must really be thinking of parametric polymorphism in OCaml or Haskell.

Re: Go 1.27 Interactive Tour

#116

Post by eterm »

Laurel1234 wrote: post #79
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.

In C# this is the convention.

It's a mix, because some stuff tends to just use `T`, but there's better descriptors elsewhere.

There's IList but Task

There's Action but also Dictionary and Map

This stuff kind of "makes sense" once you're used to it, because it's difficult to say what IList ought to have been called otherwise, IList is a mouthful, and Action simply suffers from the inability to specify an unknown number of generic parameters.

https://learn.microsoft.com/en-us/dotnet/api/system.collecti...

https://learn.microsoft.com/en-us/dotnet/api/system.action-2...

https://learn.microsoft.com/en-us/dotnet/api/system.collecti...

Re: Go 1.27 Interactive Tour

#117

Post by zer00eyz »

neilprosser wrote: post #55
my-next-account wrote: post #46

>The quieter but bigger change I really wish they didn't use such stupid LLM-isms.

I do wonder whether, as a group of people being regularly exposed to text written by LLMs, we'll gradually end up writing and talking like that in our normal language. At that point perhaps text written by LLM and human will be indistinguishable. I already find myself using terms like 'footgun' in jest more than I ever did before! "The creatures outside looked from pig to man, and from man to pig, and from pig to man…

> I do wonder whether, as a group of people being regularly exposed to text written by LLMs, we'll gradually end up writing and talking like that in our normal language.

We were doing this before LLM's. All sorts of trendy business speak would spread - the term "synergy" springs to mind as one people beat to death.

This is the concept of "memetics" (as in meme) in action. Hank Green recently talked about using AI and he went "off script" and threw "I appreciate the pushback" into his speech on the fly...

LLM's generating large volumes of content means that we're going to see all of its "isms" creep into other peoples speech much faster.

Re: Go 1.27 Interactive Tour

#118

Post by zerr »

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.

We often forget that our profession (computer programming) belongs to STEM. Some (like Go 1.0 :)) wish to think it is Arts & Humanities. The sooner we realize that yes, it is OK and actually expected to bear a cognitive weight of "(b Box[T]) Map[U any](f func(T) U) Box[U]" the sooner we get back to reality... :)
Post reply on HN