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

71–80 of 105 posts

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

#71

Post by pcwalton »

stcredzero wrote: post #58
quotemstr wrote: post #52

Earlier quoted context omitted.

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

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

This presupposes that change is bad. In many (most?) codebases, the change in style is good. Gecko, for example, has survived as long as it has because of the gradual migration away from '90s Don Box-style componentry toward modern C++.

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

#72

Post by mattnewton »

woah wrote: post #59
mattnewton wrote: post #45

Earlier quoted context omitted.

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.

Besides the fact that I think it's less simple to have ad-hoc compiler extensions for the standard library types that can't be replicated in userspace, so the alternatives are code generation and type erasure, it doesn't have to be an absolute principal! We can have generics without sliding towards some slippery slope of abstraction! You don't allow some kind of generics one day and wake up the next day with custom operators and monads. The buck really can stop at this one pain point.

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

#73

Post by pjmlp »

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.

Me too, however I do see Go as having a sweet spot for those that don't want to move beyond C, but can accept having a GC around and more type safety.

For everyone else, there are better options.

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

#74

Post by mattnewton »

stcredzero wrote: post #67
mattnewton wrote: post #45

Earlier quoted context omitted.

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.

I think it would be almost perfect if it just trusted the user a bit more. If it trusted the user just a bit more, it would be making many of the same mistakes other languages make, which Go is trying to avoid. You're free to go and use some of those other languages.

I don't understand this attitude. I do use other languages, and I can tell you type polymorphism is not a mistake. Complicated architectures full of abstraction are a mistake, which you can limit without sacrificing the ability for me to make a type-safe generic function.

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

#75

Post by stcredzero »

pcwalton wrote: post #71
stcredzero wrote: post #58

Earlier quoted context omitted.

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

> 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. This presupposes that change is bad. In many (most?) codebases, the change in style is good . Gecko, for example, has survived as long as it has because of the gradual migration away from '90s Don Box-style componentry tow…

This presupposes that change is bad. In many (most?) codebases, the change in style is good.

Sure, such a thing can be good, as in, it's a good trade off. Pulling a tooth can be good in this sense, as it's better than getting further infections from an abscess. But here's the thing about trade-offs -- really you want to avoid having to make them in the first place. (Dental hygiene.)

I'm working in a C++ code base right now. It's like an archaeological dig, with each "layer" corresponding to a major revision of C++ style. It's "good" that parts of the codebase are more modern, but the price for this is the cognitive load of language mode switching. (And occasionally, memory management conundrums.)

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

#76

Post by stcredzero »

quotemstr wrote: post #65
stcredzero wrote: post #58

Earlier quoted context omitted.

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

> 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 Sure, but I've never been convinced consistency matters at that scale. I think it's enough to be locally consistent; Windows doesn't seem to be hurt by its codebase containing practically every style you can imagine. > leve…

Sure, but I've never been convinced consistency matters at that scale. I think it's enough to be locally consistent

In C++, it can result in the occasional memory management paradox to work through. (In addition to the background cognitive load for watching out for such.)

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

#77

Post by pcwalton »

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…

Encouraging consistency across the language ecosystem doesn't have to conflict with layering. The problem with having what are properly library routines in the language core syntax is that it's a layering violation: it makes the language more complex, harder to reason about, and harder to learn because it creates special cases in the grammar and core semantics. (For example, note the inconsistent behavior of indexing a nil map vs. indexing a nil slice.)

The way to discourage people from "changing everything" is to make the standard library ubiquitous and to use encapsulation to prevent people from changing its internals. If Go had generic maps in the standard library, and you couldn't get access to their internals, then the effect would be exactly the same as the built-in map that Go has today. You see this in other languages: very few people create custom dictionaries in C#, for example.

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

#78

Post by pcwalton »

stcredzero wrote: post #75
pcwalton wrote: post #71

Earlier quoted context omitted.

> 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. This presupposes that change is bad. In many (most?) codebases, the change in style is good . Gecko, for example, has survived as long as it has because of the gradual migration away from '90s Don Box-style componentry tow…

This presupposes that change is bad. In many (most?) codebases, the change in style is good. Sure, such a thing can be good, as in, it's a good trade off. Pulling a tooth can be good in this sense, as it's better than getting further infections from an abscess. But here's the thing about trade-offs -- really you want to avoid having to make them in the first place. (Dental hygiene.) I'm working in a C++ code base rig…

I can't tell whether you're arguing (a) that people who originated whatever C++ codebase you're working on should have had better foresight or (b) nobody should have even tried migrating to a more modern style. I think both (a) and (b) are untenable: (a) is equivalent to "people shouldn't make mistakes"—i.e. directly at odds with the real world—and (b) is a recipe for stagnation.

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

#79

Post by stcredzero »

mattnewton wrote: post #74
stcredzero wrote: post #67

Earlier quoted context omitted.

I think it would be almost perfect if it just trusted the user a bit more. If it trusted the user just a bit more, it would be making many of the same mistakes other languages make, which Go is trying to avoid. You're free to go and use some of those other languages.

I don't understand this attitude. I do use other languages, and I can tell you type polymorphism is not a mistake. Complicated architectures full of abstraction are a mistake, which you can limit without sacrificing the ability for me to make a type-safe generic function.

I can tell you type polymorphism is not a mistake.

It's a particular trade-off. Some opine that it's not the right trade off. You disagree.

Complicated architectures full of abstraction are a mistake, which you can limit without sacrificing the ability for me to make a type-safe generic function.

From what I've seen, the other mechanisms for limiting over-exuberant abstraction don't work well enough over the long term, at scale.

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

#80

Post by karma_vaccum123 »

mattnewton wrote: post #72
woah wrote: post #59

Earlier quoted context omitted.

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

Besides the fact that I think it's less simple to have ad-hoc compiler extensions for the standard library types that can't be replicated in userspace, so the alternatives are code generation and type erasure, it doesn't have to be an absolute principal! We can have generics without sliding towards some slippery slope of abstraction! You don't allow some kind of generics one day and wake up the next day with custom o…

Okay, that's nice, but the Go developers already picked their side in the debate many years ago. If you don't like it, use one of the many other tools available.
Post reply on HN