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

Generics enabled by default in Go tip

go-review.googlesource.com

Post reply on HN
Print view View original

371–378 of 378 posts

Re: Generics enabled by default in Go tip

#371

Post by pkolaczk »

jshen wrote: post #366
pkolaczk wrote: post #363

Earlier quoted context omitted.

Without generics, you'd have N functions instead of 1. Are you sure N times the complexity of non-generic function is less than 1 time the complexity of a generic function?

No one knows for sure. I’ve seen a study or two that found that reading and writing generic code is a lot harder, while using a generic library is relatively easy.

Writing generic code is indeed harder than writing non-generic code, but what I wanted to point out is that you can't compare generic code to a non-generic piece that handles only one type (which is often what people do), because the functionality is not the same, it is apples to oranges. What you should compare is non-generic code that handles the same cases as the generic one. So the non-generic code would also get a lot of additional complexity due to that - e.g. instance-of checks or repetition that would be absent in the generic one.

I think genericity is like any other abstraction e.g. functions or interfaces. Applying it blindly can lead to more complexity, but in hands of someone who knows what they are doing it can be a great tool for reducing complexity.

Re: Generics enabled by default in Go tip

#372

Post by jshen »

pkolaczk wrote: post #371
jshen wrote: post #366

Earlier quoted context omitted.

No one knows for sure. I’ve seen a study or two that found that reading and writing generic code is a lot harder, while using a generic library is relatively easy.

Writing generic code is indeed harder than writing non-generic code, but what I wanted to point out is that you can't compare generic code to a non-generic piece that handles only one type (which is often what people do), because the functionality is not the same, it is apples to oranges. What you should compare is non-generic code that handles the same cases as the generic one. So the non-generic code would also get…

“ in hands of someone who knows what they are doing it can be a great tool for reducing complexity.”

It really boils down to this, but what does that really mean? I’ve been coding for a very long time, and go is one of the very few languages where it’s relatively easy for me to jump into a code base I’ve never seen before and make sense of it. Maybe the majority of code isn’t written be people that “know what they are doing”?

I like to think in terms of optionality, the magnitude of possible upside and down side. I’ve come to the conclusion that heavy abstraction has a large magnitude of downside risk and relatively small upside benefit for large teams and institutions.

Re: Generics enabled by default in Go tip

#373

Post by sagichmal »

amw-zero wrote: post #353
sagichmal wrote: post #331

Earlier quoted context omitted.

> the builtins are ad-hoc and half-assed In what way are slices and maps half-assed?

I’m sure they mean that because they are not applicable to the rest of the language. It’s like, the Go creators recognized the situation where generics were necessary, but only used it for slices and maps. I really don’t think they were saying that slices and maps themselves are bad. They function perfectly. I’m sure they meant that it’s just silly to confine quasi-generics to those 2 places.

> it’s just silly to confine quasi-generics to those 2 places

Why is it silly?

Re: Generics enabled by default in Go tip

#374

Post by spion »

spion wrote: post #243
iainmerrick wrote: post #237

Earlier quoted context omitted.

No, I don't want _tacked on_ generics. What languages in your opinion have good, non-tacked-on generics? Are they generally better than other languages? Here are some pretty successful languages that gained generics after maturity: C++, Java, C#, TypeScript (based on JavaScript), Objective-C, even Python.

The libraries are better because they're designed with generics in mind. Most C# libraries in use today were built after generics were added, and there never was a large ecosystem already developed at the time Java has had lots of libraries thrown away due to initial lack of generics and a lot of painful migration e.g. https://docs.oracle.com/javase/tutorial/extra/generics/conve... A good parallel would be async-awai…

The ecocystem did start moving forward, but it will take a long time for the older pre async-await libraries to fade away and there will always be some strangeness resulting from the fact a lot of the libraries you find use a totally different API convention that you have to call via promisifying tools.

Re: Generics enabled by default in Go tip

#375

Post by pkolaczk »

jshen wrote: post #372
pkolaczk wrote: post #371

Earlier quoted context omitted.

Writing generic code is indeed harder than writing non-generic code, but what I wanted to point out is that you can't compare generic code to a non-generic piece that handles only one type (which is often what people do), because the functionality is not the same, it is apples to oranges. What you should compare is non-generic code that handles the same cases as the generic one. So the non-generic code would also get…

“ in hands of someone who knows what they are doing it can be a great tool for reducing complexity.” It really boils down to this, but what does that really mean? I’ve been coding for a very long time, and go is one of the very few languages where it’s relatively easy for me to jump into a code base I’ve never seen before and make sense of it. Maybe the majority of code isn’t written be people that “know what they ar…

Proper abstraction can have a huge upside by allowing people to understand a part of the project without the need to understand all of it. We're using abstractions all the time really, you don't need generics for that. An iterator, a collection, a file, a network connection, a database table are all abstractions. You don't have to read N millions of lines of database code to learn how to use a database. Abstractions like these are good.

Abstractions where the description of the usage (API) is just as complex as the implementation are bad, and I bet you can create them in Go quite easily without generics. At least I know it is possible in Java, and also was before Java 5.

Re: Generics enabled by default in Go tip

#376

Post by VirusNewbie »

Taek wrote: post #251
tengbretson wrote: post #31

Earlier quoted context omitted.

Maybe you could have gotten that work done with fewer than 500,000 loc if you used a language with a better feature set.

Lines of code is a complete red herring. It takes me less time to read and review 500 lines of Go than it does 100 lines of JavaScript. Sometimes - especially in other languages - you see a piece of "elegant" code that does something complex in line 3 lines, and you think "hmm, this is a puzzle, and I'm going to be staring at it for 20 minutes before I'm convinced that its 100% correct." We actively tell our engineer…

Study after study has shown people fail at repetitive tasks, it is likely you do a much poorer job reviewing that 500 lines of Go code than your javascript.

Using generics isn't 'clever'. It's like saying a loop is clever. It's abstraction, the opposite of clever.

Re: Generics enabled by default in Go tip

#377

Post by jshen »

pkolaczk wrote: post #375
jshen wrote: post #372

Earlier quoted context omitted.

“ in hands of someone who knows what they are doing it can be a great tool for reducing complexity.” It really boils down to this, but what does that really mean? I’ve been coding for a very long time, and go is one of the very few languages where it’s relatively easy for me to jump into a code base I’ve never seen before and make sense of it. Maybe the majority of code isn’t written be people that “know what they ar…

Proper abstraction can have a huge upside by allowing people to understand a part of the project without the need to understand all of it. We're using abstractions all the time really, you don't need generics for that. An iterator, a collection, a file, a network connection, a database table are all abstractions. You don't have to read N millions of lines of database code to learn how to use a database. Abstractions…

Again, a lot is packed into your usage of the term “proper”. I find new code bases in go far easier to read than new code bases in every other language I’ve used. Are you suggesting that most code bases are written by people that don’t know what they are doing, and are improperly using the language features?

Re: Generics enabled by default in Go tip

#378

Post by [deleted] »

jshen wrote: post #377
pkolaczk wrote: post #375

Earlier quoted context omitted.

Proper abstraction can have a huge upside by allowing people to understand a part of the project without the need to understand all of it. We're using abstractions all the time really, you don't need generics for that. An iterator, a collection, a file, a network connection, a database table are all abstractions. You don't have to read N millions of lines of database code to learn how to use a database. Abstractions…

Again, a lot is packed into your usage of the term “proper”. I find new code bases in go far easier to read than new code bases in every other language I’ve used. Are you suggesting that most code bases are written by people that don’t know what they are doing, and are improperly using the language features?

[deleted]
Post reply on HN