Unfortunately the only way to get type errors statically right now is to run `hh_client` at the command line (see http://docs.hhvm.com/manual/en/install.hack.bootstrapping.ph...) -- this is what vim-hack will do for you. HHVM will only report type errors that it can see at runtime, which won't catch the edge cases or error cases you didn't think to test, which kind of defeats the purpose of having the static type system. For a really simple integration, you can do `watch hh_client` in a second window, which will run the checker every 3 seconds, configurable, see `man watch`.
This separation is different than many other languages, and lots of folks have found it confusing. It largely exists for technical reasons, and we should be able to have a better UX for end users; this is something I've been thinking a lot about and want to try to improve in the language going forward. (I work full-time on the Hack team.) Please do give it a shot and let us know how it goes!
Funny, I was in the IRC channel this evening having a chat to Simon and managed to work all this out! I'm actually quite excited by it, I think the type checking that's available + unit testing will catch most of the edge cases I was looking to catch, although that "doesn't check global scope" threw me for a bit when getting it all up and running!
I'm really interested to see what you end up coming up with UX wise. What sort of edge cases do you think the `hh_*` apps will miss? Running `hh_client` on save isn't a bad thing, IMO, and having it output JSON for easy integration is amazing :) But I'm curious what the type checker will miss currently?
Is there a public mailing list where these sorts of discussions happen or is it more internal to Facebook? I'm really interested in Hack (as is where I work, we push PHP to it's limits so we're keen to use something that can catch even more bugs from day 0) so thanks very much for pushing PHP even further forward!
Are the technical reasons for missing type errors that wouldn't be triggered at run-time insurmountable? Or is it more a "finding the right UX to expose it"?
It's not that the tyepchecker will miss things, it's that, for folks coming from other languages, it's not clear that there even exists a separate typechecker you have to run!
There isn't a mailing list right now. A few discussions are just in-person since we sit next to each other, but we're trying to make things as transparent as we can. Lots of stuff (and hopefully more moving forward) happen on #hhvm on Freenode or on GitHub issues -- basically the same channels as the HHVM project itself. There is also nontrivial discussion during code review, which is very unfortunately all internal right now; we hope to have that all moved external as soon as we can. (There are a lot of tricky integrations with internal tools that need to happen for that to work.)
This separation is different than many other languages, and lots of folks have found it confusing. It largely exists for technical reasons, and we should be able to have a better UX for end users; this is something I've been thinking a lot about and want to try to improve in the language going forward. (I work full-time on the Hack team.) Please do give it a shot and let us know how it goes!