[davelnewton]

I wouldn't classify those as "type problems" but rather "using types to solve problems". I have no issue with the claim that great type systems make some... ahem... types of problems go away, although it's often trading one type of complexity for another. My issue is with the claim that "long term development is intrinsically better with static typing".

[fghfghgfhfg]

The type system, at least more powerful ones, encode a lot of intention and more importantly, enforce it.

It might add some additional complexity in the first writing of the code, but in return you eliminate whole classes of problems forever. It's not just the initial writing that benefits (at some cost, admittedly), but all future changes won't have those problems either. In the case the types themselves need to change to account for expanded functionality or whatever, you again pay some cost in complexity, but in return every place the new type would cause problems you get a nice error.

The other thing to keep in mind is that whether or not these type are codified in the language they're there conceptually. Just because you have to write them down doesn't necessarily add complexity but is more like forced documentation that can be used to eliminate who classes of problems. It's difficult to see how this wouldn't intrinsically be better than so-called dynamic typing.

[Havvy]

If you're talking about a good type system, sure. The type system in Go is frankly terrible at describing the kinds of invariants and reuse we care about.

I'd dare say that diaylizer (Elixir's optional but easy to use type system) would lead to more maintainable code than Go's forced type system in the long run.

[davelnewton]

That more or less sums up my view on Go in a nutshell.

[jeremyjh]

A type problem is any problem that types can solve for you. People who are exposed to very limited type systems consider the range of type problems to be limited. Still it is true that most of these problems are solved quickly and caught with unit tests - no one thinks that simple type problems are the source of your production bugs. A good type system is mostly a productivity play for me; I develop a little faster and I refactor MUCH more quickly and with less effort.

[davelnewton]

I'm pretty familiar with actually-good type systems, and as I've attempted to say, they do eliminate certain classes of problems. They just don't happen to be the types of problems I struggle with or find major productivity-burners. YMMV.

Orthogonal to all this is that I'm underwhelmed by Go's type system :/ If I was going to shoot for a language whose type system really helped me (in the ways I need/want help) it wouldn't be Go. It's pretty slick for some things (aesthetics aside) though.