Go Proposal: first-class support for sorting slices

Post by mattnewton » Tue, Aug 16, 2016, 6:06 PM UTC

niftich wrote: post #35

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 promise this isn't a troll question, but isn't the opinionatedness (which is a matter of taste) one of Go's biggest features? Once you remove that, what do you get over Elixir or Erlang, on a technical level? Static linking and no VM?

Post by coldtea » Tue, Aug 16, 2016, 6:12 PM UTC

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.

Post by quotemstr » Tue, Aug 16, 2016, 6:17 PM UTC

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

Post by stcredzero » Tue, Aug 16, 2016, 6:18 PM UTC

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.

Post by stcredzero » Tue, Aug 16, 2016, 6:22 PM UTC

coldtea wrote: post #62

ainar-g wrote: post #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.

> I may be an outlier here, but I'm not bothered at all by the way sorting is currently done. It's good enough. I fear that's also the motto for a lot of Go's design choices.