Generics enabled by default in Go tip • Hacker News Board

Re: Generics enabled by default in Go tip

#231

Post by R0b0t1 » Sat, Aug 21, 2021, 10:50 AM UTC

SideburnsOfDoom wrote: post #219

tedunangst wrote: post #34

Every HN thread about go: go is useless because it lacks generics. Go adds generics. HN thread: I don't want this. Good case study about the people drawn to comment on a topic.

> 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…

These don't seem tacked on. They spent so long on them specifically so they don't seem tacked on.

The issue with Go is if you're not shuffling around binary data it has horrible developer ergonomics. Network data is usually untyped, but if you start needing to care about what is in that data and need typed datastructures built around it you stop having fun quick. Same issue with C, really.

Re: Generics enabled by default in Go tip

#232

Post by masklinn » Sat, Aug 21, 2021, 10:57 AM UTC

takeda wrote: post #213

tptacek wrote: post #177

Earlier quoted context omitted.

I'm not sure I follow, because Rust is also (thankfully) fussy about integer types.

I don't have problem with being strong typed, I like that as well. The problem is that the stdlib doesn't really support other types and that's mostly due to lack of generics, so using uncommon types becomes quite annoying.

TBF the float Min/Max issue has nothing to do with generics, there isn't a "floating-point" generic class, and the entire reason why Go has an f64 Min/Max in the first place is that floats are not fully ordered[0], so you "can't" use regular comparisons (which you'd be told to do for integers) and thus you could not have a generic min/max relying on that even if there was one (e.g. in Rust `f32` and `f64` are not `Ord`, which `std::cmp::{min, max}` require, hence both `f32` and `f64` having their own inherent min/max methods).

So what your issue comes down to is Go's designers couldn't be arsed to duplicate the entire `math` package to also work on `float32`. Some members of the community did rise to the challenge[1] tho.

[0] well recent revisions of IEEE-754 have a total ordering predicate but I wouldn't say that it's really useful for such a situation as it positions NaNs on "outside" of the numbers, so a negative NaN is smaller than a negative number and a positive NaN larger than a positive number

[1] https://github.com/chewxy/math32

Re: Generics enabled by default in Go tip

#233

Post by theshrike79 » Sat, Aug 21, 2021, 11:10 AM UTC

takeda wrote: post #107

theshrike79 wrote: post #61

Earlier quoted context omitted.

You say "verbose and repetitive", I say "easy to read without any surprises". The verbose patterns (if err!= nil for example) make the code predictable to read, you notice the code smell of missing error handling really fast.

I think readability has multiple dimensions, and it really depends what you are looking for. For example here's a code in Go to look for a Prime: func IsPrime(n int) bool { if n It's readable as it is simple to understand what each line does. Here for example is a code that does the same thing in Rust: fn is_prime(n: u64) -> bool { match n { 0...1 => false, _ => !(2..n).any(|d| n % d == 0), } } It's might seem more c…

The difference here is that I can hand off the first code to any random freshly hired CS grad or cheapest outsourced coder and they can grok the code quickly. This is the advantage Go has to all other languages.

The Rust code needs maintenance coders of way higher caliber, not something you'd usually find. It's super fun for the top-tier developers who love to be expressive and concise with their code, but all code is pushed down to maintenance mode eventually when the hotshots move on to the new shiny project.

Go has removed pretty much every footgun by sticking to the basics. You have one way to do a loop, one way to do comparisons etc. There are very few ways to hide non-obvious functionality.

It _is_ possible to create complex programs, that are hard to follow but that's a larger design problem. Not something the language can force on developers.

Re: Generics enabled by default in Go tip

#234

Post by masklinn » Sat, Aug 21, 2021, 11:20 AM UTC

erik_seaberg wrote: post #225

masklinn wrote: post #218

Earlier quoted context omitted.

> I assume reflection will choose the one for the args you want to pass, or make you do that. According to the spec: > It's impossible for non-generic code to refer to generic code without instantiating it, so there is no reflection information for uninstantiated generic types or functions. You won't be able to reflect a generic List or List[T] at all which… makes sense, I think? `reflect` works on values at runtime,…

I was thinking of generic functions rather than (non-generic) methods on generic types. Unfortunately it looks like reflection can’t look up functions in a module at all , which is surprisingly broken.

> Unfortunately it looks like reflection can’t look up functions in a module at all, which is surprisingly broken.

The more time passes the more I think ubiquitous reflection in statically typed languages is what's broken (and a reflection (heh) of deep limitations of the language).

So while I could understand having issues with generics breaking existing reflection code (which doesn't seem to be the case), I'm not going to be sad over reflection having never supported toplevel functions in the first place.

Re: Generics enabled by default in Go tip

#235

Post by hyperman1 » Sat, Aug 21, 2021, 11:21 AM UTC

mypalmike wrote: post #214

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…

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.

Re: Generics enabled by default in Go tip

#236

Post by d33 » Sat, Aug 21, 2021, 11:35 AM UTC

3np wrote: post #2

Wow, it's happening! For others completely out of the loop on that there was even an accepted proposal that is now being implemented: https://go.dev/blog/generics-proposal

As an outsider planning to eventually learn Go, I have two questions:

1. what's "Go tip"?

2. does this allow us to approximate when it could make it to one of Go's stable releases? I guesstimate it's something that would land not sooner than within a year, right?

Re: Generics enabled by default in Go tip

#237

Post by iainmerrick » Sat, Aug 21, 2021, 11:36 AM UTC

SideburnsOfDoom wrote: post #219

tedunangst wrote: post #34

Every HN thread about go: go is useless because it lacks generics. Go adds generics. HN thread: I don't want this. Good case study about the people drawn to comment on a topic.

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

Re: Generics enabled by default in Go tip

#238

Post by hyperman1 » Sat, Aug 21, 2021, 11:41 AM UTC

anothernewdude wrote: post #158

tedunangst wrote: post #34

Every HN thread about go: go is useless because it lacks generics. Go adds generics. HN thread: I don't want this. Good case study about the people drawn to comment on a topic.

The people who cared about Go not having generics (myself included) moved on. The time for a well designed language with Generics was five years ago. The only people who care about Go now are the ones who convinced themselves that casting from empty interfaces was okay.

Yes and no. I dropped go after a short but tumultous love/hate relation, but decided to take a fresh look if generics had a decent answer. There's a lot to like about go. So I'll look back soon.

Re: Generics enabled by default in Go tip

#239

Post by Zababa » Sat, Aug 21, 2021, 11:50 AM UTC

smokey_circles wrote: post #187

Language flamewars on internet forums are... strange. Why have we all so strongly coupled our identities as programmers to the language we use? Sense of community and a perceived need to defend it? I don't think Go needs generics, but I'm not about to invent obscure edge cases to justify for/against the idea. That's a recurring theme in all defenses of any language. It's not helpful. Use Go if you like the "clarity",…

> Why have we all so strongly coupled our identities as programmers to the language we use?

Because the viability of a language is linked directly to its ecosystem and big names using it, so people that want to use one language have to promote its use if it's not in the top 5. You don't see many people advocating for Java, but some people are advocating for C#, Kotlin, Scala. You don't see many people advoating for JS, but many people are advocating for Elm, TypeScript, ReasonML.

On the other hand, people that are "forced" to use a language want to bring features from other languages they'd rather use. You can see in this graph https://go.dev/blog/survey2020/missing_features.svg (from https://go.dev/blog/survey2020-results) that people that want Go to change want to bring features from ML, Java, Rust, etc. Other languages. Because they have to work with Go or want to work with it but want to bring what they already know with them.

Lots of people spend 8 hours a day using the programming language that their company chose. Adding a few things that they like to it seem like a good way to make their life better.

Re: Generics enabled by default in Go tip

#240

Post by SergeAx » Sat, Aug 21, 2021, 11:56 AM UTC

tedunangst wrote: post #34

Every HN thread about go: go is useless because it lacks generics. Go adds generics. HN thread: I don't want this. Good case study about the people drawn to comment on a topic.

I am okay with generics as long as they are not affecting compile time. I love Go for blazing fast builds and testing and afraid generics will degrade it. Otherwise, generics are adding some cognitive complexity to code, but I don't have to use them and will just occasionaly have to figure them out in libraries.