I did get your scope, but I don't agree with it. I've written web applications (with database hooks, obviously) in both statically typed and dynamically typed l

I did get your scope, but I don't agree with it. I've written web applications (with database hooks, obviously) in both statically typed and dynamically typed languages. Defining the return types from your DB lookups takes only a few seconds of additional mental overhead than dynamic languages do. But that cost does have additional benefits that can save time debugging. So in the grand scheme of things, there really isn't much between ones productivity dynamic and typed languages (assuming someone of equal proficiency in both paradigms) I will grant you that Go does get a little more awkward if you're dealing with null data types in the database as you then need to start casting interfaces. Which gets a pain real quick. But it's rare that you actually need null types in the database - usually that requirement can be circumvented at the database design level (eg using default values in the table design or defining flag fields). Sometimes a different language will require you to architect your platform a little differently, but that's kind of the point of having different tools.