Eight years of Go • Hacker News Board

Re: Eight years of Go

#21

Post by [deleted] » Fri, Nov 10, 2017, 6:46 PM UTC

hood_syntax wrote: post #13

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

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.

[deleted]

Re: Eight years of Go

#22

Post by ori_b » Fri, Nov 10, 2017, 6:46 PM UTC

hood_syntax wrote: post #13

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

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/

Re: Eight years of Go

#23

Post by pera » Fri, Nov 10, 2017, 6:46 PM UTC

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

Maybe, but even then at the end they decided to pay attention to this "vocal minority" and add go dep.

Re: Eight years of Go

#24

Post by misframer » Fri, Nov 10, 2017, 6:47 PM UTC

hood_syntax wrote: post #13

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

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.

I've been using Go at work and for my personal projects for over 4.5 years. I rarely have to sort. It's not a big deal for me.

Re: Eight years of Go

#25

Post by ori_b » Fri, Nov 10, 2017, 6:48 PM UTC

nine_k wrote: post #17

noncoml wrote: post #2

Things I love about go: 1. Probably the best ecosystem out there. 2. Go routines 3. (Enabled by (2) actually) `defer` 4. That I can add interfaces implementations to structs I don’t own 5. No exceptions. Actually (5) is one of the few things I don’t like about Haskell. If Go had ADTs and generics it would easily be my favorite language. Edit: and of course the channels. Edit2: yeah, i have no idea why i connected (2)…

I wonder how the presence of ADTs and absence of generic functions would mesh together. With ADTs, using a sum type instead of the `result, err = func(...)`, would be an obvious thing to do. But the next thing you'd consider would be `bind` / `>>=`.

I'm not sure why the next thing you'd consider is bind. It seems like plenty of languages with ADTs and generics still either don't have it available in their libraries, or use it extremely lightly, in spite of being able to implement it.

Re: Eight years of Go

#26

Post by sigzero » Fri, Nov 10, 2017, 6:49 PM UTC

noncoml wrote: post #2

Things I love about go: 1. Probably the best ecosystem out there. 2. Go routines 3. (Enabled by (2) actually) `defer` 4. That I can add interfaces implementations to structs I don’t own 5. No exceptions. Actually (5) is one of the few things I don’t like about Haskell. If Go had ADTs and generics it would easily be my favorite language. Edit: and of course the channels. Edit2: yeah, i have no idea why i connected (2)…

#5 is not a positive thing.

Re: Eight years of Go

#27

Post by [deleted] » Fri, Nov 10, 2017, 6:49 PM UTC

tonyedgecombe wrote: post #6

noncoml wrote: post #2

Things I love about go: 1. Probably the best ecosystem out there. 2. Go routines 3. (Enabled by (2) actually) `defer` 4. That I can add interfaces implementations to structs I don’t own 5. No exceptions. Actually (5) is one of the few things I don’t like about Haskell. If Go had ADTs and generics it would easily be my favorite language. Edit: and of course the channels. Edit2: yeah, i have no idea why i connected (2)…

Lack of exceptions is the main reason I won't use it.

[deleted]

Re: Eight years of Go

#28

Post by nine_k » Fri, Nov 10, 2017, 6:49 PM UTC

hood_syntax wrote: post #13

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

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.

Apparently, the project leaders see it as a lower-priority (though not unimportant) issue. Looking at the adoption figures, they seem to be right.

I personally stay away from Go due to lack of generics and other expressiveness issues. People who have to work with it write code generators on top of the compiler, because the compiler team won't include it into the language. (I can see how it's not an easy thing to do; Russ Cox wrote a nice piece about it.)

Java prior to version 5 had the very same problem. It was wildly popular nevertheless. It took Java 8 years to gain support for generics, though, about as long as it took Go to not yet obtain them. (By that time, Java was widely considered the Cobol of 21st century; I think Go must be successfully stealing that crown now.)

Re: Eight years of Go

#29

Post by AnIdiotOnTheNet » Fri, Nov 10, 2017, 6:49 PM UTC

hood_syntax wrote: post #13

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

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.

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.

Re: Eight years of Go

#30

Post by krylon » Fri, Nov 10, 2017, 6:50 PM UTC

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 language. And don't get me wrong, I like both of these languages.

But with Go, my intuition what I think a given piece of code should mean is nearly always in line with the language specification. The only other language I had this level of rapport with is Python.

There are many things I miss in Go, but all in all, I think it is simplicity done right.

BUT if Go had not also gotten the things right that you mention, it probably would not have become this popular.