Live data from Hacker News

Go Proposal: first-class support for sorting slices

github.com

21–30 of 105 posts

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

#21
post #11

Earlier 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

Something we're slowly coming to terms with is the consequence of having open source without open governance.

It's not clear to me that the language would be better if the project stewards accepted more feature requests, though. It is incredibly difficult to hold the line against feeping creatures and a noisy minority when the benefit of simplicity is diffuse.

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

#22
> naming a new type (e.g. "widgetsByName") is tedious to many

More than tedium, it's a bit sinister because the convention of creating 'parallel' slice types with names like that blurs the line between what's a noun and what's a verb. With a type name like that, one would expect a value of that type to always be sorted, right? Nope! A "widgetsByName" is just a flower in the breeze hoping that the sort.Sort bumble-bee makes contact.

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

#23

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..

Well, that's how C++ started. I'm honestly surprised nobody's forked Go or made a less obnoxiously opinionated front-end.

Oden: experimental, statically-typed functional language, built for Go ecosystem

https://news.ycombinator.com/item?id=11183836

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

#24

Earlier quoted context omitted.

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.

No disagreement. I was just pointing out that what you were asking for is in fact user-defined generics.

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

#25

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..

Well, that's how C++ started. I'm honestly surprised nobody's forked Go or made a less obnoxiously opinionated front-end.

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.

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

#26
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.

interface{} is the new void*.

There are far better ways to handle generics in modern languages, which preserve type safety and aren't very cumbersome.

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

#27
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.

interface{} is the new void*. There are far better ways to handle generics in modern languages, which preserve type safety and aren't very cumbersome.

> interface{} is the new void*.

More like Java's Object, especially since downcasts are mandatorily runtime-checked. And the results are exactly what one could have expected from the first 10 years of java (if slightly subdued as Java only had a single magical blessed buildin type) given the language is in more or less the same class.

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

#28
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.

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).

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

#29

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..

Well, that's how C++ started. I'm honestly surprised nobody's forked Go or made a less obnoxiously opinionated front-end.

Go++?

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

#30
I may be an outlier here, but I'm not bothered at all by the way sorting is currently done. It's good enough. The "tedious" type names are mostly unexported anyway, and Len and Swap methods are just a bit of copy-paste.

I don't really think we should tweak it, it's not broken. A code-generation tool would be nice instead.

Post reply on HN