[iopq]

Consider the following:

it is actually more difficult to code in a language that's simple

Why? Because a more feature-complete language allows you to ELIMINATE the concept of `nil` through an `Option` type.

An `Option` type is an `enum` that consists of either `Some(x)` or `None`. That means it is always checked. You can never accidentally use a value that is `None` because the type checker would not let you use `Option<T>` instead of `T` itself.

The code snippets on the websites are far from simple. You HAVE TO remember to do `if err != nil` in every single function. A more advanced type system would actually make this a requirement.

So what is more important, the simplicity of the language or lack of bugs?

[nexneo]

Go depends on tools to check correctness that type system doesn't cover. Check, http://blog.golang.org/error-handling-and-go and https://github.com/kisielk/errcheck

[nostrademons]

Isn't this just layering another, non-standard type system on top of the language itself? After all, a type system is no more than a tool to check the correctness of programs. (And often, document the assumptions that the programmer made.)

I don't think this is a bad thing in and of itself - I like how languages like Python, Lisp, Javascript, and Erlang have been able to layer typesystems on top without building them into the language itself. But I wouldn't exactly hold it up as an example of simplicity, particularly since in those languages the community hasn't agreed on any one type system.

[iopq]

That's the answer for everything in the Go community. More ad-hoc tools to replace the type system. Have concurrency bugs? Use a tool that detects some types of data races. Have problems with errors? Have a tool that detects not checking for errors.

How is approaching every single problem with a different tool more simple than using the type system as the one tool for static checking? The Go ecosystem is creating a ad-hoc, informally-specified, bug-ridden, slow implementation of half of the type checker of Haskell.

[pacala]

The jury is out on whether, for large time frames and for large communities, having a centralized type system is better than having a decentralized set of independent tools.

I'm not very excited by GHC's model of language extensions, https://downloads.haskell.org/~ghc/6.12.2/docs/html/users_gu.... And in spite of the large number of Haskell extensions, there are still pragmatic niches that aren't covered, see for example Rust's encoding of memory management in the type system.

In a sense, GHC contains a ad-hoc, informally-specified, bug-ridden, slow implementation of half of the type checker of Coq ;) Which is to say that there are many flavors of sophisticated type systems, and it's not clear which flavor is most conducive for writing good software on a tight time budget.

[WalterBright]

One of the goals of the D programming language is to render add-on tools like 'lint' and 'coverity' redundant.

[manu3000]

errcheck actually tries to give you what you get for free with a type system (if you have option types)

[NateDad]

You and I have vastly different definitions of "free", I think.

[panic]

Exactly. If simplicity were the most important thing, we'd all be writing code in Forth or some sort of macro assembler.

[WalterBright]

It's true that assembler is actually pretty simple. It's just that the simple instructions combine in hard to understand ways.

[xorcist]

You could have said Lisp instead, and it's not hard to find people making that case.

It's a tradeoff between designing your own complex building blocks or having very complex tools with thousands of them ready-made.

I won't pretend to have an easy answer, but I do know I personally prefer when people err on the side of simpler tools.