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

361–370 of 378 posts

Re: Generics enabled by default in Go tip

#361

Post by scns »

tptacek wrote: post #93
coryrc wrote: post #65

Earlier quoted context omitted.

Yeah, that's why Kubernetes had to develop code generators. So focused.

I wouldn't know, I don't use K8s. But I did write a code-generating ORM for a Go project and found it in a bunch of ways superior to the ORMs I'd used in dynamic languages, like ActiveRecord. And I've also worked with heavily parameterized Rust crates that kept 20 tabs open in my browser just trying to work my way through a couple function calls. Don't get me wrong, I'd take Rust generics over codegen 8 times out of…

Is your ORM open source?

Re: Generics enabled by default in Go tip

#362

Post by dolni »

scns wrote: post #347
dolni wrote: post #314

Earlier quoted context omitted.

> I've learned that it's better to build many very very simple things and connect them. Not for any technical reasons, but because it allows other developers to quickly begin adding to and fixing your systems. You get to leverage the large amount of mediocre programmers when your systems are simple instead of looking for heros. It's definitely easier said than done though to make systems naturally intuitive and simpl…

Where did parent mention microservices? NSI (No Snark Intended). (edit) A parody about those: https://www.youtube.com/watch?v=y8OnoxKotPQ

I gathered the bit about microservices from

> I try to extend the simplicity of golang all the way to the network architecture.

Re: Generics enabled by default in Go tip

#363

Post by pkolaczk »

jshen wrote: post #325
jagger27 wrote: post #324

Earlier quoted context omitted.

That example is essentially the most basic use of generics. There are much more complex examples that would support your argument better. What do you find confusing about that code?

I don’t find it confusing, but it is certainly more complex than a simple function call. I chose it because it is a basic usage of generics, to highlight that basic generics are more complex than basic function calls. A code base that makes heavy usage of generics takes more time to understand than one that doesn’t make heavy use of generics. The readability of go is what I love about it, amongst a few other things.

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?

Re: Generics enabled by default in Go tip

#364

Post by pjmlp »

c-cube wrote: post #360
pjmlp wrote: post #345

Earlier quoted context omitted.

Kind of, now that typeof is going to be part of the language, that coupled with the preprocessor, does allow exactly that. Although in typical C fashion is a bit of kludge.

"coupled with the preprocessor" is a bit of a cop-out :-). Do you have a concrete example of what typeof would enable? Like a basic implementation of a vector type?

True, it is basically //go: generate, before Go was born.

Here is an example, https://codereview.stackexchange.com/questions/101816/generi...

Re: Generics enabled by default in Go tip

#365

Post by pjmlp »

amw-zero wrote: post #354
pjmlp wrote: post #316

Earlier quoted context omitted.

It isn't as if previous languages did not used code generators before generics were a thing on them.

Yea but, it has never been a particularly popular approach.

It surely was in C, C++ and Java.

Borland BIDS 1.0 used such approach with pre-processor tricks, similar to many C projects do as well.

Java, well EMF was a common tool to generate such boilerplate, Velocity was another one.

Re: Generics enabled by default in Go tip

#366

Post by jshen »

pkolaczk wrote: post #363
jshen wrote: post #325

Earlier quoted context omitted.

I don’t find it confusing, but it is certainly more complex than a simple function call. I chose it because it is a basic usage of generics, to highlight that basic generics are more complex than basic function calls. A code base that makes heavy usage of generics takes more time to understand than one that doesn’t make heavy use of generics. The readability of go is what I love about it, amongst a few other things.

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.

Re: Generics enabled by default in Go tip

#367

Post by pharmakom »

zarzavat wrote: post #266
_ph_ wrote: post #250

I like Go very much, a huge role plays its simplicity. In my career, I have been much more often bitten by having to deal with the complexity of a language then by not being able to do things, because a language feature is missing. That is, why I like Go so much. It strikes a great balance between important high-level features (GC, first class functions and closures) and still being a simple language (like Scheme is,…

I used to really hate Go's attitude to generics and type system features in general. I still do, but I appreciate that it's a matter of taste, and that different people have different tolerances for language complexity. People who like simplicity can use Go and people who like type systems can use Rust.

Weird to think of Rust as an alternative to Go imo. C# and Java are more similar to Go (mostly due to GC), but with generics etc

Re: Generics enabled by default in Go tip

#368

Post by pharmakom »

peter_l_downs wrote: post #4

Super excited for this. If you haven't checked out the latest proposal, here's an example of what Option/Result box types might look like (obviously not ready for release, just an experiment): https://go2goplay.golang.org/p/krvTH1_7lwX

Without language constructs for avoiding the pyramid of doom (e.g. Haskell do-notation) I think this will end badly!

Re: Generics enabled by default in Go tip

#369

Post by chrismarlow9 »

dolni wrote: post #362
scns wrote: post #347

Earlier quoted context omitted.

Where did parent mention microservices? NSI (No Snark Intended). (edit) A parody about those: https://www.youtube.com/watch?v=y8OnoxKotPQ

I gathered the bit about microservices from > I try to extend the simplicity of golang all the way to the network architecture.

That's a fair take from my words but it wasn't the intent. Really I just meant stick with consistent hashing, queues and the like. I guess really the "leverage existing tools and patterns" would have covered it sufficiently. I'm by no means a micro service fan. It reminds me of people abusing containers the way people abused the nosql movement. It has its place. I think we agree at the end of the day, and it's difficult to put into words.

Re: Generics enabled by default in Go tip

#370

Post by mypalmike »

hyperman1 wrote: post #235
mypalmike wrote: post #214

Earlier quoted context omitted.

With Java, I didn't find it to be either a huge win or a major loss. And I still don't. It's basically window dressing that lets you avoid casts in certain obvious places where they weren't particularly problematic anyhow.

It's more than window dressing. A year ago I added correct generics to about 50 000 lines of Java, an old module in a bigger program. The change was mostly mechanical, removing casts and adding signatures. I found a few places where refactoring had left behind a wrong type cast. Production logs demonstrated actual crashes corresponding to these cast. There were bugs in the issue tracker, marked unresolvable.

Interesting, I'd never encountered such bugs, but it makes sense
Post reply on HN