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

171–180 of 288 posts

Re: Go: Support for Generic Methods

#171

Post by AdieuToLogic »

dnnddidiej wrote: post #137
xena wrote: post #92

This will finally let me make the monad library I've been dreaming of for years. Be afraid.

Can we have Exception monads? Asking for friend.

> Can we have Exception monads? Asking for friend.

This is nonsensical. Monads define a strict set of behaviors formalized as "monad laws"[0].

Perhaps what you want is a container which adheres to monad laws capable of abstracting exceptions. Two exemplars of same are Haskell's Data.Either[1] and Scala's Either[2].

0 - https://wiki.haskell.org/Monad_laws

1 - https://hackage-content.haskell.org/package/base-4.22.0.0/do...

2 - https://www.scala-lang.org/api/3.8.3/scala/util/Either.html

Re: Go: Support for Generic Methods

#172

Post by rustyzig »

AdieuToLogic wrote: post #170
9rx wrote: post #163

Earlier quoted context omitted.

Funnily enough, Go's generics were designed by the same guy who introduced monads to computer science. Everything comes fill circle.

> 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://homepages.inf.ed.ac.uk/wadler/topics/go.html

Re: Go: Support for Generic Methods

#173

Post by pjmlp »

Go becoming a proper 21st century language, is like pulling teeth.

It is Apple's school of design, think different, ah, actually, there are reasons why the fence is in the middle of nowhere.

Then the design ends up half way there versus being done properly from the beginning.

Re: Go: Support for Generic Methods

#174

Post by uecker »

20k wrote: post #159
j_w wrote: post #112

Earlier quoted context omitted.

Isn't an array of arrays by definition the sequential implementation? Otherwise you would have an array of pointers to arrays. The usage (syntax) for them would be the same but the performance would not be. They also have different uses. You would expect an array of arrays to be an array of arrays which share the same length. For an array of pointers to an array you would expect dynamic length arrays contained within…

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

Re: Go: Support for Generic Methods

#175

Post by lacker »

AdieuToLogic wrote: post #171
dnnddidiej wrote: post #137

Earlier quoted context omitted.

Can we have Exception monads? Asking for friend.

> Can we have Exception monads? Asking for friend. This is nonsensical. Monads define a strict set of behaviors formalized as "monad laws"[0]. Perhaps what you want is a container which adheres to monad laws capable of abstracting exceptions. Two exemplars of same are Haskell's Data.Either[1] and Scala's Either[2]. 0 - https://wiki.haskell.org/Monad_laws 1 - https://hackage-content.haskell.org/package/base-4.22.0.0/d…

I don't think it's nonsensical, it's just another name for the same thing. E.g. in the Haskell wiki it says, "the Error monad, also called the Exception monad".

https://wiki.haskell.org/index.php?title=All_About_Monads

Re: Go: Support for Generic Methods

#177

Post by Merovius »

thayne wrote: post #148

> Go doesn't support such generic interface methods because we don't know how to implement (calls of) them, or at least we don't know how to implement them efficiently. I don't really understand this argument. I read the discussion linked to[1], and yeah, monomorphization approaches (whether at compile time, link time, or runtime with JIT) are obviously going to be difficult or impossible, but the reason against usin…

> 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 of complexity, with surprising failure modes if these two are not bug-compatible.

> But that runtime reflection is exactly how you would work around it today.

I think the overwhelming majority of people will "work around it" by just not trying to use generic methods.

Re: Go: Support for Generic Methods

#178

Post by Merovius »

tialaramex wrote: post #145
dwattttt wrote: post #134

Earlier quoted context omitted.

That is another way of looking at it, but given the topic, you're gonna have to expand or contextualise that. I Rust a fair bit, and only barely follow.

Actually in hindsight I think my perspective was less helpful because you can write a dyn compatible trait with a generic method it's just that you can't call the method via the trait objects, dynamic dispatch isn't possible for your function. So the original way to think about it was superior.

FWIW I found, so far, that bringing up dyn-compatibility to Rust people was very useful in helping them understand why Go's interfaces won't ever have generic methods.

The one additional piece of information you need is that in Go, all interfaces are supposed to be trait objects. The exception are union-elements, but that's really a restriction the Go team is trying to remove, not a model to base more features on.

Re: Go: Support for Generic Methods

#179

Post by Merovius »

EdwardDiego wrote: post #139
kbolino wrote: post #123

Earlier quoted context omitted.

Generic interfaces already exist. Generic interface methods, which would be relevant, are not planned. The reason is outlined early in the proposal: nobody knows how to implement them efficiently. Rust has the same problem, for what it's worth: dispatchable functions on dyn-compatible traits cannot be generic [1]. [1]: https://doc.rust-lang.org/reference/items/traits.html#r-item...

Is it because of the kinda built-in duck typing, for want of a better word? The thing where if you have a method (or methods) that matches the signature of method(s) of an interface, you implement the interface without explicitly declaring so?

More specifically, it is because of interface type assertions – the fact that if you have a value of some interface type (e.g. `any`), you can dynamically assert that it is another interface type (e.g. `io.Reader`). A good example of that is `io.Copy`: https://cs.opensource.google/go/go/+/refs/tags/go1.26.3:src/...

This aspect is what prevents you from statically knowing which interface-implementations you need to generate for a specific concrete type. There could always be new ones added at runtime.

Re: Go: Support for Generic Methods

#180

Post by MrBuddyCasino »

thayne wrote: post #148

> Go doesn't support such generic interface methods because we don't know how to implement (calls of) them, or at least we don't know how to implement them efficiently. I don't really understand this argument. I read the discussion linked to[1], and yeah, monomorphization approaches (whether at compile time, link time, or runtime with JIT) are obviously going to be difficult or impossible, but the reason against usin…

Like Java‘s generic erasure? Primitive types aren’t supported at all, have to used boxed ones. Its slightly annoying but not too much. You can fall back to arrays to have performant primitive containers.
Post reply on HN