Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eight years of Go

blog.golang.org

Post reply on HN
Print view View original

71–80 of 291 posts

Re: Eight years of Go

#71

Post by krylon »

ori_b wrote: post #22
hood_syntax wrote: post #13

Earlier quoted context omitted.

Are the complaints about lack of generics really a minority thing? Writing separate functions to sort different types just strikes me as ridiculous. EDIT: My original tone was a bit nasty in retrospect. Did a little research and while I still am on the generics side, the current situation seems at least workable for a good number of use cases.

But you don't need to do that. It's a bit clunkier than generics, but it's usable: https://golang.org/pkg/sort/

I have had the need to sort data rarely enough that it has not been a real problem to me (most of the time that data came out of a relational database that did the sorting for me).

But when I did have the need to sort stuff, I have found it annoying. Even C has a more convenient solution for this problem. (Admittedly, Go's sort.Sort can work for data structures other than arrays/slices.)

Like I said, it has not been a sufficiently large problem to really bother me, but it is not a pretty solution, IMHO.

Of course, one might argue that the creators of Go knew that sorting things was not such a common problem for their target audience, and thus they made the trade off to make sorting suck in return for overall simplicity; Go's type system makes it practically impossible to implement a type-generic sorting function like C's qsort(3) without sacrificing performance or making the language more complex.

So maybe that is one of the trade offs we have to make. I still wish for a better solution, even if that may be impossible without turning Go into another C++. And if you like C++, that is totally fine, it has a number of very big advantages. But then you do not need Go to become another C++ if you have the original right there; and even if you wanted to get away from C++ without giving up the benefits it offers, D looks like a more promising alternative.

Re: Eight years of Go

#72

Post by freyir »

rdsubhas wrote: post #41
nine_k wrote: post #7

Go is an example of how to be extremely successful by catering to the needs of the project's core audience (well-rounded stdlib, extremely fast GC, short build times, trivial deployment, etc) while paying much less attention to the vocal minority's complaints (generics, package system, etc).

I'm not sure what you mean by vocal minority's complaints. Golang generics is the second most voted issue on GitHub itself: https://github.com/issues?q=is%3Aopen+is%3Aissue+sort%3Areac... (I'm not sure if GitHub sorting is broken, but the same issue has more +1s than the top +1d issue as per that sort mode as well) Generics has the most experience reports in Go 2 proposal. Maybe this can be categorized and excluded a…

It's the biggest issue, but that doesn't mean the majority of Go developers support it. 1734 people reacted to the generics issue, most in favor, but there are many more Go developers than that.

But the people who read the proposal and reacted to it may be the vocal minority who are concerned about generics. The majority may not spend their time reading or reacting to proposals they don't care about.

Re: Eight years of Go

#73

Post by AnIdiotOnTheNet »

weberc2 wrote: post #48
AnIdiotOnTheNet wrote: post #29

Earlier quoted context omitted.

Yes, it is minor. Go has interfaces, so you just write a Comparer interface and sorter that takes two Comparers and then anything implementing Comparer is sortable. *Note: author has written basically nothing in Go and only has a passing familiarity.

If your `Comparer` is an element type (as opposed to Go's `sort.Interface` abstraction over collections), this is going to be horribly unperformant. Suppose your `Foo` type implements `Comparer`, and you have a large `[]Foo`. Then you'll first have to iterate over each element in `[]Foo` and add it to your `[]Comparer`, probably with an allocation per element. Then each invocation of `foo.Compare()` is going to be in…

From this description, I'm getting the impression that Go's interfaces are not as much like Java interfaces as I had assumed.

Never the less, I find that generics usually are just an over-engineered solution to any given problem.

Re: Eight years of Go

#74

Post by pcwalton »

dualogy wrote: post #69
pcwalton wrote: post #65

Earlier quoted context omitted.

You're still writing separate functions (implementations of sort.Interface) to sort different types.

A little boilerplate hasn't killed anyone. If you're talking about "100s of different Enterprise Business Objects (TM) structs", something is probably off in the overall program design and/or code-gen should probably be introduced regardless of the 'sort' (and related typically-generics use-cases) question, as that sounds like something to be largely derived from pre-existing schemas of some sort..

> A little boilerplate hasn't killed anyone.

It's annoying, especially since basic generics are simpler than interfaces.

> If you're talking about "100s of different Enterprise Business Objects (TM) structs"

I don't write enterprise software. I sometimes need to sort things.

Re: Eight years of Go

#75

Post by rifung »

weberc2 wrote: post #53
Gys wrote: post #20

Earlier quoted context omitted.

Assuming developers are rational in their choices, by far most of the Go developers still prefer to use the language without generics. I think its just a minor problem compared to all benefits.

> by far most of the Go developers still prefer to use the language without generics I've been writing Go regularly for at least 5 years, and my guess is that at most 60% of Go developers prefer no generics. I also think that number is climbing.

I write Go at work but have never heard anyone say this.

Can you explain why you would prefer no generics to this dumb junior engineer who wants to be enlightened?

Re: Eight years of Go

#77

Post by qaq »

pmoriarty wrote: post #55
wheaties wrote: post #44

Earlier quoted context omitted.

The best ecosystem out there? Since when? I'd say that Java and Python have huge, wonderful and full ecosystems. Golang doesn't even come close to that, yet. Furthermore, Golang doesn't even have a community standard (or several standards) dependency manager.

Python's packaging is a nightmare of half-baked, incompatible approaches that puts the lie to the famous "Zen of Python" that "There should be one-- and preferably only one --obvious way to do it."

and yet Pipenv is miles ahead of what Go has to offer.

Re: Eight years of Go

#78

Post by tetraodonpuffer »

krylon wrote: post #30
nine_k wrote: post #7

Go is an example of how to be extremely successful by catering to the needs of the project's core audience (well-rounded stdlib, extremely fast GC, short build times, trivial deployment, etc) while paying much less attention to the vocal minority's complaints (generics, package system, etc).

You are not wrong. But I think there is more to it. I have used Go (almost) exclusively for private toy programs I write in my free time to relax (sounds weird, I know), so my perspective may be warped. But something about is very compatible with the way my mind works. With some other languages, say C or C#, I find myself constantly browsing through documentation to figure out what a given construct means in that lan…

> my intuition what I think a given piece of code should mean is nearly always in line with the language specification.

for some things yes, but for others I think that it's more familiarity than intuition, take for example interface slices, you start by learning that you can assign any type to interface{}, so intuitively you'd think that you could assign any type slice to []interface{} but you find out soon enough that doesn't work

If you dig a bit it is completely understandable why it doesn't given how interfaces are laid out in memory, but from an intuitive standpoint you'd think that since you can do it in the scalar case you should be able to do it in the slice case too...

This is a very minor nitpick, I do agree that compared to many other languages golang is very easy to mentally parse, at the expense of some expressivity at times.

Whenever I code in it, which these days is pretty much all the time, I do miss some conveniences from other languages (generics, list comprehensions, ...) but of course every language has its tradeoffs, I most certainly miss golang's strengths every time I have to write some C or python.

Re: Eight years of Go

#79

Post by stablemap »

weberc2 wrote: post #59
stablemap wrote: post #3

A post earlier this year by Rob Pike, celebrating ten years of Go: https://commandcenter.blogspot.com/2017/09/go-ten-years-and-...

This blog post is 8 years since Go was an open source project. Rob's post was probably something like "10 years since we began work on Go".

Yes, I didn’t mean to imply a contradiction. Just two articles that go well together.

Re: Eight years of Go

#80

Post by theshrike79 »

dekhn wrote: post #38
nine_k wrote: post #7

Go is an example of how to be extremely successful by catering to the needs of the project's core audience (well-rounded stdlib, extremely fast GC, short build times, trivial deployment, etc) while paying much less attention to the vocal minority's complaints (generics, package system, etc).

Complaints about generics aren't coming from a minority group. It's a majority now.

People want generics because they think every language should have generics.

What they don't know is the exact cases where the lack of generics causes a real-world problem for them. This is what the developers are requesting at the moment, in order to possibly bring generics to Go 2.

Post reply on HN