8 ms·
Engineer working on Hack here. Yeah, I think Hack is a good language to start a new project in. For as much flak as PHP gets, there are actually a lot of good
by jwatzman 13y ago
Engineer working on Hack here.
Yeah, I think Hack is a good language to start a new project in. For as much flak as PHP gets, there are actually a lot of good things about the language. The fast development cycle -- edit php script, refresh -- is something amazing that you don't get in a lot of statically typed languages, which usually have a compilation step. The crazy dynamic things you can do also occasionally have their place, though it's certainly easy to shoot yourself in the foot.
On the other hand, a lot of the time you want the safety that strong static typing can give you. Even just the null propagation checking can immediately find tons and tons of silly little bugs without even running the code, and ensure that the code stays consistent as a "mini unit test" if you will.
Hack hits the sweet spot of both. Wiring the Hack typechecker into vim was really revolutionary for me -- having both the immediate feedback of the type system for all the silly bugs that I was writing, along with the fast reload/test cycle from PHP, is great.
- copergi 13y ago>The fast development cycle -- edit php script, refresh -- is something amazing that you don't get in a lot of statically typed languages You seriously think that? That's how we do haskell web development. Both yesod and snap do this out of the box. That's how every java developer I know works.
- bos 13y agoI have a little bit by way of Haskell chops, and I'll venture that the performance of the Hack typechecker is a very big deal, and it is in a different breed than the turnaround time you get from snap or yesod (or Java).
- copergi 13y ago"Type checking is faster than other statically typed languages" is quite different from "other statically typed languages don't offer this workflow", which is what was claimed.
- jfischoff 13y agowhat makes it a different breed? Edit: I misread what you wrote. I thought you were saying there was something fundamentally different about the type checker, but more that reload experience is different then what you get with Yesod.
- maaaats 13y agoHow do you do it in java? Compile (takes time) -> hotswap (takes time), or can't hotswap since changes to signature, will need to restart server (takes lot of time).
- copergi 13y agohttp://docs.codehaus.org/display/JETTY/Maven+Jetty+Plugin http://docs.codehaus.org/display/JETTY/Maven+Jetty+Plugin
- maaaats 13y agoYeah, that's the one we're using. Still takes a couple of seconds, though. And as I said, big changes can't be reloaded, so the whole server will have to be restarted.
- copergi 13y ago>Still takes a couple of seconds, though How big is your code base, and is it all in one huge file or something? Our stuff is reloaded and ready before I've alt+tabbed back and hit refresh.
- eevee 13y agoEr, `paste serve --reload` restarts small-to-medium Python projects faster than I can alt-tab, which is actually faster than my static blog engine can regenerate itself too.
- eugenez 13y agoThe Facebook codebase is not exactly a small-to-medium project, so there is a fair bit of value in edit-and-reload.
- eevee 13y agoThe parent comment was about Hack's being good for a new project.
- strlen 13y agoIs there a statically typed variant of Python that would work with existing web servers, etc..? I am aware that there's Cython and I know that py3k technically permits type annotations (which Jetbrain's Python IDE uses quite effectively), but that isn't true static type checking in the same way as Hack does this.
- eevee 13y agoStatically-typed Python would ruin a great number of Python libraries you'd probably want to be using. It'd be a very different language. Once you have type annotations, it wouldn't be too much of a stretch to enforce them statically with a separate tool. You could even go as far as rejecting first-party code if you can't statically determine every single value's type. Pylint's underlying astroid library has a bunch of inference tools you could perhaps build on top of.
- strlen 13y agoSuch a tool would be no less difficult to build than hack itself, though. Hack's "gradual typing" solves the problem of re-using existing code that you've mentioned. FB already had a PyLint-like tool earlier that could do some static analysis, namely pfff (also open source and written in OCaml), but it did not provide a full-on static type system like Hack. (Background: I used pfff when I was in bootcamp at FB itself. This was however prior to hack, I worked solely on C++, Java, and a bit of Python at FB after bootcamp). I am sure if FB started off with Python, a similar solution could have been found, but if you're looking for a tool that exists _right_ now, Hack is actually quite decent. Creating a static type system, implement local type inference, as well as working out "gradual typing" and associated problems (all while being able to do type-checking at speeds developer _expect_) is not a trivial problem.
- hyp0 13y agoDo you know if other languages have static null checking i.e. your null annotation/propagation (apart from Haskell's Maybe union type etc)? I'm intrigued, because it's such a good idea (especially when null's originator claimed it was a "billion dollar mistake"), though Java doesn't have it. I'm wondering if there's some subtle problem with it...? Also, how do you make your vim typechecker fast enough? Usually, even syntax colouring is local to ensure adequate performance - and a typechecker with inference/propagation would be very non-local.
- wffurr 13y agoJava 8 adds this exact feature through extending annotation capability and adding hooks for pluggable type checkers, including a null propagation checker: http://docs.oracle.com/javase/tutorial/java/annotations/type_annotations.html http://docs.oracle.com/javase/tutorial/java/annotations/type... and an Optional<T> class (references to which can still be null for maximum hilarity): http://download.java.net/jdk8/docs/api/java/util/Optional.html http://download.java.net/jdk8/docs/api/java/util/Optional.ht... I'm stoked. And disappointed the "elvis" operator didn't make it in. I hope some day Java breaks backwards compatibility and eliminates null entirely. Then again, that's already happened with the proliferation of other JVM languages. But that doesn't me at my day job, where we have a large legacy code base... which would need to be ported to a backwards-incompatible version of non-null Java anyway. Hm. Well, with Java 8 I can at least start to grow null-safe code within our codebase.