commit c8b8fcd09d93760902a5795658774ad67bee2a0f
parent 193ce95f9e5f4d502cc49d479c4f3248c859c050
Author: Shimmy Xu <shimmy.xu@shimmy1996.com>
Date: Sat, 16 Jan 2021 21:18:03 -0600
Add hoots
Diffstat:
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/content/hoots/1610498227.en.md b/content/hoots/1610498227.en.md
@@ -0,0 +1,5 @@
++++
+date = 2021-01-12T18:37:07-06:00
+draft = false
++++
+twixter -> twoxter -> twixt3r -> twIVter -> twixter (in typical movie sequal naming fashion).+
\ No newline at end of file
diff --git a/content/hoots/1610849111.en.md b/content/hoots/1610849111.en.md
@@ -0,0 +1,10 @@
++++
+date = 2021-01-16T20:05:11-06:00
+draft = false
++++
+Reading through the [latest Go generic
+proposal](https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md), I felt ok at the beginning, but increasingly uneasy as I scroll along to find the long list of restrictions and edge cases. It's clear that the dev team is actually painstakingly trying to fit a generics implementation (almost exactly as people have asked for) into the language. Perhaps because Go seemed like such an opinionated language, I was not actually expecting such an serious attempt at all: I would have expected Go generics to simply involve a handful of special interface types from standard library that are somehow unboxed (have one less layer of pointer redirection) and we still write for-loops instead of map-reduces.
+
+It's one of those cases where I applaud the effort, but I'm not convinced that a suitable solution can be achieved (like *The Rise of Skywalker*). The proposed generics system eats into Go's originally quite orthogonal feature set and reading through all the caveats of how it would interact with other parts of Go already feels similar in length as the entire Go spec. On the other hand, generics and interface types obviously overlap in functionality and while there are restrictions in place to discourage a Go version of "almost always `auto`" from happening, having to think about which one to (not) use takes away some of Go's appeal for me.
+
+Ugh, this is such an arduous yet unrewarding path to go down. Maybe Go team's `.async` moment would eventually come and we would all love the solution, but then again, I really don't mind writing generics-free Go that much.