- Sets

- Trees/graphs

- Stacks/queues

- List-like data structures with different performance characteristics than slices

- Monadic data structures you find in functional languages, like Option (for dealing with the lack of a value), Either (one of two possible values), Future (basically either a success or an error, computed asynchronously), etc.

I’m sure we’ll see popular libraries providing all of the above, and more. Generics will make for a wider variety of programming styles in Go, which has downsides as well as upsides.

Go will likely get a bit more functional/declarative/high-level, a bit less imperative/procedural/low-level. It’s not about to become Haskell or Scala, but maybe a bit more like TypeScript or statically typed Python, a bit less like C.

Pre-generics, Go has been a very limited language. On the downside it’s verbose and error-prone, on the upside it’s very uniform. I think generics will make it less verbose and error-prone, but also less uniform - stylistic differences from programmer to programmer will be greater, similar to other high level languages.

Except that this kind of uniformity inherently tends to disappear in larger projects, to be replaced by increased complexity. Java was also designed to be a "simple" language, one trivially understandable by hordes of low-skilled code monkeys, and yet look at the added layers of complexity in many Java enterprise frameworks. More full-featured languages, when properly designed (especially, avoiding the feeping creaturitis of something like Scala), make it easier not harder to manage inherent complexity at a larger and larger scale of development. But Go is now basically stuck with its constrained feature set, and Go developers cannot easily avail themselves of these tools. This is why so many devs criticize this particular design goal; it's pretty much incoherent.

I've worked on really neat big Scala codebases and really terrible big Go codebases – a determined developer can make a mess regardless of language, and for some cases it's actually easier to end up in that place with Go than with a more expressive language with a more comprehensive stdlib. Go isn't well-equipped for a number of things, and if you have to do those a lot, generated code and workarounds like the pseudo-sets people build from maps really become liabilities.

From what I've seen as far as complex codebases are concerned, I'd say Go can be very readable for small-ish programs that lend themselves well to Go's opinionated standard library and way of doing things, but I'd definitely want to use something more expressive at scale or for anything that doesn't fit into Go's limitations well.

What I find interesting here is that Scala has the reputation of being a complex language, while its syntax and grammar are among the simplest and most straightforward there is: https://images.app.goo.gl/K1NTGUP4G9T6wfY48

I believe that this is what "scalable" means in the eyes of its creator: it offers very powerful abstractions to be adequate for mundane tasks (e.g. file-level scripting) up to complex systems and problem spaces.

Yes, as a consequence, people have created libraries and codebases with Scala that are inadequately complex and abstract for the problem at hand, but that's not something one should blame on the language but on the project/company culture. Same is true for any language: C++ templates can be abused in ludicrous ways, some of Java's design patterns make you wish inheritance would be forbidden, python's module imports potentially overwriting globals and other footguns.

No language can be dumbed-down so much that the resulting codebase becomes immune to some amount of "abstraction management", not go, not even python. Once this is understood and accepted, it becomes obvious that it's not worthy to castrate a language on the basis of "simplicity", because eventually this complexity will be warranted at a point in the future or for some aspect of the project.

I think the go designers did the right thing here, I don't think this will bring dramatic changes in how the language is used, and will actually help with "managing abstraction" where it's due.

Here's more on that: https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofL...

You can't dumb down a language and expect the complexity of the problem space to go away (developers will have to cope with it one way or another), and you can't expect the programming language alone to be the sole judge of what's an acceptable level of abstraction (or architects would have been made redundant by now).

- List

- Array

- Dictionary

- Set (map with empty value)

- Stack (easily emulated with list)

- Queue (channel)

Other than the ones mentioned before, the only ones I've ever used were a priority queue and sorted map (AVL-tree), and even those were rare. Other than these I used others that were so application-specific, that it made no sense to be generic. Based on this there's no strong case for why generics have to be in the language. Not hating, but I'm not convinced either way.

This takes up unnecessary space—use map[T]struct{} instead, which also explains to anyone reading the code that the value isn't used.

if myset[thing] { ... }

With a map[T]struct(), you end up with:

if _, ok := myset[thing]; ok { ... }

Sometimes, the saving in space is TOTALLY worth the extra verbosity. Sometimes, the slight clarity from "non-existent keys return the zero value" wins.

Using a "set's" value in an if statement doesn't make sense either, compared to

    if _, exists := something[item]; exists { ... }

As Rob said, "Clear is better than clever." https://www.youtube.com/watch?v=PAAkCSZUG1c&t=875s

I also don't want to be hunting down whoever creates a map[T]bool and doesn't leave a comment explaining it's a set ;)

Hopefully we won't have to worry about it for much longer regardless, since I imagine we'll be using proper sets (with methods) some point in the near future.

But, that's one of those "requires extensive documentation" (and ideally, wrapping in a custom type and provide methods for checking and manipulating the set(s)).

In either way, even with that type of data type underlying a set, I would (probably) provide a functional API to interact with it.

    m["x"] = foo()
    for k := range {
        // if foo returned false, this is buggy
    }

for k, v := range m { if v { } }

But it also allows you to use "if m[key] { ... }". It is literally a trade-off for what convenience you want. And in both cases, you should (probably) wrap an abstraction around the raw map.

> I wish I understood how people can say 'this will result in so much more weird boilerplate garbage code'

It's pretty simple: there's a lot of developers that misuse/shouldn't use generics.

Here's an article I found just casually browsing on Google that shows why this can turn out to be such a huge problem.

https://itnext.io/golang-1-18-generics-the-good-the-bad-the-...

What I don’t understand is why people insist on making Go like every other language that already does what that are looking for. You want a language with generics, purely functional blah blah blah, great there are tons of choices, use one of them. Why insist on reducing the diversity in language choice, and trade-offs?

Again I ask, why insist that go become the same as all the other languages when you can just use one of those? Why demand less diversity?

You have many many choices that work the way you want. Go use them, why try to dictate to us that we can't have the choice we want? We disagree about the value of these things, and their trade-offs. That's what diversity is for, you have languages that work your way. Why insist that one of the few that doesn't has become like all the others?

If your code did not use generics, it can continue to not use generics. If you did not interact with any libraries whose need for generics was apparent, you can continue to do that too and the libraries you were using aren't going anywhere.

But just because you don't interact with a problem doesn't mean it doesn't exist, and the problem has historically been solved with dynamic downcasting, code generation, or copy-pasting, all of which result in codebases far harder to read and understand than most other languages. For these problems, you are not trading off generic code vs simple code, you are trading off generic code vs incomprehensible code. It is great that you have never needed a tree-map instead of a hash-map, but many have.

Go's simplicity is in many ways it being the spiritual successor to C, and even C has generics nowadays because they are an enormous value add.

“ If your code did not use generics, it can continue to not use generics. If you did not interact with any libraries whose need for generics was apparent, you can continue to do that too and the libraries you were using aren't going anywhere.”

This shows a profound lack of understanding of software development at scale.

https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy

You're arguing a strawman. No one insists that Go become the same as all the other languages (which are themselves nowhere near the same as each other). People are just asking for generics.

C++, Java, C#, and Haskell all have generics and are still wildly different languages even with respect to their approach to generics.

Also quitting the job isn't always an option.

That is why some of us have to put up with languages that we rather not.

Even COBOL and Fortran keep up with modern times!

Yes, including generics.

The old ways of code generators are good enough.

You might have a different opinion, that's fine, you have tons of languages that work the way you want. That's what diversity is for. Yet so many of you want to remove that diversity for a reason that I don't understand. There is no science that has proved which of us is right, so the best option in my opinion is to let diversity flourish. I can't understand why you all are against that.

Go is open source, create your own fork without generics and lets see which version keeps going.

I'm hopeful that this implementation is hitting the sweat spot, and that the Go team won't chase the demands to make Go like many of the other languages. I think the biggest win for Go is not having class based inheritance. Fortunately, I haven't seen anyone demanding that.

The same is true for other features, like channels and goroutines.

But goroutines? I see much less abuse there. And they're so damn handy.

With generics, reading and reasoning about code becomes [even] more challenging.

Personally for me, at this juncture I'm finding that for new projects I might just as soon spring for Java or maybe even prefer it to Go. For the straightforward mvn-style dependency management, if nothing else.

It's all moot now, though. There's no going back, this puppy is cooked!

However contracting pays well, so I don't care.

You might want to reflect on your reasons for jumping ship because your tooling gained a new feature. Sound's rather irrational to me.

Avoiding updating to a new version of OSX that stabs you in the face is a reasonable thing to do, despite it being a new feature.

- noone is forcing you to use generics in your go programs.

- if you are running outdated OS because you don't like some UX change, you might as well consider changing OS.

Sounds like it's just me.

Solving them helps better solve the product and business "real-world" problems.

"I need a priority queue for X" isn't generic, and "I need a priority queue for Y" isn't generic either. But well if you're doing it a lot, would be nice to not just reproduce the same bugs over and over again, yeah?

Everyone's worried about Go turning into Java and I can't speak too much to the utility (I have written maybe 50 pages of go in my life) but anyone who uses Python's standard lib can point you to 10 different things that are nice to have bug-free versions of and that "just work" thanks to Python's "generics".

Where you split that process as a separate library you either decide to write or reuse - that becomes the problem to solve. A set implementation may be a problem to solve: https://github.com/deckarep/golang-set A btree may be a problem to solve: https://gitlab.com/cznic/b/-/tree/master/v2

If you do, you haven't understood the problem that you need to solve and you are reaching for things you don't need to use.

Instead, what is likely to happen is, a lot of problems that generics can be applied to, they more often will be, simply because the option is on the table, regardless of whether it really improves anything. Go taught me to stop worrying and trust the For loop, and now we’re probably going to have dozens of utility libraries with Map and Reduce routines that people will use for extremely simple loops that don’t need them, probably resulting in slower code that takes longer to compile that needs a slower and more complicated optimizer to make up for it. In my opinion, the antithesis of what makes Go great.

Not saying generics is all bad, or that reduce is bad, or anything like that. But once a programming language has a new way to do something, you can be damn well sure people will use it, often even to their own disadvantage. Go doesn’t have pattern matching control flow, so the best degree of soundness you can pull out of an Optional type is ugly visitor-pattern type interaction. And yet, I’m worried routines will superfluously return Optional types anyways, just because you can, even though it’s not really any better than just returning a type and a boolean.

And yes. Actual code that actually needs generics for real will benefit, undeniably. Data structure and generic algorithm implementations will benefit greatly. The ugly sort package can finally be cleaned up. That’s great. But, most Go programs simply aren’t suffering from a lack of basic generics. Operative words: most, and basic generics. Many programs simply don’t need any data structures other than a basic growable vector type and a basic hashtable, and Go has both and they are built-in and work generically. Yet the more complex problems that C++ templates and Rust generics solve will probably not be aided at all by Go generics, which are simply much more limited in scope.

And despite that, this is quite an increase in compiler complexity. I know many are thinking “how hard could it be? Tons of languages do it today”—but Go isn’t really like all of the other languages. The simpler compiler is a huge benefit to the compiler and the whole ecosystem. Arguably, Go’s simplicity enabled them to experiment with things that wouldn’t be very easy to do in other languages, with regards to its GC and threading model. They’ve got it figured out of course, but it really isn’t a simple walk in the park. Any single aspect has a lot going on:

https://github.com/golang/proposal/blob/master/design/generi...

My hope is that the relatively mature ecosystem of Go will somewhat encourage people to keep their code simple and use generics sparingly, but with such a major shift in the language it’s hard to imagine what is “idiomatic” won’t change over time. I feel Go’s brutalist simplicity is its strong point and that it will just be an inferior option if you try to write code in it like C++ or Rust.

Of course… we’ll see.

The problem you're describing already exists, there's no preventing it or getting rid of it, and generics are tame by comparison - at least they semantically mean exactly what the developer intended them to mean, don't come with non-obvious performance downsides, and don't clobber existing concepts like error handling.

As for optionals vs separate bools, love 'em or don't, but yes, there is a downside, which is in my view possibly Go's only regression from C: no longer being able to stick the function call in the if-statement directly without additional fanfare.

Now as for the rest. Generics don’t automatically make code slower. In fact, in some places, the practical effect should make code faster; for example, the sort package currently defeats escape analysis even though it shouldn’t, and a monomorphized version should not suffer that consequence. Also, obviously, the fact that it removes runtime dispatch will also lower overhead. I understand that.

However, generics DO have some consequences:

- Every part of the toolchain—the compiler, linters, etc.—needs to understand generics and handle them properly. This is a non-zero cost; generics-heavy code will have measurably slower compile times. Go compilation times are fast, and that’s a feature.

- Generics improve the ergonomics of certain patterns that are absolutely slower. It is totally possible for someone to write a “map” function today for every type they could ever want, but it’s not really practical, and since it forces you to just write the loop out anyway, it really begs the question why you would bother in most cases. With generics, it should be relatively easy, but without aggressive optimization, it will be less efficient than the simple For loop. The map call and closure would need to be inlined for the optimizer to be able to get back to the same point. Having to do this, again, will slow down compilation more.

Honestly, you’re right; it’s far from the end of the world. However, I am pessimistic because to me, it’s unclear the costs of generics will be outweighed by the benefits of generics, but once the cat is out of the bag, it’ll be hard to ever go back on it.

Personally, I believe there are other improvements that would’ve been more valuable to consider first, like, personally, sum types and basic pattern matching. Sum types feel like something that, while it would have costs, has a potential to benefit a wide variety of programs and make certain code less error prone in a way that I don’t expect generics to.

(I realize I’m replying ridiculous fast here, but I just happen to click over to Comments on the first minute. Dumb luck.)

Of course, I could just use Rust, but it’s much harder to make idiomatic Rust libraries than it is idiomatic Go libraries, and I think that fact stunts the ecosystem a bit.

Go may encourage you to use a map to an empty struct for a set, or a weird if statement syntax that contains a full statement instead of a more elegant looking match or for expression, but I find its little quirks to be manageable and without a terrible amount of consequence. Generics will probably bring some good, like the end of needing weird slice tricks, but I’m still concerned it won’t be overall worth it.

Who says this? There have been a lot of weird arguments surrounding Go and generics over the last decade, but I’ve never heard anything like this.