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

251–260 of 378 posts

Re: Generics enabled by default in Go tip

#251

Post by Taek »

tengbretson wrote: post #31
Taek wrote: post #21

Earlier quoted context omitted.

Find a different way to solve the problem. I've written close to half a million lines of code in Go and the lack of generics has been a pain point in maybe 1% of that? Usually, if you are thinking about generics you are reaching for abstraction when you don't need to be. If you really need generic structures you can use the interface type but generally there's a simpler solution that doesn't require generics.

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 engineers not to be clever. Write boring code that is obviously correct, and don't worry if your boring code is 25 lines when the elegant code is 8. It takes you longer to write the elegant code, and it takes the reviewer longer to read it, and often times (though not always ) it's also more difficult to test.

I love Go because of how boring and consistent and easy to read it is. The language and the task of "programming" melt away and instead you get to focus on solving problems.

Re: Generics enabled by default in Go tip

#252

Post by 4ad »

pkulak wrote: post #150
lokedhs wrote: post #73

Earlier quoted context omitted.

Back when generics were introduced to Java I felt the same thing. I had been doing Java for years at that time. I had also been working for Sun, so of course I was exposed to it. I was very negative towards generics and had similar arguments as you. It didn't take long before I changed my mind. I'd never want to write Java without generics again. I'm not saying you're going to have the same experience, but I would su…

Does Go generics have type erasure? If not, OP can expect and even better journey.

There are two meanings of "type erasure". One concerns the user, the other the compiler writer.

When most users people ask about type erasure, they ask whether types are erased when compiling the reflection information for polymorphic values (like Java does). Go doesn't have polymorphic values, so the question doesn't apply.

Type erasure means something more general than that to compiler people. Type erasure refers to whether you can compile code while erasing its type, and it's generally a useful property. In general statically-typed programming languages are implemented with type erasure, while dynamically-typed languages are not. Of course, since Go has reflection, it can't do type erasure. Interfaces also conflict with type erasure somewhat, though as expected, during the code generation types are erased as much as possible.

As a comparison, Rust does type erasure fully.

Re: Generics enabled by default in Go tip

#253

Post by Taek »

fiddlerwoaroof wrote: post #63
jshen wrote: post #45

Earlier quoted context omitted.

And it would have been far harder to read for those new to the generic code base. Complex abstractions make people feel smart, they rarely make code easier to understand or maintain.

Optimizing for people that are new to a codebase seems like a mistake to me: onboarding costs are relatively minimal and finite (per developer) whereas maintenance costs have no fixed bound: if generics let you exclude invalid states by design (and they do: this is one of the biggest advantages of parametric polymorphism vs. interfaces), they will be useful for keeping maintenance costs under control.

You definitely want to optimize for people who are new to a codebase. Over enough time, the codebase grows to a point where essentially _everyone_ is new to each area of the code, because nobody has touched that code in 2-3 years and the person who wrote it may not even be with the project anymore.

Even for your own single-person projects - if you get fancy with the code, 6 months later you find it's a lot harder to get back into and mess around with than if you had written the code as though you were presenting it to a beginner.

Re: Generics enabled by default in Go tip

#254

Post by 4ad »

jolux wrote: post #96
tptacek wrote: post #83

Earlier quoted context omitted.

Sure, that's true, and it's fine. There are people who find s-expressions both liberating and clarifying, and others who get lost in a sea of parentheses. And there are problems that are especially amenable to s-expressions, or generics, or fine-grained control of memory allocation, or interwoven code and markup, object hierarchies, and those problems sort of "ask" for particular languages. But for the most part, thi…

There are certain things that just can’t be done without generics, though. Type safe higher order functions, type safe custom collections, etc. Of course, perhaps these are all just subjective to you, because you can still write any program you need without them. But not having this feature does constrain the set of type-safe programs you can write quite a bit.

You can absolutely write type-safe higher order functions without generics. You can't write generic higher order functions, but that's a tautology.

Also higher-order functions are a moot point. Higher-order functions give you convenience, but no increase in expressive power (defunctionalization is an homomorphism).

Of course, generics give you a true increase in power.

Re: Generics enabled by default in Go tip

#255

Post by Taek »

h4x0r12345 wrote: post #119
jshen wrote: post #64

Earlier quoted context omitted.

They are complex. I’m guessing you haven’t thought about them much beyond the trivial use cases.

No, it's relative. For the top 5% - 10% of developers, generics are a useful tool for doing their job efficiently. For the bottom 50% of developers, generics are complex and confusing, and only provides more footguns.

And the top 1% of developers know that you are most productive when you stick to the simplest primitives ;)

I jest, but I also don't. All the best developers I know strongly prefer footgun-free libraries and primitives. The advantage is that you don't _need_ to spend brain cycles checking and double checking that it was written correctly, and when you want to make changes you don't need unwind an elaborate abstraction to stretch it further.

In martial arts (I'm a second degree black belt), the third move you learn is the round house kick (turned leg kick - the first two moves are the punch and the straight leg kick). At the olympic level, 70% of all points are scored using a roundhouse kick.

The other funny thing about the roundhouse kick is how much you can learn from watching someone do a single one. You can tell the difference between someone with 2 years of experience and 3 years of experience, and you can _also_ tell the difference between someone with 15 years of experience and 20 years of experience.

The point of this story being that masters are masters not because they can do elaborate techniques, but because their command over the simplest techniques is superlative.

I've found in life that this applies to pretty much everything. Martial arts, programming, painting, cooking, and effectively any task that definitively has some people who are better than others.

Re: Generics enabled by default in Go tip

#256

Post by [deleted] »

4ad wrote: post #254
jolux wrote: post #96

Earlier quoted context omitted.

There are certain things that just can’t be done without generics, though. Type safe higher order functions, type safe custom collections, etc. Of course, perhaps these are all just subjective to you, because you can still write any program you need without them. But not having this feature does constrain the set of type-safe programs you can write quite a bit.

You can absolutely write type-safe higher order functions without generics. You can't write generic higher order functions, but that's a tautology. Also higher-order functions are a moot point. Higher-order functions give you convenience, but no increase in expressive power (defunctionalization is an homomorphism). Of course, generics give you a true increase in power.

[deleted]

Re: Generics enabled by default in Go tip

#257

Post by xigoi »

iainmerrick wrote: post #237
SideburnsOfDoom wrote: post #219

Earlier quoted context omitted.

> Go adds generics. HN thread: I don't want this If generics are a good idea for a language, then it's better to add them in version 0.01 of the language and build up from there with generics as an intrinsic part of the language and standard libraries. No, I don't want _tacked on_ generics. Generics are not in 2021 a "bleeding edge" feature, that _might_ be useful later. They are established and proven in ways that t…

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.

> What languages in your opinion have good, non-tacked-on generics?

ML and its derivatives, Haskell, Rust, Nim.

Re: Generics enabled by default in Go tip

#258

Post by Taek »

jrockway wrote: post #91
Taek wrote: post #26

Not excited about this feature, I guess we'll see how frequently it shows up in unwanted places. Generics in C++ really damage the readability of the code sometimes, maybe the go devs have found a better way. Very skeptical, but the go devs have given me plenty of pleasant surprises before, maybe we get another one here.

The key to readability is programming with readability in mind. Sure, languages play some part in that, but 90% of it is the programmer. Go is simple right now, and generics do complicate it, but even with the simplicity that Go has, people already make a giant mess of it. As soon as you get any advanced feature, people will abuse it -- colossal generic functions that take 5 interface{} arguments (but only ever opera…

The reason that people find Go to be so much more readable than anything else is because there's often only one way to do the thing you want. The entire language spec is like 2 pages long, and the standard library is relatively thin - generally there are not cases of two libraries that can be used to accomplish the same goal.

This has the general effect of making every piece of code familiar, because every piece of code is forced to use the same ideas to solve adjacent problems.

The foil to this is javascript, where you've got a bunch of different ways to set up functions and promises and async and threading and communications and error handling, etc. Javascript is a very flexible and high level language, but that also means everyone solves problems in their own unique way.

Re: Generics enabled by default in Go tip

#259

Post by 4ad »

continuational wrote: post #202
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

This seems somewhat strange to me (and I don't just mean hard on the eyes): func (o Option[T]) Unwrap() T How does Go know that T is a type parameter here, and not a concrete type named T?

Because it can only be a type parameter. There is no specialization. (TBH I think that's a mistake because if prevents a solution to the Expression Problem.)

Re: Generics enabled by default in Go tip

#260

Post by 4ad »

SPBS wrote: post #141
tapirl wrote: post #104

Earlier quoted context omitted.

Each Unwrap() call needs two OK() calls? Letting Unwrap return OK would be better? BTW, the readability is really not good as Go 1.

As it rightfully should. God forbid people start returning Result[T] types instead of (T, error) and splintering the ecosystem. Option types are pointless if you don't have exhaustive pattern matching to ensure correctness.

Go's type system is actually expressive enough to ensure exhaustiveness, although it's non-obvious and syntactically heavy and impractical. I am working on a paper that will explore this.
Post reply on HN