blog/we-have-go-2: write generics section

Signed-off-by: Xe Iaso <me@christine.website>

blog/we-have-go-2.markdown

@@ -89,6 +89,21 @@ nonzero amount of work. The bootstrapping can be made simpler with
 compatible with the semantics and user experience of the Go compiler that
 Google makes.
 
+Another key thing porting the compiler to Go unlocks is the ability to compile
+Go packages in parallel. Back when the compiler was written in C, the main point
+of parallelism was the fact that each Go package was compiled in parallel. This
+lead to people splitting up bigger packages into smaller sub-packages in order
+to speedhack the compiler. Having the compiler be written in Go means that the
+compiler can take advantage of Go features like its dead-simple concurrency
+primitives to spread the load out across all the cores on the machine.
+
+<xeblog-conv name="Mara" mood="hacker">The Go compiler is fast sure, but
+over a certain point having each package be compiled in a single-threaded manner
+adds up and can make build times slow. This was a lot worse when things like the
+AWS, GCP and Kubernetes client libraries had everything in one big package.
+Building those packages could take minutes, which is very long in Go
+time.</xeblog-conv>
+
 ## Go Modules
 
 In Go's dependency model, you have a folder that contains all your Go code
@@ -724,9 +739,7 @@ missing the brutal simplicity of Go interfaces in other languages like Rust.
 In Go 1.18, support for adding types as parameters to other types was added.
 This allows you to define constraints on what types are accepted by a function,
 so that you can reuse the same logic for multiple different kinds of underlying
-types or write collections that deal with values of a given type that meets an
-interface without also having to make sure that everything else in that
-collection is of the same type at runtime.
+types.
 
 That `doSomething` function from above could be rewritten like this with
 generics:
@@ -739,21 +752,89 @@ func doSomething[T Quacker](qs []T) {
 }
 ```
 
-We can totally refactor out the error return and any of that runtime fallible
-code. This allows us to express constraints at _compile time_ so that
-attempting to mix `Duck`s and `Sheep` in the same argument to `doSomething`
-will fail to build. 
+However this doesn't currently let you avoid mixing types of `Quacker`s at
+compile time like I assumed while I was writing the first version of this
+article. This does however let you write code like this:
 
-- [ ] Overview of some of the types of collections it lets you make
-- [ ] This is a huge improvement to the language
+```go
+doSomething([]Duck{{}, {}, {}})
+doSomething([]Sheep{{}, {}, {}})
+```
+
+And then this will reject anything that _is not a `Quacker`_ at compile time:
+
+```go
+doSomething([]string{"hi there this won't work"})
+```
+
+```
+./prog.go:20:13: string does not implement Quacker (missing Quack method)
+```
+
+### Unions
+
+This also lets you create untagged union types, or types that can be a range of
+other types. These are typically useful when writing parsers or other similar
+things.
+
+<xeblog-conv name="Numa" mood="delet">It's frankly kind of fascinating that
+something made by Google would even let you _think_ about the word "union" when
+using it.</xeblog-conv>
+
+Here's an example of a union type of several different kinds of values that you
+could realistically see in a parser for a language like [LOLCODE](http://www.lolcode.org/):
+
+```go
+// Value can hold any LOLCODE value as defined by the LOLCODE 1.2 spec[1].
+//
+// [1]: https://github.com/justinmeza/lolcode-spec/blob/master/v1.2/lolcode-spec-v1.2.md#types
+type Value interface {
+  int64    // NUMBR
+  float64  // NUMBAR
+  string   // YARN
+  bool     // TROOF
+  struct{} // NOOB
+}
+```
+
+This is similar to making something like an
+[`enum`](https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html) in Rust,
+except that there isn't any tag for what the data could be. You still have to do
+a type-assertion over every value it _could_ be, but you can do it with only the
+subset of values listed in the interface vs any possible type ever made. This
+makes it easier to constrain what values can be so you can focus more on your
+parsing code and less on defensively programming around variable types.
+
+This adds up to a huge improvement to the language, making things that were
+previously very tedious and difficult very easy. You can make your own
+generic collections (such as a B-Tree) and take advantages of packages like
+[`golang.org/x/exp/slices`](https://pkg.go.dev/golang.org/x/exp/slices) to avoid
+the repetition of having to define utility functions for every single type you
+use in a program.
+
+<xeblog-conv name="Cadey" mood="enby">I'm barely scratching the surface with
+generics here, please see the [type parameters proposal
+document](https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md)
+for a lot more information on how generics work. This is a well-written thing
+and I highly suggest reading this at least once before you try to use generics
+in your Go code. I've been watching this all develop from afar and I'm very
+happy with what we have so far (the only things I'd want would be a bit more
+ability to be precise about what you are allowing with slices and maps as
+function arguments).</xeblog-conv>
 
 ---
 
-We already have Go 2. It’s just called Go 1.18 for some reason. It’s got so many
-improvements and fundamental changes that I believe that this is already Go 2 in
-spirit. I, as some random person on the internet that is not associated with the
-Go team, think that if there was sufficient political will that they could
-probably label what we have as Go 2, but I don’t think that is going to happen
-any time soon. Until then, we still have a very great set of building blocks
-that allow you to make easy to maintain production quality services, and I don’t
-see that changing any time soon.
+In conclusion, I believe that we already have Go 2. It’s just called Go 1.18 for
+some reason. It’s got so many improvements and fundamental changes that I
+believe that this is already Go 2 in spirit. There are so many other things that
+I'm not covering here (mostly because this post is so long already) like
+fuzzing, RISC-V support, binary/octal/hexadecimal/imaginary number literals,
+WebAssembly support, so many garbage collector improvements and more. This has
+added up to make Go a fantastic choice for developing server-side applications.
+
+I, as some random person on the
+internet that is not associated with the Go team, think that if there was
+sufficient political will that they could probably label what we have as Go 2,
+but I don’t think that is going to happen any time soon. Until then, we still
+have a very great set of building blocks that allow you to make easy to maintain
+production quality services, and I don’t see that changing any time soon.