All the usual suspects, error handling, sum types, interfaces.
Just a note, I'm yet to see a problem highlighted in the section about interfaces, in particular that changing a concrete type will make it not fit the interface anymore which will result in troubles. It's often used as a tool to make the changes (e.g. change the interface, observe the compilation failure and fix all the occurrences). They way interfaces are usually defined on site as a minimal possible signature - if your code just needs one method, you define a narrow interface and that's it. That also makes it impossible to predict what kind of interface is needed at producer side.
If the argument is that you can fit a wrong struct into the interface, then again, I'm yet to see a real life manifestation of this problem.
Every library is a liability especially in terms of api. There are many example where the first take on a problem within a std lib was a bad choice and required a major overhaul. Once something is in standard library it’s literally impossible to take it back without breaking the world if you don’t control api consumers
I think this post needs better examples to show case the issue, because right now the issue is not clear. Ideally you would need an example that uses the context.Cause function, see below
The contexts and errors communicate information in different directions. Errors let upstream function know what happened within the call, context lets downstream functions know what happened elsewhere in the system. As a consequence there isn't much point to cancel the context and return the error right away if there isn't anybody else listening to it.
Also, context can be chained by definition. If you need to be able to cancel the context with a cause or cancel it with a timeout, you can just make two context and use them.
> For many business apps, they will never reach 2 billion unique values per table, so this will be adequate for their entire life. I’ve also recommended always using bigint/int8 in other contexts.
I'm sure every dba has a war story that starts with similar decision in the past
The other reason is the volume of the code being produced combined with the constant product changes. An innocent change like mixing two close but still different concepts can easily poison the whole codebase and take years to undo and may even be nearly impossible to fix if it propagates to external systems outside of direct control
Just a note, I'm yet to see a problem highlighted in the section about interfaces, in particular that changing a concrete type will make it not fit the interface anymore which will result in troubles. It's often used as a tool to make the changes (e.g. change the interface, observe the compilation failure and fix all the occurrences). They way interfaces are usually defined on site as a minimal possible signature - if your code just needs one method, you define a narrow interface and that's it. That also makes it impossible to predict what kind of interface is needed at producer side.
If the argument is that you can fit a wrong struct into the interface, then again, I'm yet to see a real life manifestation of this problem.