[em-bee]

depending on the definition of static and dynamic, go could arguably be described as static (personally, i prefer declarative, as static is generally defined as something that i understand to be true for C but not for go), but that still does not make it weak.

[antonvs]

I'm saying Go has a weak type system. This was apparently an intentional choice by the authors. Go doesn't even have sum types, which are an extremely basic, foundational feature of type systems. Even C had an equivalent in its union types.

"Weak type system" means that there are many restrictions on what constitutes a valid program that can't be expressed in Go, that can be expressed in languages with stronger type systems, like Rust, Haskell, or even Java and C#.

[em-bee]

ok, fair enough, what actually interests me is why in your opinion it is weak.

in my understanding, weak typing comes from values being interpreted differently or are silently converted based on how they are used. php taking strings with numeric values when used in a math operation is a form of weak typing.

if that is not what you mean then you are using a different definition for weak typing. that's ok, i don't want to argue about what is the right definition, but i am interested in the definition you are using.

[antonvs]

I was just using "weak" in the ordinary English sense, as in "not powerful". But you're right, that's confusing because of existing terminology.

I should have said that Go has a less expressive type system, i.e. the expressivity of its type system is weak.

It has no sum types, no algebraic data types, no real pattern matching, and limited generic constraints. And of course if we compare it to much more expressive type systems, which is a bit unfair because none of them are mainstream, it has no higher-kinded types, no dependent types, and no refinement types.

As for "true" weak typing, the idiomatic use of `any` (`interface{}`) in Go comes pretty close. While languages with more expressive type systems will often have some way to express that general concept, it's typically more constrained, more friendly to static checks, and less unsafe, because of the some of the other properties I mentioned, such as pattern matching where the compiler will warn you if you're not properly checking a value before unsafely accessing it.

The reason for my comment about Python and PHP is because to me, programming in Go feels little different in programming in those languages along with one of the bolted-on static checkers they have - you don't get anywhere close to the same level of static guarantee of correctness of programs. It's difficult to implement Yaron Minsky's adage "make invalid states unrepresentable" in Go's type system, and that's unfortunate.