A Proposal for Adding Generics to Go

Post by majewsky » Tue, Jan 12, 2021, 9:27 PM UTC

jrockway wrote: post #122

joshlemer wrote: post #62

Earlier quoted context omitted.

I thought the idomatic approach was to represent sets with map[key]bool

A map[T]bool has 3 states for every key; absent, true, and false. A map[t]struct{} has 2 states for every key; absent, and present. People new to Go tend to pick map[T]bool or map[T]int because they're used to using bools and ints throughout their code, but struct{} is the correct value type for sets. (That is not to say that a counting set, map[T]int is useless, however. If you need that, use that!)

  if _, ok := wasTouched[thing]; !ok {
    touch(thing)
    wasTouched[thing] = struct{}{}
  }

  if !wasTouched[thing] {
    touch(thing)
    wasTouched[thing] = true
  }

Post by philosopher1234 » Tue, Jan 12, 2021, 9:28 PM UTC

Jtsummers wrote: post #106

RHSeeger wrote: post #66

Earlier quoted context omitted.

As someone who finds "indicating intent in the code" an important thing, I must admit I find this concert slightly horrifying. A Map and a Set are two different things and which one you use conveys some intent as to what you mean by your code. I get that it works, but it would still make me unhappy to do.

Ideally, if the language/standard library provides maps but not sets, and you wanted to use the idiomatic set = map of type -> bool approach, you'd create a wrapper so that intent is preserved but users don't have to know about the backing mechanism. Of course, it's obnoxious if everyone has to do this themselves and the language lacks generics so you have to write this once for each potential type.

Post by wtetzner » Tue, Jan 12, 2021, 9:31 PM UTC

tschellenbach wrote: post #11

We have a very large Go codebase here at Stream and not having generics is just not really as big of an issue as you think it is. There are plenty of work arounds if you get used to not having generics in the language. The fast compile times of Go are amazing. I was doing some Kotlin a few weeks ago and the difference is crazy. Go: Install deps, compile everything done in 5s. Doing the same in Kotlin, laptop freezes,…

Post by brundolf » Tue, Jan 12, 2021, 9:33 PM UTC

philosopher1234 wrote: post #193

brundolf wrote: post #182

Earlier quoted context omitted.

Right, and that's where the question gets muddy Though again, Go as a whole seems ill-suited for scaling to larger projects because of lots of other limitations on its type system, reliance on conventions, implicit-defaults, etc. Which makes it well-suited to (and often used for) things like microservices, where each actual codebase is smallish. Codebases like these will tend towards having less "library-like" code a…

Why do you say Go has trouble scaling to large code bases? Is that something you'd expect, or something borne out by the evidence? And if so, what is the evidence?

Post by coddle-hark » Tue, Jan 12, 2021, 9:36 PM UTC

brundolf wrote: post #187

coddle-hark wrote: post #185

Earlier quoted context omitted.

It's a real pain in the ass not having generics any time you're working with algorithms and data structures. Linked lists? Graphs? Trees? Go is generally quite nice to work with but it implementing these basic structures again and again with different underlying data types makes me feel like I'm writing Java. Which is ironic because, you know, Java has generics.

I think the idea is that these fundamentals could/should be supplied by the standard library Ironically, despite all their differences, Rust actually has a similar situation: it's really hard to write the fundamental data-structures in Rust, so they've put a focus on having really good standard-library implementations and people are generally content using those (in Rust's case it's because the borrow-checker makes p…