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

Expectations for generics in Go 1.18

groups.google.com

Post reply on HN
Print view View original

151–160 of 209 posts

Re: Expectations for generics in Go 1.18

#151

Post by parley »

y4mi wrote: post #145
kubb wrote: post #137

Earlier quoted context omitted.

That's an expected pivot. From "nobody needs generics" to "we absolutely needed 10 years to figure out the best way to do parametric polymorphism, which was already known for 35 years when the language was created". And of course in addition to that, there will probably be claims that "no one claimed that generics aren't needed". I'm glad that we have the archives to show that this isn't true, and it's a good thing t…

Often the people that expressed that opinion are different people then for example the person you responded to here. Please remember that this is a forum of a very big group of participants with varying points of view and resulting opinions. Even if he was previously a person that said golang doesnt need generics, I struggle with your point of view. It seems you're of the opinion that nobody should be allowed to... c…

You're arguing for charitable interpretations of statements by people who claimed Go didn't need generics or even that Go was better without them, saying that one should be able to change ones opinion without being called dumb. I fully agree.

Similarly, a charitable interpretation of what kubb wrote would be that they are referring to those who might have been dishonest in their defense of Go's lack of generics, which one might say kubb does indicate by using words like apologetes and zealots. The Internet is full of people who pick a team and will say dishonest things in perceived defense of it. I agree with kubb in this regard. That is the charitable interpretation of what kubb wrote, but instead you assumed kubb referred to everyone who ever voiced that opinion and suggested kubb should refocus on what kind of person they want to be.

The Internet needs more of charitable interpretations, and HN in particular. Perhaps I failed to interpret you charitably now? Nuances get lost easily in online debates... :)

Re: Expectations for generics in Go 1.18

#152

Post by StevePerkins »

kubb wrote: post #137
sudhirj wrote: post #133

Earlier quoted context omitted.

Sigh. Go without generics was useful. We built useful things with it. Go with generics will continue to be useful, and it'll make it easier to build some things that were irritating to build earlier. The design of generics went though so many rounds of iteration and discussions to make sure it wasn't a detriment to the language - indeed you can build everything that Go has already been used to build without ever know…

That's an expected pivot. From "nobody needs generics" to "we absolutely needed 10 years to figure out the best way to do parametric polymorphism, which was already known for 35 years when the language was created". And of course in addition to that, there will probably be claims that "no one claimed that generics aren't needed". I'm glad that we have the archives to show that this isn't true, and it's a good thing t…

The term "gaslighting" has become overwrought to the point where it's hard not to immediately dismiss anyone using it.

It is not a "pivot" for someone to say, "X isn't necessary", and then say, "X still isn't necessary but at least it's implementation doesn't break things".

Re: Expectations for generics in Go 1.18

#153

Post by julik »

chairmanwow1 wrote: post #119
kubb wrote: post #113

Earlier quoted context omitted.

They already have it with panic and recover. They just don't recommend using it for error handling.

Even if this behavior is similar to how Java exceptions work, I love the way go packages are written. Explicit error handling can be tedious, but I’m never confused about what some code will do. Compared to Java where an exception may bubble up 10 layers to a catchall try catch statement, I actually know where the error is coming from. Would be nice to have this abstracted away with tooling though. I would imagine go…

Go errors are actually less useful in this case since they do not capture backtraces by default (if I remember well), and invite gratuitous re-wrapping. Most times I had to troubleshoot something it was useful to know the lowest level where the error happened, not the arbitrary level the application/library author decided to be appropriate and missed.

Re: Expectations for generics in Go 1.18

#154

Post by throwaway894345 »

parley wrote: post #151
y4mi wrote: post #145

Earlier quoted context omitted.

Often the people that expressed that opinion are different people then for example the person you responded to here. Please remember that this is a forum of a very big group of participants with varying points of view and resulting opinions. Even if he was previously a person that said golang doesnt need generics, I struggle with your point of view. It seems you're of the opinion that nobody should be allowed to... c…

You're arguing for charitable interpretations of statements by people who claimed Go didn't need generics or even that Go was better without them, saying that one should be able to change ones opinion without being called dumb. I fully agree. Similarly, a charitable interpretation of what kubb wrote would be that they are referring to those who might have been dishonest in their defense of Go's lack of generics, whic…

I sort of agree. The most charitable interpretation is that kubb is “nutpicking”—addressing the least articulate and worst arguments of a community. But he would do us all a favor to acknowledge explicitly the boundaries of his criticism. For example, I hold the position that generics aren’t necessary, but that they will make some code more clear and a lot of other code less clear (and this has long been my position)—does kubb’s criticism apply to positions like mine? Am I his “zealot”?

Moreover, using terms like “zealot” to refer to people with whom one disagrees is very likely to inflame the thread (as indeed it already has, to a degree), whatever kubb’s intention.

Re: Expectations for generics in Go 1.18

#155

Post by throwaway894345 »

valenterry wrote: post #120
sph wrote: post #92

Earlier quoted context omitted.

Niche in your niche perhaps, but there's a lot of code in the wild written in Go. Hell, all the modern devops tools are written in Go (Docker, k8s & co.) Meanwhile, as a non Java programmer, I've never seen a Scala app. I know about R, but nothing on my PC is written in it. Agreed that PHP is massive in comparison to all of them.

Sure, devops tools are usually more fundamental, whereas high level languages are used for things closer to the business. Twitter's backend for example is mainly powered by Scala, but you probably don't know about it, because it is not as visible to you.

Enumeration isn’t a compelling way to indicate relative frequency (in this case, frequency of usage of Go and Scala, respectively). An enumeration of size=1 is even less convincing.

Re: Expectations for generics in Go 1.18

#156

Post by throwaway894345 »

awestroke wrote: post #72

And so Go is one step closer to being a real programming language in many people's eyes.

It seems eminently foolish to think Go isn’t a “real language” for lack of generics—why should we concern ourselves about fools’ opinions?

Re: Expectations for generics in Go 1.18

#157

Post by Joker_vD »

Cthulhu_ wrote: post #110
iamcreasy wrote: post #106

Earlier quoted context omitted.

I suppose there are many examples like this. Once I've copied a piece of code from SO but IntellijIDEA was warning me that the semicolon at the end of the line is not correct. Upon further investigation(I think IntelljIDEA reported Unicode value) I've found out that the 'semicolon' I copied is a Greek character that looks exactly like semicolon. I wonder how people on vim/emacs deal with situation like this.

It's similar when online editors try to be clever and replace a straight " with a fancy one (like in Word), really annoying.

That's why Powershell actually recognizes those fancy quotes and treats those as normal quotes.

Re: Expectations for generics in Go 1.18

#158

Post by cle »

kubb wrote: post #117

I'm glad that all the blog posts written by the apologetes and zealots, claiming that Go doesn't need generics and how they will actually be a detriment to the language, are archived somewhere in the wayback machines, so that they can't gaslight us into believing that they weren't just being silly for all this time.

This attitude/mindset seems so petty and disappointing. Feels to me like gotcha journalism or something.

Re: Expectations for generics in Go 1.18

#159

Post by throwaway894345 »

julik wrote: post #153
chairmanwow1 wrote: post #119

Earlier quoted context omitted.

Even if this behavior is similar to how Java exceptions work, I love the way go packages are written. Explicit error handling can be tedious, but I’m never confused about what some code will do. Compared to Java where an exception may bubble up 10 layers to a catchall try catch statement, I actually know where the error is coming from. Would be nice to have this abstracted away with tooling though. I would imagine go…

Go errors are actually less useful in this case since they do not capture backtraces by default (if I remember well), and invite gratuitous re-wrapping. Most times I had to troubleshoot something it was useful to know the lowest level where the error happened, not the arbitrary level the application/library author decided to be appropriate and missed.

Agreed, there are tradeoffs, but at least Go’s approach has more potential—there’s nothing stopping Go from capturing stack traces and returning them on the error object. On the other hand, exceptions always have the confusing control flow problem.

Re: Expectations for generics in Go 1.18

#160

Post by Someone »

Athas wrote: post #121
Cthulhu_ wrote: post #112

Earlier quoted context omitted.

I've come to prefer code quantity over code complexity. I mean, what the fuck is def traverseImpl[F[_], A, B](fa: Option[A])(f: A => F[B])(implicit F: Applicative[F]) = fa map (a => F.map(f(a))(Some(_): Option[B])) getOrElse F.point(None)

This is probably less readable than it has to be due to the lack of whitespace. I don't know the language (Scala?), but I don't think it's too hard to work it out. First, the '[F[_], A, B]' part are type parameters, where I assume the 'F[_]' part is just a bad notation for a type of kind '* -> *' (i.e. a higher-ranked type). The next value parameter has type 'Option[A]', and after that we have 'A => F[B]'. This confi…

scala has infix everything ‘operators’. f(x) can be written as f x and f.g(x) can be written as f g x if the parser manages to figure out what it means (I’m sure they phrase that differently)

Idea, I think, is to make the repl look more like a CLI, but it also may be a fight against punctuation.

Post reply on HN