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

51–60 of 105 posts

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

#51

Post by omarforgotpwd »

shurcooL wrote: post #43
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.

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.

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

#52

Post by quotemstr »

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 a lot easier to use lints, binding coding standards, compiler options, and so on to limit your team to a subset of the language than it is to bolt more power later onto a language like Go.

Being opinionated works well for some teams --- I get that. You don't need the language spec to be opinionated when you can get the same result through mechanisms that don't affect everyone.

It's just like when we're writing code: don't make global changes to achieve some local effect

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

#53

Post by Jtsummers »

quotemstr wrote: post #20
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..

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

C++ implementations were commercial products. Same with C before it, and many (possibly most) languages used in industry. Because platforms were less uniform, and even where they were porting still took much more effort than it does today.

It's really hard to justify making a new go, python, lua, etc. implementation when the primary ones are stable and support a large number of platforms.

And adding language features by altering syntax/semantics, you might as well produce an entire new language rather than deal with the headaches of being partially compatible and having to track the original over time.

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

#54

Post by themartorana »

twblalock wrote: post #25
quotemstr wrote: post #20

Earlier quoted context omitted.

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.

"It's not very widely used."

Um. Well ok, maybe but not likely, as pointed out by a sibling comment, but it is used by a large fraction of companies that deal with services on an enormous scale - Google (obvi), Dropbox, Cloudflare... here, better than copy/paste: https://github.com/golang/go/wiki/GoUsers

You're going to recognize an awful lot of those companies.

Edit: not sure if it counts, but the number of companies using software written in Go in mission-critical ops is enormous (see: Docker).

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

#55

Post by scott_s »

catnaroek wrote: post #24
spriggan3 wrote: post #16

Earlier quoted context omitted.

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.

In fact, if I understand spriggan3's proposal correctly, that's how Java's generics work. The approach is usually called type-erasure. (https://docs.oracle.com/javase/tutorial/java/generics/erasur...)

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

#56

Post by stcredzero »

sbov wrote: post #48
stcredzero wrote: post #41

Earlier quoted context omitted.

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.

By giving this power, you also increase the consistency of the language.

Maybe. That's like the apocryphal story about the student asking a question if a particular proof step is really obvious, so the professor goes across the hall, derives stuff on the other blackboard for the next 30 minutes, then comes back into the lecture hall saying, "Yes, it's obvious."

Maybe you increase the consistency of the language from one point of view, but what happens from the perspective of each individual project? What if this leads to projects where templates have been used to create 3 different template based "little languages" to make X, Y, and Z easier? You had 3 problems, but now you have 6. The oft written reply to that in these debates, is to limit the power of the template system -- but is that a robust goal under the group dynamics of the language community? I think not.

One subliminal goal in the design of Go seems to be about privileging certain conventions to avoid a babel of roll-your-own conventions in large projects. This is all across the language and even in the toolchain.

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

#57

Post by woah »

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.

The privileging of Go's stdlib is a core design choice. The idea is that your implementation code is simple, and the language takes care of library code in whatever way is best. If you don't like it, use another language.

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

#58

Post by stcredzero »

quotemstr wrote: post #52
stcredzero wrote: post #41

Earlier quoted context omitted.

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 a lot easier to use lints, binding coding standards, compiler options, and so on to limit your team to a subset of the language than it is to bolt more power later onto a language like Go. Being opinionated works well for some teams --- I get that. You don't need the language spec to be opinionated when you can get the same result through mechanisms that don't affect everyone. It's just like when we're writing c…

It's a lot easier to use lints, binding coding standards, compiler options, and so on to limit your team to a subset of the language than it is to bolt more power later onto a language like Go.

This deserves a bitter laugh. For large, long-lived codebases, where there have been effectively many different teams and a number of different managers, the standards, coding styles, and tooling are almost certain to change. If you know of a large corporate codebase where this is not true, please tell me about it. Hell, you need to write a paper about this and start giving talks at conferences!

It seems like the Go maintainers are trying to solve this by moving such conventions from the level of individual project to the level of the language community. I think there is merit in this. For one thing, I suspect this will create greater social and intellectual cohesion across the language community as a whole.

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

#59

Post by woah »

mattnewton wrote: post #45
karma_vaccum123 wrote: post #19

Earlier quoted context omitted.

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.

You say you like the simplicity, yet you are complaining about it.

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

#60

Post by mseepgood »

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.

"vastly friendlier type systems"? The type systems of all of these languages are more "bondage & discipline" than Go's. Stricter, more complex.
Post reply on HN