I chuckled at the juxtaposition of the “expressivity and clarity” comment:

>> you can create composite types (types out of types). This lets you get a lot of expressivity and clarity about how you use Go

Followed by long winded code:

>> However, we can make this a lot more complicated with the power of the Thunk[T] type

And confusion:

>> Why is this so much slower?

This article touches on a lot of the frustration i see with abuse of static typing.

You’re going to write more code and take longer to write it and longer to change it (read: you’re going to cost me more money to build and maintain this code), for the unproven claim that you’ll write less bugs.

The author then goes on to write a logic bug in their memoization code.

But only after they’ve created a generic MPMC queue type by taking an already generic MPMC queue type (a go channel) then writing logic that breaks it (can’t handle an empty queue state) which they code their way out of by throwing more code i have to own.