I personally found Go far more unproductive than Python - doing if err!=nil a zillion times and writing the nth for loop..it made me cry worse than cutting fresh onions.

Python is not Perfect (bad general-purpose performance), but IMHO honestly a more productive language than Go.

And Python has type hinting nowadays which is sweet when you want it. Type hinting is good for self-documenting stable code.

I never minded the boilerplate. Pushing buttons on a keyboard never slowed me down very much, especially compared to finding and fixing bugs or even writing gratuitous test cases to guard against type errors. If I could only press a few buttons per minute or if I could write many test cases per minute I might feel differently.

Go's err != nil has nothing to do with types though. It's just its own quirky convention.

Python could similarly declare that exceptions are only for dead-end panics, and all error handling should be done by returning 2-element tuples.

What kind of types are you dealing with that makes them so hard to keep track of? Are you talking about strings and integers, or a really really complicated objects and functions thing with functions of functions of functions and that kind of thing?

Honestly I find this question crazy. Have you never made an asynchronous data call returning an array of objects with properties that are complex types? You're already at Promise<Array<ComplexObject>>. What if you have to keep track of multiple of those calls at once in a data structure? Have you never used map or filter operations on streams of data? Do you really think functions returning functions is "really really complicated"? It makes me wonder whether you've ever actually worked on a moderately complex system.

> filter doesn't even change the types of its arguments

But map, which 90% is used after filter, does.

  const foo = client.someRequest()
    .filter(item => /* some condition */)
    .map(item => /* some transformation */)

  someFunction(foo)

Without a strong type system, how do you ensure "someFunction" is called with the correct data structure ?

The answer is either:

  - you implement your own type system (based on json schema?)
  - you write the type checks manually in your tests

With a strong type system, it is already done by the compiler.

Every REST/GraphQL APIs relies on a strongly typed schema.

A type system in your programming language is a feature that allows you to "encode" the schema within the language itself.

The most expressive the type system is, the less validation code you need. The less code you have, the easier it is to maintain your code.

You don't like the verbosity? That's what type inference is for, take a look at that Typescript example:

  const handlers = {
    foo: () => { /* ... */ },
    bar: () => { /* ... */ }
  }
  const action: keyof typeof handlers = someOtherFunc()
  handlers[action]()

If your function returns just a string, Typescript would scream at you. If your function return type is ('foo' | 'bar'), then you ensure that handlers[action] will never be undefined, without writing an if/else/throw block.

Strings and integers are rarely just strings and integers. For example, is this "integer" an order ID or a customer ID? Without a type system to tell them apart, mixing them up is a bug waiting to happen.

Today I was refactoring a codebase I maintain.

In one domain the program thinks of time in 1/256ths second ticks. And in another it thinks in terms of 1/32768ths of a second. Elsewhere it thinks in terms of ms.

Having them all represented as an int is often confusing. For me that wrote the code. God help anyone else.

If there is a practical reason you aren't using a uniform format for time I would consider this a case where compile-time type validation make sense... but for most applications I work on I would argue this is not a concern.

Well, sometimes you get really crazy types, like large implicit unions where many of the variants are dictionaries with specific structures or a class that has an attribute created dynamically. Or when some API says it wants a “file-like object”, does it mean “object with read() method”? Or read() + close()? What about seek()? Etc. But the spirit of my comment was about making sure that the types align—that I’m correctly passing the right kind of data into some function for every function. It’s easy to make type errors, and I know it’s not just me because type errors of various kinds were the number one kind of error in our production logs at our Python shop even though we had high unit test coverage.

Usually it's just many small uncomplicated structs.