So the current approach is providing some popular functions which would normally require generics to implement as built-ins?
I understand the want to avoid over architected designs, but relying on a single party (who is not associated with your product or business need) to bless every abstraction you can use in your code base seems like a recipe for pain and awkwardness. Definitely limits me from wanting to make significant investments in go.
Go Proposal: first-class support for sorting slices
11–20 of 105 posts
Re: Go Proposal: first-class support for sorting slices
#12Another 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 binding / genericity would be necessary to make this approach not as verbose.
Re: Go Proposal: first-class support for sorting slices
#13Earlier quoted context omitted.
I understand the want to avoid over architected designs, but relying on a single party (who is not associated with your product or business need) to bless every abstraction you can use in your code base seems like a recipe for pain and awkwardness. Definitely limits me from wanting to make significant investments in go.
https://golang.org/LICENSE
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..
Re: Go Proposal: first-class support for sorting slices
#14So 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.
Re: Go Proposal: first-class support for sorting slices
#15So 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.
Re: Go Proposal: first-class support for sorting slices
#16Earlier quoted context omitted.
Go needs functions that support parametric types for collections. I'm not even talking about generics here as user defined types. Let's forget about generics or "the ability for developers to implement their own type safe containers". Let's talk about the fact that functions in Go could support type parameters in signatures , something like : func Map (slice []V,func(element V)W)[]W { // ... } What we have here is a…
This is nice, but generic functions are still generics.
Go already has generic functions : append, copy ... that are type safe at compile time, how do you think they are implemented in the source code of Go's compiler?
Just like I said. Go compiler finds "append" token, and go look up if both arguments and the return type match, not at run time, at compile time.
Re: Go Proposal: first-class support for sorting slices
#17It 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.
Re: Go Proposal: first-class support for sorting slices
#18So 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.
Can you give an example of what exactly generate does? All I can tell is that it me you call other programs like yacc to preprocess some files. So just a replacement for make?
Re: Go Proposal: first-class support for sorting slices
#19Re: Go Proposal: first-class support for sorting slices
#20Earlier quoted context omitted.
https://golang.org/LICENSE
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..
Well, that's how C++ started. I'm honestly surprised nobody's forked Go or made a less obnoxiously opinionated front-end.