> I've noticed a lot of Rust lovers commenting about how great Rust's type system is. It probably is, but I haven't run into any problems with Go's type system.
I think it depends on the kind of things people write. Most people I see writing Go code seem to be writing programs, a piece of code that performs a specific function for a user. In those cases, you very often know exactly the domain types, and Go's type system is perfectly adequate there.
Other programmers write libraries, functionality that is meant to be used by other programmers to build their code upon. In this case, you rarely know the context in which a user of your library will use it, therefore you cannot really make any decision about types. This is a big reason why people like having parametric polymorphism.
The constant arguments that we see online probably comes from people writing programs and people writing libraries arguing with one another without understanding the context in which the other writes code.
> Other programmers write libraries, functionality that is meant
> to be used by other programmers to build their code upon.
> In this case, you rarely know the context in which a user of
> your library will use it, therefore you
> cannot really make any decision about types.
Uh ? Even for a library you certainly can make decisions about types, document them and enforce them. Who wants to accept unspecified data types ?
That doesn't mean no decision has been made: in a typed language with subtyping, this amounts to choose the "top" type of the type hierarchy, and without subtyping, you're choosing not to enforce structural constraints. In untyped languages with structured values (like any usable language), you make those decisions in the way your code checks for this or that value attribute or runtime structure. I guess unspecified and specified as "any" is often the same, but for me the former is a design mistake.
I think it depends on the kind of things people write. Most people I see writing Go code seem to be writing programs, a piece of code that performs a specific function for a user. In those cases, you very often know exactly the domain types, and Go's type system is perfectly adequate there.
Other programmers write libraries, functionality that is meant to be used by other programmers to build their code upon. In this case, you rarely know the context in which a user of your library will use it, therefore you cannot really make any decision about types. This is a big reason why people like having parametric polymorphism.
The constant arguments that we see online probably comes from people writing programs and people writing libraries arguing with one another without understanding the context in which the other writes code.