Thorsten Ball -- developer and author of "Writing An Interpreter In Go" and "Writing A Compiler In Go" -- shares his writing experiences and tips.
After years of blood sweat and hardwork i finnaly got hired today
My gf didn't car wouldn't even pick up my phones and just replied with a dry text
So i thought maybe you guys would like to know
discussion
Many times, when modeling a data structure for some business logic, I found myself thinking that it would be 10x easier if Go had sum types. One known proposal says that this is not such a priority problem, although the UX will improve many times, because if we strictly only need a few different types, we don’t have to resort to interfaces and think about how to implement them, plus we remove the overhead of dynamic dispatch. And it can simplify error handling a little, although this is debatable, since error is an interface, and moving to something else, like Result in Rust, would divide the community. And we’ve already crossed a red line where the interface keyword means not only method sets, but also type constraints, and interface also could hypothetically be used for sum types. Btw, sum types are implemented interestingly in Kotlin, where there are no traditional sum types, but there are sealed interfaces that basically do the same job
