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

41–50 of 105 posts

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

#41

Post by stcredzero »

quotemstr wrote: post #14
patates wrote: post #5

So the current approach is providing some popular functions which would normally require generics to implement as built-ins?

I was just ranting about this approach elsewhere. Go and QBasic are broken in the same way: both lack power in the core language and have special syntax for facilities that really ought to be normal calls into the standard library. In Go's case, we have goroutines, error flag omission, maps, and so on; in QBasic, we have LINE. A language's core syntax should not privilege its standard library above other libraries.

A language's core syntax should not privilege its standard library above other libraries.

I'm not so sure. Smalltalk had this in spades. There is a downside to this. Giving a bunch of 20-somethings the full power to basically change everything can result in code-bases which suffer from the chaos of over exuberant hubris. Go is deliberately favoring a certain set of conventions. To do this, they are also deliberately making it harder to change the language from within itself.

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

#42

Post by bigdubs »

masklinn wrote: post #32
bigdubs wrote: post #12

Another approach to this (this is used to good effect in LINQ) is to skip the `Less(i,j)` and just provide a value extractor, except golang makes that super verbose because you'd have to do `func(v interface{}) interface{}` The idea would be if you have `type foo struct { ID int, Rank int }` you could provide `func(v interface{}) interface{} { return v.(foo).Rank }` and it would sort by rank. Some level of late bindi…

> Another approach to this (this is used to good effect in LINQ) Also in Python, it's called "key functions". Of course since Go doesn't have tuples and/or user-defined ordering, it either only works for simple comparisons (e.g. by rank but not by rank and name) or you have to hand-roll some weird-ass coercion into whatever key type the language uses. > you'd have to do `func(v interface{}) interface{}` And that does…

Also time.Time (which could be thought of as two int64s)

Even string ordering there is a lot left up to the implementation as far as how it is done. Do capitals come first? Does capitalization not matter? etc.

For non-intrinsic types you would provide the equivalent `less` function, but in my own programming the bulk of the things I order by are intrinsic.

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

#43

Post by shurcooL »

eknkc wrote: post #17

It seems like due to lack of generics I see more and more interface{} and reflection stuff in code bases. This is getting ridiculous. I've written a lot of Go. Tried my best to stick to what language provides but at some point you say "screw it" and start fighting with the language. That is never a good sign.

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.

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

#44

Post by wyager »

pjmlp wrote: post #15
patates wrote: post #5

So the current approach is providing some popular functions which would normally require generics to implement as built-ins?

Or use code generation via the generate package. Go is a great C replacement for any use case where using a GC is an affordable option. Other than that, there are lots of other languages with AOT compilation to native code and better abstractions.

If I can use GC, why would I pick go over any of the other compiles-to-native languages with vastly friendlier type systems and language features? Rust, D, Haskell, etc. all offer similar performance profiles and are much nicer for the programmer.

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

#45

Post by mattnewton »

karma_vaccum123 wrote: post #19
mattnewton wrote: post #13

Earlier quoted context omitted.

Right, so now I'm forking it and maintaining my own language to add a feature I just get for free in any number of reasonable competitors..

Rust is ready, free, and open. Use it and stop complaining about Go.

In my case it's python, Rust has a bit more of a learning curve / productivity hit. I'm still complaining though because I like what Go is doing with concurrency and simplicity, but I think it would be almost perfect if it just trusted the user a bit more.

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

#46

Post by twblalock »

zzzcpan wrote: post #38
twblalock wrote: post #25

Earlier quoted context omitted.

I think you overestimate the number of people who care that much about Go. It's not very widely used. It would also be a massive effort to add generics to it at this point, because of the design choices the team made early on.

> It would also be a massive effort to add generics to it at this point Not really. The easiest approach would take like a day for PoC.

What approach would that be?

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

#47

Post by geodel »

wyager wrote: post #44
pjmlp wrote: post #15

Earlier quoted context omitted.

Or use code generation via the generate package. Go is a great C replacement for any use case where using a GC is an affordable option. Other than that, there are lots of other languages with AOT compilation to native code and better abstractions.

If I can use GC, why would I pick go over any of the other compiles-to-native languages with vastly friendlier type systems and language features? Rust, D, Haskell, etc. all offer similar performance profiles and are much nicer for the programmer.

Most likely you wouldn't but many seems to prefer it over Rust/D/Haskell.

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

#48

Post by sbov »

stcredzero wrote: post #41
quotemstr wrote: post #14

Earlier quoted context omitted.

I was just ranting about this approach elsewhere. Go and QBasic are broken in the same way: both lack power in the core language and have special syntax for facilities that really ought to be normal calls into the standard library. In Go's case, we have goroutines, error flag omission, maps, and so on; in QBasic, we have LINE. A language's core syntax should not privilege its standard library above other libraries.

A language's core syntax should not privilege its standard library above other libraries. I'm not so sure. Smalltalk had this in spades. There is a downside to this. Giving a bunch of 20-somethings the full power to basically change everything can result in code-bases which suffer from the chaos of over exuberant hubris. Go is deliberately favoring a certain set of conventions . To do this, they are also deliberately…

It's not about changing everything, it's about being able to make abstractions that aren't second class citizens. By giving this power, you also increase the consistency of the language.

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

#49

Post by interactiv »

burntsushi wrote: post #39
interactiv wrote: post #28

Earlier quoted context omitted.

yep, I wrote this : https://github.com/Mparaiso/lodash-go which is in theory "runtime type safe" in the sense that is yields an error if types do not match , but it uses reflection which leads to a huge performance hit. The irony is that Go is a perfectly capable functional language when one opts out of Go type system. (Don't use that package, this is not idiomatic Go).

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.

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

#50

Post by zzzcpan »

twblalock wrote: post #46
zzzcpan wrote: post #38

Earlier quoted context omitted.

> It would also be a massive effort to add generics to it at this point Not really. The easiest approach would take like a day for PoC.

What approach would that be?

That would be meta/templating approach.
Post reply on HN