Ian Lance Taylor: “Go intentionally has a weak type system, (…)”
Recently, Ian Lance Taylor, one of the most productive contributors to Go and, IIRC, the original author of gccgo, has written a very interesting comment on his view of the language:
(…) Go intentionally has a weak type system, and there are many restrictions that can be expressed in other languages but cannot be expressed in Go. Go in general encourages programming by writing code rather than programming by writing types. (…)
I found this distinction, writing code vs. writing types, very insightful. In my experience, in a language like Rust or (modern fancy) C++ the programmer is constantly forced to think about types, while when I program in Go or C, I almost never think about them. Types are, in fact, almost always obvious. It is also interesting that languages like Haskell and Idris explicitly expect the programmer to program with types.
What do you think?
I just read a really interesting article on type systems yesterday – What To Know Before Debating Type Systems. It expresses the opinion that types are fundamentally a way of asserting things about a program, and given that it is impossible to determine whether an arbitrary program has any given property, it compares dynamic and static types as a way to approach the goal of asserting that a program behaves as desired – static typing inevitably rejects some correct programs, whereas dynamic typing inevitably accepts some incorrect programs.
“What To Know…” is an amazing read. Thank you for sharing!
Interesting distinction indeed. In typescript I find myself thinking about types a lot iff I choose to. My code is intentionally veering towards very strong and strict typing. But I also know it's very optional to go that route and I've written a lot of typescript code where I don't think about types at all, especially with the excellent inference engine.
I think TS is by far the best languages regarding how to implement optional typing.
I had to learn and write a bit of Haskell for a Compuational Semantics class. It was uncomfortable because I am not well studied in algebraic type systems, so reasoning about my Haskell code took me a lot longer than than some of the mathier people in my class. But I did see some benefits of Haskell in that certain kinds of bugs were impossible, and programs were more proof-like than scripting languages. Basically, Haskell feels liking writing logical proofs, whereas Python can be written in a variety of ways. You can write very strict Python, and even use external type checkers or static analyzers. You can write Python in an object-oriented style. You can write Python in a procedural style. You can write Python in a functional style. But Python doesn’t feel opinionated. You can try to write Haskell in a variety of styles, but only if you have a very tight grasp of the type system, and if you try to veer too far from a functional style, the type system will drag you back.
I’m more productive writing Python because it is more flexible, but I realize that for some things, like constraint satisfaction problems or proof checking, Haskell does some things on behalf of the programmer that are worth the hassle of dealing with explicit types.