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

251–260 of 288 posts

Re: Go: Support for Generic Methods

#251

Post by thayne »

Merovius wrote: post #218
thayne wrote: post #209

Earlier quoted context omitted.

> 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.

https://go.dev/doc/faq#generics_implementation

My point is for interface generics it could just always use a single instantiation. Similar to what java does.

Or alternatively, go could go the other direction and add a new type of interface that is only for use in generic constraints, and then generic methods could be part of that interface, but not normal interfaces, so that the generic methods could be called from other generic functions. That would be similar to rust and c++.

Re: Go: Support for Generic Methods

#252

Post by uecker »

pjmlp wrote: post #219
uecker wrote: post #174

Earlier quoted context omitted.

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…

I see that they spend time making their hardware run general software, but I can't see anything specific in GPU hardware to std::mdspan.

I respect Ada but I would not want to use it. But I have a choice between C++ with hmdspan and C99's arrays, I choose C99 any time.

Re: Go: Support for Generic Methods

#253

Post by tines »

jimbokun wrote: post #167
tines wrote: post #64

Earlier quoted context omitted.

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

> “What do you think? There was a man who had two sons. He went to the first and said, ‘Son, go and work today in the vineyard.’ “ ‘I will not,’ he answered, but later he changed his mind and went. “Then the father went to the other son and said the same thing. He answered, ‘I will, sir,’ but he did not go. “Which of the two did what his father wanted?” “The first,” they answered. Jesus said to them, “Truly I tell yo…

Whether they made a good decision or not, or changed their mind or not, is beside the point (I think they did, and they did!). I was merely replying to the claim that

> They didn't say they never wanted to do generics, but that they did want to take their time and do them right.

Re: Go: Support for Generic Methods

#254

Post by tines »

piekvorst wrote: post #193
tines wrote: post #102

Earlier quoted context omitted.

I'm not mad, I'm a proponent of stronger type systems. I'm just correcting the record about > They didn't say they never wanted to do generics, but that they did want to take their time and do them right.

What’s the correction? The two claims are not in conflict. Saying “we don’t expect to ever add X” is not equivalent to “we never wanted to add X.” It simply means that they didn’t think it would happen, which can coexist with an underlying willingness to consider it if a suitable approach appeared.

You added the word "want", the OP said "need". "We don't ever expect to add X" implies "we don't think we need X."

Re: Go: Support for Generic Methods

#255

Post by OneWingedShark »

uecker wrote: post #252
pjmlp wrote: post #219

Earlier quoted context omitted.

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…

I see that they spend time making their hardware run general software, but I can't see anything specific in GPU hardware to std::mdspan. I respect Ada but I would not want to use it. But I have a choice between C++ with hmdspan and C99's arrays, I choose C99 any time.

Why is that? I find Ada much nicer than the C-languages when it comes to arrays: A'Range, A'Length, A'First, and A'Last are super-useful, as is the unconstrained array.

You can even use unconstrained arrays to provide the same functionality that Optional does in functional-programming, provided the element-type can be an element of an array:

    -- Here we define an index-type with one value.
    Subtype Boolean_Index is Boolean range True..True;
    -- And here we define an array indexed by it, but can also have length 0.
    Type Optional(Boolean_Index range ) of Element;
And there you have the mechanism for Optional; just use "For Object of Optional_Array Loop" to enclose your operations and bam, it works perfectly.

Re: Go: Support for Generic Methods

#256

Post by HALtheWise »

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.

Sorta, but it's important for the calling convention that the compiler is consistent on what is done at compiletime vs runtime. Because methods are "normal functions" for the calling convention (and can be assigned to function-typed variables), there would be a lot of gymnastics required for the compiler to make runtime-generated variants of methods work.

Re: Go: Support for Generic Methods

#257

Post by pjmlp »

uecker wrote: post #252
pjmlp wrote: post #219

Earlier quoted context omitted.

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…

I see that they spend time making their hardware run general software, but I can't see anything specific in GPU hardware to std::mdspan. I respect Ada but I would not want to use it. But I have a choice between C++ with hmdspan and C99's arrays, I choose C99 any time.

I guess you aren't their target customer anyway, NVidia isn't that found of pure C code, with first class tooling for C, C++, Fortran, Python JIT, Ada and most recently Rust.

The std:mdspan proposal came from NVidia employees, alongside AMD and HPC research labs.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p00...

Yeah, I remember discussions on comp.lang.c calling programming with Ada, or even Modula-2, programming with straightjacket.

Meanwhile governments and national security bodies got another point of view.

You mean the C99 arrays Google paid the work to clean from the Linux kernel?

Re: Go: Support for Generic Methods

#258

Post by pjmlp »

9rx wrote: post #250
pjmlp wrote: post #190

Earlier quoted context omitted.

Yes, the same guy that supported the effort to add generics to Java, a decade beforee Go came to be, talk about not getting language design history. Stop excusing them, they were the first to acknolowdge being wrong in first place, "They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. W…

> Stop excusing them What is there to excuse? Your quote confirms that they simply don't know what they're doing as was already established. Not that anyone should expect them to. They're just regular average humans, same as every other random Joe you encounter while walking down the street, who all equally have their own failings and shortcomings. Why HN is constantly trying to put these particular people on a pedes…

They certainly knew what they were doing.

The first step to acknowledge not being great language designers is to actually be humble to learn from the work of others.

Not assert to all "we know better", and then repeatly having to backpedals on such assertions.

Re: Go: Support for Generic Methods

#259

Post by uecker »

pjmlp wrote: post #257
uecker wrote: post #252

Earlier quoted context omitted.

I see that they spend time making their hardware run general software, but I can't see anything specific in GPU hardware to std::mdspan. I respect Ada but I would not want to use it. But I have a choice between C++ with hmdspan and C99's arrays, I choose C99 any time.

I guess you aren't their target customer anyway, NVidia isn't that found of pure C code, with first class tooling for C, C++, Fortran, Python JIT, Ada and most recently Rust. The std:mdspan proposal came from NVidia employees, alongside AMD and HPC research labs. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p00... Yeah, I remember discussions on comp.lang.c calling programming with Ada, or even Modula-2,…

The thing is that I rewrite high performance numerical code on GPUs and the CUDA part is what sucks most. And the moment one uses templates, the compilation times make it insufferable. I really do not understand why people put up with this garbage. I am really looking forward to the day where I can remove CUDA from my projects and replace it with compiler-supported offloading is really

The kernel removed VLAs, I am more talking about vm types. But even for VLA - while I had a small role in that undertaking myself - I think it was a stupid mistake from a security point of view to remove VLAs from the kernel. Google pays for a lot of nonsense...

Re: Go: Support for Generic Methods

#260

Post by MrBuddyCasino »

ethin wrote: post #248
MrBuddyCasino wrote: post #206

Earlier quoted context omitted.

> it would make many things in the language easier to express Like what?

Like IPv6 addresses, UUIDs, the list goes on. Does it mean anything that Go themselves had to invent a custom uint128 type in the standard library because they didn't want to add it to the language? There's a very long list of instances of them stonewalling it here: https://github.com/golang/go/issues/9455

I agree with their reasoning, you don’t typically do math with a UUID, 128 bit cryptographic hashes are insecure and outdated anyway, and IPv6 is kinda valid but rare and still doable with slices.
Post reply on HN