Go's type system is "strong," as far as that goes. In comparison to OCaml and Haskell, Go's type system is less expressive. That is, OCaml and Haskell will let you express more invariants in the type system more easily.
The point of a type system is to make it easier to reason about your programs, so a type system like C's, where almost all of the types are size specifications, like the difference between short and int and long, is almost orthogonal to the purpose of having a type system in the first place: It doesn't matter if someone's height in centimeters is an int or a long, it matters that it can't be added to their age in days, and if someone tries it, the compiler catches it and alerts the programmer to nonsense in the codebase.
Being able to represent both their height in centimeters and their age in days in a 32-bit integer is pointless trivia unless you're designing a bits-on-the-wire network protocol specification, or interfacing with hardware registers, or designing a binary file format, in which case C's type system still doesn't give you enough information, because endianness is not specified.
Object systems are an attempt at solving the "Foogols don't have real type systems" problem, but they drag in notions of hierarchy which don't always fit outside of toy problems, and not even then. Plus, Smalltalk-style object systems which mandate that everything must work via message-passing drags in even more complexity orthogonal to the idea of finally having a semantic type system. And as long as there are still size specification pseduo-types, boxed or unboxed, the type system still has an inherent hole in it, because you can still say nonsense which type-checks perfectly cleanly.
So saying Go has a strong type system and comparing it to OCaml or Haskell is meaningless, because the two kinds of type systems (that is, real, semantic type systems versus size specifications) aren't trying to do the same thing.
Your entire comment seems to be about C. But you asked about Go. C's type system is classically considered "weak" and Go's is considered "strong." This isn't controversial, insomuch as "weak" and "strong" have meaning in the first place. C will perform some implicit conversions between types for you. Go won't. That's the difference that causes one to be considered weak and another to be considered strong.
Any two type systems can be meaningfully compared. My comparison was exceptionally broad and seems perfectly consistent with everything you said.
My point is, types which specify low-level details about data size and representation but not the semantics of which operations are actually sensible to use on them and which types can be meaningfully used together are not really types, in that they don't make programs any easier to read or write.
I also deny that autoconversion weakens a type system. For example, if you have a data type which holds a person's height, it is utterly uninteresting what units it's in most of the time, and it can save a lot of trouble if the runtime or compiler keeps track and converts automatically if you try to add a height currently being stored as inches to one currently being stored as centimeters, or adding centimeters to fractional centimeters rounded to the nearest millimeter, for example. There are any number of purely mechanical autoconversion tasks which can and should be done automatically and which don't change the type, in that they don't change which operations are valid for the value. And that autoconversion still wouldn't make adding height to age any more sensible, even if the two values were truly indistinguishable at the machine code level.
> the semantics of which operations are actually sensible to use on them and which types can be meaningfully used together
Go lets you do this just fine. I think it would help if you used concrete examples to demonstrate what you mean.
> I also deny that autoconversion weakens a type system.
Deny it all you want. I don't really care to get into a definitional war with you. The definitions I use are the ones that have a consensus backing them[1]:
> in general, a strongly typed language is more likely to generate an error or refuse to compile if the argument passed to a function does not closely match the expected type. On the other hand, a weakly typed language may produce unpredictable results or may perform implicit type conversion.
If you read that article, you'll see that most of it is about describing what the terms mean. There is no precise definition, and I've been careful to embrace that fact in my comments. Nevertheless, in common usage, the terms "strong" and "weak" in the context of type systems typically demarcate the prevalence of implicit autoconversions between types.
> And that autoconversion still wouldn't make adding height to age any more sensible, even if the two values were truly indistinguishable at the machine code level.
Weaker type systems permit this form of autoconversion. Notice that "strong" and "weak" are properties of the type system itself, and that they refer to implicit autoconversions between types. Autoconversions that occur because of appropriate polymorphism defined by users of the language is an orthogonal concept.
I think the bottom line is that you aren't using "strong" and "weak" as they are commonly used. If you want to make up your own definitions for them, then please just say that so that we can stop wasting time. (I have no problem with you coming up with your own definitions, I just want you to acknowledge that you're doing it.)
You didn't use a single concrete example. Please show some Go code that demonstrates your point.
> I also don't appreciate being downvoted for having a pleasant discussion relevant to the topic.
I didn't downvote you (I couldn't even if I wanted to, HN disallows it). But you have certainly not made this a pleasant conversation. Your comments aren't intelligible to me. I've asked for clarification and you haven't given it, which leads me to believe you aren't interested in a good conversation.
> Proof that the type system I'm talking about isn't weak
I never contested that.
> unlike the ones C and Go have.
The only claim I've made is that Go's type system is "strong." You have, not once, ever responded to this claim directly.
