7 ms·

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

by nexneo 12y ago

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

nostrademons 12y ago
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.
manu3000 12y ago
errcheck actually tries to give you what you get for free with a type system (if you have option types)
- NateDad 12y ago
  You and I have vastly different definitions of "free", I think.
WalterBright 12y ago
One of the goals of the D programming language is to render add-on tools like 'lint' and 'coverity' redundant.
iopq 12y ago
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 12y ago
  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_guide/flag-reference.html#id598783 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.

by nexneo 12y ago

nostrademons 12y ago

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.

manu3000 12y ago

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

NateDad 12y ago
You and I have vastly different definitions of "free", I think.

WalterBright 12y ago

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

iopq 12y ago

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 12y ago
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_guide/flag-reference.html#id598783 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.