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

Go: Support for Generic Methods

github.com

Post reply on HN
Print view View original

211–220 of 288 posts

Re: Go: Support for Generic Methods

#211

Post by a-french-anon »

xscott wrote: post #17
a-french-anon wrote: post #4

Earlier quoted context omitted.

Maybe, but personally I've become quite tired of programming languages "organically grown" as opposed to properly designed the first time. After a good decade of C then C++, I found ANSI CL (despite being a massive compromise and unfinished) much more coherent and complete than both.

Scheme is (or at least was) coherent. You don't need to look any further than set/setf/setq to see that Common Lisp is "organically grown" from the fertilizer of a committee. CL does its best to make every other lisp more attractive.

Common Lisp didn't grow into its warts, though, it was intentionally a "Common" Lisp. A compromise, like I wrote.

Re: Go: Support for Generic Methods

#212

Post by galkk »

stouset wrote: post #76
tczMUFlmoNk wrote: post #57

Earlier quoted context omitted.

> As for the detractors, from the first generics proposal this was called out as a "not now", not never. What? The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods". There is also some similar discussion of the original generics proposal, with language like "then it's much less clear why we need methods at all". (I'm omitting some context, but I don't feel that it changes…

No, you’re clearly wrong; golang was always going to add support for generic functions. Everyone also wanted and accepted the need for generics. It was always something they wanted to add to the language. Rob Pike never said that that kind of abstraction isn’t what golang is for. It was always just a matter of getting the design right. Go has always been a systems language. It was one when we thought it was going to…

I love your rant.

The writing is on the wall for next development.

“For the foreseeable future, the Go team will stop pursuing syntactic language changes for error handling. We will also close all open and incoming proposals that concern themselves primarily with the syntax of error handling, without further investigation.”

Re: Go: Support for Generic Methods

#213

Post by tapirl »

msaher66 wrote: post #200

Since they can't implement interfaces, Generic methods are just syntax sugar for generic functions. I'm surprised they actually accepted this proposal for sugar.

Yes, the sugar is just to make chain calls with parameter types possible. The sugar reflects the limitation of the basic of Go generics design. Now they would make the language even more complex for such a small need. In facts, there are more problems in Go generics need to be solved earlier than this: https://go101.org/generics/888-the-status-quo-of-go-custom-g...

Re: Go: Support for Generic Methods

#214

Post by shakow »

9rx wrote: post #124
stouset wrote: post #122

Earlier quoted context omitted.

Ah the good old “just be a perfect programmer and you won’t run into any issues” argument. Haven’t heard that one in awhile.

If only you had made it to the second paragraph. Hey, at least we can now understand why you have such a hard time with nil, so that's something.

Your second paragraph doesn't hold after one minute spent reading the CVEs list.

Re: Go: Support for Generic Methods

#215

Post by MrBuddyCasino »

binary132 wrote: post #34

Chasing a perceived gap between language features and user expectations has been and continues to be the greatest error in the leadership of Go.

They should have blocked generics forever and instead have a proper enum. Unpopular opinion, I know.

Re: Go: Support for Generic Methods

#216

Post by throwway262515 »

rustyzig wrote: post #172
AdieuToLogic wrote: post #170

Earlier quoted context omitted.

> Funnily enough, Go's generics were designed by the same guy who introduced monads to computer science. No contributor to Go is responsible for "introducing monads to computer science", as the Monad concept is a member of (or defined by if you prefer) Category Theory[0]. 0 - https://en.wikipedia.org/wiki/Category_theory

As you point out, monads come from category theory, not native to computer science. Thus there had to be someone to introduce approaches to applying monads in computer science. The paper usually credited with that is: https://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/b... Which the parent rightfully points out was written by the same person primarily responsible for the design of generics in Go: https://home…

On that note, calculus come from physics. AI should really hand back all those jacobians and hessians.

Re: Go: Support for Generic Methods

#217

Post by foldr »

tines wrote: post #64
CamouflagedKiwi wrote: post #32

Earlier quoted context omitted.

They didn't say they never wanted to do generics, but that they did want to take their time and do them right. Debatable how much they have been "right", although this gets them somewhat closer. And I think they have not been "wrong" in the ways they wanted to avoid (they referenced some issues with Java generics as prior art, although I forget the details).

From another commenter here: > The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods".

But they haven’t added generic methods, really. This change just lets you use method syntax in cases where you could have used a function. It’s a pretty conservative change that I think a lot of people here are misunderstanding. Actual generic methods wouldn’t really make sense (for the same reason that you have similar restrictions on dynamic trait implementations in Rust).

Re: Go: Support for Generic Methods

#218

Post by Merovius »

thayne wrote: post #209
Merovius wrote: post #177

Earlier quoted context omitted.

> but the reason against using runtime reflection is mostly that it's slow. More specifically, it is that it would introduce surprising performance cliffs – code becoming surprisingly slow due to seemingly unrelated changes. Though BTQH I think an even more important argument is that you would need to have effectively two generics implementations, one working at runtime and one working at compile time. That's a lot o…

> you would need to have effectively two generics implementations, one working at runtime and one working at compile time My understanding is that go already has a hybrid system works at compiletime and sometimes at runtime.

I'm not sure what you mean. Perhaps you are referring to the reflect package? In that case, yes, that exists. But it is limited in its power (for example, it doesn't allow to create types with methods – precisely because of the difficulties we are talking about) and a comparatively frequent source of bugs. If anything, it provides pretty strong evidence for the problems with this approach.

Re: Go: Support for Generic Methods

#219

Post by pjmlp »

uecker wrote: post #174
20k wrote: post #159

Earlier quoted context omitted.

The C++ way to do it currently would be: std::array , M> data; Which is contiguous int data[M][N]; also works fine and is contiguous in C++ Edit: For the stack at least. On the heap, you'd need to use a single std::vector and do the indices manually, or use mdspan

I does not work fine in C++ when N and M are not compile-time constants, which is basically always the case in any interesting numerical algorithm. Also not in Rust. It works fine in C though, or FORTRAN, or Ada, or ALGOL 60, ...

Which is why std::mdspan exists, and std::linalg.

NVidia has pivoted to design CUDA hardware with focus on C++ back in , and seems to be doing quite well for them.

CppCon 2017: "Designing (New) C++ Hardware”

https://www.youtube.com/watch?v=86seb-iZCnI

They were also the ones sponsoring the ISO work on mdspan, while HPC research labs are pushing for linalg on top.

I would rather be using Ada today, but that isn't how the world moves.

Re: Go: Support for Generic Methods

#220

Post by pjmlp »

someone_19 wrote: post #210
MrBuddyCasino wrote: post #198

Earlier quoted context omitted.

Theres a whole universe between proper enums and go becoming Ada. Same with null safety.

Ada is the lost knowledge of a past, more advanced civilization.

Thankfully not everyone has forgotten.

https://www.adacore.com/case-studies/nvidia-adoption-of-spar...

Post reply on HN