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

Go Proposal: first-class support for sorting slices

github.com

Post reply on HN
Print view View original

101–105 of 105 posts

Re: Go Proposal: first-class support for sorting slices

#101

Post by pjmlp »

pcwalton wrote: post #98
stcredzero wrote: post #96

Earlier quoted context omitted.

Can you explain with an example that would apply to Go how introducing generics to a language was making a mistake? Be specific. These things are epiphenomenal, and have to do with what happens in large codebases over a long time, with lots of programmers. It's a fallacy to suppose that neat StackOverflow sized examples are some kind of a evidence gold standard. The problems I've encountered with C++ templates have t…

I'm not asking for examples of bad interactions between C++ templates and other features of C++--there are tons of those. I'm asking for examples of languages in which implementing simple generics was a bad idea in retrospect. (I don't think there are any such examples, because simple ML-style generics yield a lot of power for negligible drawback, and I hope that future versions of Go add them.)

I won't happen, there was this presentation some time ago that the language design was done and their focus was improving the runtime and tooling.

Hence why I decided to stop arguing about Go's lack of generics and rather advocate it for those that search for a C + GC with improved type safety.

For the rest of us there are better options.

Re: Go Proposal: first-class support for sorting slices

#102

Post by shurcooL »

omarforgotpwd wrote: post #51
shurcooL wrote: post #43

Earlier quoted context omitted.

Why hasn't it happened to me? I've been writing Go for over 3 years, and I prefer the language stay as is. I'm more concerned about porting it to more platforms. Perhaps that's a reason I'm motivated to desire less language changes.

I'm curious, what platform do you want to go to support that it doesn't already? Platform support seems pretty good already, at least for my needs.

A really big and popular platform where Go isn't officially supported yet is the web (browser).

I'm trying to push that direction as much as I can by contributing to GopherJS [0], which is IMO our best bet until wasm [1] comes out and has adds support for GC languages [2].

I agree the rest of the platform support is absolutely fantastic. We have the big 3 desktop OSes, as well as iOS and Android already. But so much of what we do today is on the web, and I don't want to keep using JavaScript or to keep crossing the Go JS boundary inconsistencies. That's not the kind of future I want to invest in.

[0] https://github.com/gopherjs/gopherjs#readme

[1] https://webassembly.github.io/

[2] https://github.com/WebAssembly/design/blob/master/FutureFeat...

Re: Go Proposal: first-class support for sorting slices

#103

Post by shurcooL »

coldtea wrote: post #63
shurcooL wrote: post #43

Earlier quoted context omitted.

Why hasn't it happened to me? I've been writing Go for over 3 years, and I prefer the language stay as is. I'm more concerned about porting it to more platforms. Perhaps that's a reason I'm motivated to desire less language changes.

> Why hasn't it happened to me? Well, don't know about your case, but I've seen e.g. people who are religious about being DRY and dislike any kind of useless boilerplate, and others just copy paste code with wild abandon and couldn't care at all.

I used to care about DRY to a _very_ great degree [0], and I still do. But I've come to realize DRY is much better to apply for high level _concepts_, ideas, and architectures, not unexported helper code.

It's unhelpful to try to apply it to little snippets of code and helpers. It's much less expensive to copy a snippet that's needed and duplicate it 1-2 times before starting to worry about factoring it out. By the time it's repeated 3+ times, you'll have a much better idea how to structure it.

[0] https://github.com/shurcooL/Conception#motivation

Re: Go Proposal: first-class support for sorting slices

#104

Post by shurcooL »

eknkc wrote: post #88
coldtea wrote: post #63

Earlier quoted context omitted.

> Why hasn't it happened to me? Well, don't know about your case, but I've seen e.g. people who are religious about being DRY and dislike any kind of useless boilerplate, and others just copy paste code with wild abandon and couldn't care at all.

Also, I'm generally fine with language tradeoffs, If there is a good reason that I need to copy paste something, so be it. I'll do it. Go and Generics issue on the other hand, feels a little different to me. It is a solved problem. Go does not have an inherent show stopper for generics. It's just not there because of.. What? Stubbornness? I'm not sure. But then it irritates me to copy paste stuff.

> It is a solved problem.

This is debatable. Is it a problem that's solved well? Is it solved in the best way possible and there could never be a better way to do generics?

I think not. I think it's solved adequately, but not great. Compared to the other facilities that Go offers, generics are typically pretty messy and add significant complexity to the language, tools, parsing, reasoning, compilation times, etc.

> It's just not there because of.. What? Stubbornness? I'm not sure. But then it irritates me to copy paste stuff.

This statement is ill-informed. Have you seen https://github.com/golang/go/issues/15292 and https://github.com/golang/proposal/blob/master/design/15292-...? Have you considered all the ways in which it will affect the language and the trade-offs?

Once generics are added to Go, they will forever be there, together with all the disadvantages and missed opportunities, and we'll have to live with them. That's not a thing to be taken lightly.

In comparison, maybe copying a little here and there isn't all that bad.

Re: Go Proposal: first-class support for sorting slices

#105

Post by burntsushi »

interactiv wrote: post #49
burntsushi wrote: post #39

Earlier quoted context omitted.

See also: http://blog.burntsushi.net/type-parametric-functions-golang/

Yes, if you look at the source code I use unification to tell whether types match or not.

You're doing a lot of repeated work though. I was trying to point out this function, which does unification in a generic context, given some function type: https://godoc.org/github.com/BurntSushi/ty#Check ... For example, it reduces a lot of the reflection boiler plate: https://github.com/BurntSushi/ty/blob/master/fun/list.go#L80
Post reply on HN