[ComputerGuru]

I don't mean to disparage the article (quite the contrary, it's quite the eye opener if you're not accustomed to architecting your code in this fashion) but choosing go of all languages to mockup the ideas was a terrible choice. It's syntax and type system are really quite the red-headed stepchild and for anyone unfamiliar with its syntax, its incredibly hard to make heads or tails of.

(And I say this as someone that's at least passably familiar with go and have worked on/contributed to golang projects in the past.)

[rahilb]

As far as I can tell the article contains only erlang snippets directly quoted from the paper reviewed.

[preseinger]

I think you may be alone in this assessment. Go is uniquely easy to understand, due to its small set of keywords and lack of esoteric e.g. sigils.

[weatherlight]

Yeah, I had no idea how to read the Go code.

I'm also coming from a ruby/js/ocaml/elixir/erlang background.

[preseinger]

The Go code, in its entirety:

    type HasName interface { Name() string }
    
    func Greet(n HasName) { fmt.Printf("Hello %s!\n", n.Name()) }
    
    type Joe struct {}
    
    func (_ *Joe) Name() string { return "Joe" }
    
    type Mike struct {}
    
    func (_ *Mike) Name() string { return "Mike" }
    
    func main() {
            joe := &Joe{}
            mike := &Mike{}
            Greet(mike)
            Greet(joe)
    }

You have no idea how to read this?

[weatherlight]

Yeah sorry, I had to drop it in chatgpt3 to explain it to me.

It’s like some sort of weird pseudo object oriented code.

The * and := are completely foreign. The string interpolation is weird.

Not sure what or why the &.

At the end of the day, if you went to college and learned programming, CS with Java or C, maybe this make sense.

I learned CS with Scheme, and OCaml… so your mileage may vary.