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

211–219 of 219 posts

Re: Go 1.27 Interactive Tour

#211

Post by lowmagnet »

bradfitz wrote: post #7
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…

(I was on the Go team for ages) Seriously, that's all it was. Just Ian alone proposed and rejected a half dozen of his own different approaches to generics. Finally a language + implementation plan came together that people all liked. Nobody was ever opposed to generics that I saw.

The implementation is coming along nicely, and I'm already thinking of ways of using generic bound functions. I'm not bad that it's not like Java 1.4 despite having the lessons of Java 1.4, but being class-based is a very different way of working from go. Getting the unbound functions right before the bound ones was a struggle, but I do think the approach makes sense, in the long run.

I can't wait to see the Container stuff in the next iteration, too.

Re: Go 1.27 Interactive Tour

#212

Post by lowmagnet »

Hendrikto wrote: post #97
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.

The one thing I hated about Java's generics was type erasure. It worked for the JVM but it had such stupid limits, like not being able to switch on a type, like go. (interfaces are types, this is exploitable)

Re: Go 1.27 Interactive Tour

#213

Post by peterashford »

zerr wrote: post #118
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... :)

I don't think that comment was necessary. What do you gain by denigrating the Arts?

Re: Go 1.27 Interactive Tour

#214

Post by wannabe44 »

SubjectToChange wrote: post #193
wannabe44 wrote: post #157

Earlier quoted context omitted.

In terms of tooling, Go is one of the few languages which remembers that we are in STEM.

I’m not sure if you are complementing or denigrating golang’s tooling. Most “STEM software” packages are horrendous in terms of user/developer experience, to the point of hampering their utility. For instance, MPI really reminds HPC users that we are in “STEM”, but not for a good reason. Golang has good “implementation level” tooling, but that is still nothing when compared to tooling available to Java and C#. Even i…

Native compilation which is fast enough, green threads, AST and analysis framework, in-built testing and profiling, call graphs, rewrite tooling (go fix), go.work and modules which are far better than maven / gradle mess. There's a good amount of rigour applied to Go tooling that it "just works", even as horrendous the language is.

I agree java is good too, except spring boot manages to undo all the engineering that has gone to Java.

Re: Go 1.27 Interactive Tour

#215

Post by sh0gg0the »

drivebyhooting wrote: post #11

Can generics be used to improve error handling and eliminate the if err pattern?

> Can generics be used to improve error handling and eliminate the if err pattern?

With the newly added type parameters on methods you can now implement monads that do the function chaining and error handling like in Haskell. But it still wouldn't look as nice imho. This will probably become the next Golang anti-pattern.

Re: Go 1.27 Interactive Tour

#216

Post by bilinguliar »

melodyogonna wrote: post #165
bilinguliar wrote: post #104

Earlier quoted context omitted.

You can take my place, as the same changes make me want to leave.

To what? What would you use instead, things like this seem common place in languages made in the last decade.

Zig. I know it has generics. But I am now more aligned with where the language is moving. I admire how easy it is to do data-oriented design in Zig.

To put my money where my mouth is, I am donating $50 earned with Go to Zig every month.

Re: Go 1.27 Interactive Tour

#217

Post by torginus »

mrkaye97 wrote: post #189
torginus wrote: post #186

Earlier quoted context omitted.

And I'm not a python expert, so I might be wrong here, but: My understanding is that this decorator generates some class in the background that wraps the function into some remotely executable container thing, and handles the networking? Since python is a dynamic language, and go is not, this would be impossible without codegen, generics or not, but go does have codegen facilities. And the more immediate implication,…

Ah yep! I should’ve given a Go example. In Python we use decorators because it’s what’s in fashion, but in Go and TypeScript you just create a `NewTask()` e.g. where you pass a function (as well as other args), and it returns something with e.g. a `Result` method. And that result method, which is generic, is the thing that’s really nice to have typed. Agreed codegen works fine here too by the way, but it feels kind o…

I'm just saying that this Task[T] pattern is completely alien to Go. If you want to have one-off ansynchrony, then just write it synchronously and start your work on a goroutine.

If you wanna do batch processing, use channels.

For all intents and purposes, I would say 90% of IRL usage of generics is either this Task[T] pattern, collections or map() style array processing functions.

Go had a solution for all 3 of these, that didn't involve generics. I'm in a fortunate position that I get to pick the language I work in for a lot of my work (from a reasonable selection). So if I want to write Go, I'll rather do it idiomatically, otherwise I'd pick something else. Which should be the case for everyone, and language designers should take heed. The 'we want the Java/Python/Go/JS audience' sentiment has ruined many a language, as they've turned themselves into the same mediocre language that has all the features everyone else has.

Re: Go 1.27 Interactive Tour

#218

Post by JyB »

majewsky wrote: post #198
HumblyTossed wrote: post #112

Earlier quoted context omitted.

Right? Sigh. I really dislike this. There are 37000 programming languages, stop forcing every single one that gets popular to look like this.

It's almost as if the choices that make languages "look like this" are the ones that are generally associated with a more productive development workflow.

That's funny because that's factually untrue. Go's early popularity and professional adoption were largely driven by its perceived productivity boost linked in part to the small surface area of its spec, long before this subpar generic implementation was forced into it.

Re: Go 1.27 Interactive Tour

#219

Post by JyB »

torginus wrote: post #167
YesThatTom2 wrote: post #131

"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]"

This is the kind of shit why they probably didn't want generics in the language. This is like building a very crude general-ish DSL inside the language. Because the tools are intentionally limited (as to limit the scope of the feature), the result looks ugly. Also, like with C++ templates, people find exploits to do what the designers didn't want them to, with even more elaborate workarounds. I liked Go before generi…

You are unfortunately right. I am a bit relieved because it seem generics don't seem that over-used in the community. But still, the language lost a lot with this change that felt super-forced and unnecessary. Biggest downside of the language by far.
Post reply on HN