from Hacker News

Crimes with Go Generics

by psxuaw on 4/25/22, 1:07 AM with 61 comments

  • by amscanne on 4/25/22, 4:35 AM

    If the author is reading, I believe the problem noted at the end is actually that the code isn’t going through the thunk API and thus no memoization occurs. (Consider that there is no call to Set in the evaluation tree!)

      fib = func(n int) int {
        if cache[n].o.IsSome() {
          return *cache[n].o.val
        }
        return fib(n-1) + fib(n-2)
      }
    
    Should be:

      fib = func(n int) int {
        return cache[n-1].Force() + cache[n-2].Force()
      }
  • by CraigJPerry on 4/25/22, 8:21 AM

    Crimes with Go Generics really is the perfect title for this article.

    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.

  • by reflexe on 4/25/22, 5:21 AM

    Maybe I am missing something here but as someone who is not an expert in go generics, I don't see any obvious "crimes" with the Option and Queue implementations.

    I also could not find where the author explains their "crimes".

    What I am missing here?

  • by svnpenn on 4/25/22, 4:47 PM

    I think author has gotten out of hand with the avatars. They now have three talking to each other. One was fine, but at this point it's just a distraction. Just write the article.
  • by BreakfastB0b on 4/25/22, 4:20 AM

    How long before someone figures out how to encode lightweight higher kinded types[1] in Golang. There shall be weeping and gnashing of teeth.

    [1] https://ybogomolov.me/01-higher-kinded-types/

  • by nirui on 4/25/22, 9:48 AM

    > Why is this so much slower?

    Just a side note: Go test supports benchmarking (https://dave.cheney.net/2013/06/30/how-to-write-benchmarks-i...) which gives you few useful tools such as `b.ReportAllocs()` and `go test -bench . -cpuprofile cpu.out -memprofile men.out`. These tools can give you far better information than just the execution time of a test case.

  • by nx7487 on 4/25/22, 5:42 AM

        Go 1.18 added generics to the language. This allows you to have your types take types as parameters so that you can create composite types (types out of types). This lets you get a lot of expressivity and clarity about how you use Go.
    
    Aren't structs already composite types?
  • by mrlonglong on 4/25/22, 5:21 PM

    Iain M. Banks once wrote this: "It's brains, not gonads that matters".
  • by Koiwai on 4/25/22, 7:45 AM

    The fibonacci should use an array/slice for storage instead of a map(hashmap).
  • by Kostarrr on 4/25/22, 6:44 AM

    I don’t think the Option presented here is sufficient (it is indeed a “crime”) as you cannot express Some(nil).

    But you could probably achieve that using go's not-well-known sum types, e.g. like this

    https://github.com/FSMaxB/type-safe-builder-experiment/blob/...

  • by RamblingCTO on 4/25/22, 1:22 PM

    The design isn't very reader-friendly to be honest. I really don't like the trend of terminal-inspired designs. Yeah, looks nice and nerdy, but isn't really useful for reading. Monospaced fonts aren't very good for running text as well.