261–270 of 288 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
You keep posting that. Do you understand the difference between that and "we anticipate that Go will never add generic methods"? What they actually said shows epistemic humility and recognizes that they might change their mind.
Hi! I'm a human being that is trying to understand the world and make friends along the way. I see you are too! Pleased to meet you. You asked the question > Where did "they" say "we" didn't need generics? And I (re)posted a quote from them, which sounds to me like, at the time, they believed that "we" Go users didn't need generics. They may have changed their mind, which is totally fine! But I do think it sounds lik…
Earlier quoted context omitted.
> 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.
Based on what? Sure, the one guy managed to hack up the first version of C, but it took a complete rewrite and some major changes to become what we would actually recognize as C. Not exactly indicative of someone who knows what he is doing. And everything in Go was copied straight from Winterbottom's work.
Earlier quoted context omitted.
I am not very familiar with Go and especially not its generics support. Can you implement the "join" version instead of the "bind" version, where you turn a T[T[a]] into a T[a]?
Hmm I wasn't familiar with join, but it looks like you still need join + fmap for the construction? I believe fmap would also need a generic method
Earlier quoted context omitted.
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 o…
> Similar to what java does.
Yes, if you completely forego the static implementation, you can deal with just one. Then all code is slow.
Java can get away with it, because it has a JIT compiler – so it isn't subject to the same "no runtime code generation" design restriction Go is. That also means, it can run on fewer platforms than Go.
> add a new type of interface that is only for use in generic constraints
Yes, that would be feasible. It has been ruled out, because we really don't want to have interfaces that can not be used as types. They currently exist, but the goal is to remove that restriction, not to add more of the same.
I'll note that either way, at that point we are firmly outside the realm of this particular thread. It's no longer what I was responding to.
Earlier quoted context omitted.
> 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
Thank you for clarifying this for me.
Earlier quoted context omitted.
> 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…
> Perhaps what you want is a container which adheres to monad laws capable of abstracting exceptions That is what I meant. Struggling to picture what the other "nonsensical" thing is.
Can we have Exception monads? Asking for friend.
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…
With full respect given to Wadler and his contributions to computer science, the very paper you cite authored by Wadler declares:
The concept of a monad, which arises from category theory,
has been applied by Moggi to structure the denotational
semantics of programming languages.
Earlier quoted context omitted.
You're not meant to gaslight about the evolution of software.
You're not meant to apply poor man's psychology everywhere just because you have heard about a certain psychological term.