

Building a Better PHP – Part 3: Getting Started with Hack - DaveyShafik
https://blog.engineyard.com/2014/hhvm-hack-part-3

======
dsugarman
I don't understand why you would ever want comments to affect the outcome of
the program, it can only confuse programmers

------
ZeroGravitas
To what degree can you opt in to all this, while still producing code that'll
run on standard PHP? Not a lot, seems to be the answer, but maybe I'm looking
in the wrong places.

~~~
trebor
Hack extends the PHP syntax with type hints which are required (I think). So
any Hack scripts are incompatible with PHP, starting with the `<?hh` tag and
moving on from there. Technically HHVM can run projects that are a mix of
PHP/Hack, but I wouldn't recommend that. Mixing your codebase is worse for
portability, in my opinion, as implementors are more likely to implement
_just_ Hack than Hack + PHP.

~~~
jwatzman
> type hints which are required (I think)

Only in strict mode; in partial or decl mode, you can leave off the
annotations. In fact, a large fraction of PHP files are also valid Hack files
in partial mode. The article has a decent explanation of the modes, and see
[http://docs.hhvm.com/manual/en/hack.modes.php](http://docs.hhvm.com/manual/en/hack.modes.php)
for our official documentation.

> Technically HHVM can run projects that are a mix of PHP/Hack, but I wouldn't
> recommend that. Mixing your codebase is worse for portability, in my
> opinion, as implementors are more likely to implement just Hack than Hack +
> PHP.

I'm not sure I understand your argument here. Hack was _designed_ to be
seamlessly used in a mixed PHP/Hack codebase. Facebook itself is still in such
a mixed state, and will likely remain so for the foreseeable future; we've
gotten a ton of benefit from converting _most_ of our code, but there's a long
tail that's just not worth pushing through all at once.

~~~
trebor
Sounds like it's better than I thought.

> I'm not sure I understand your argument here. Hack was designed to be
> seamlessly used in a mixed PHP/Hack codebase.

My argument is that if another person/organization implemented a Hack runtime
it'd most likely be Hack-only, not Hack + PHP. As you can see, I don't mean in
HHVM itself but in potential 3rd party implementations. So software written to
run in a mixed Hack mode now, may not be supported in the future with other
interpreters.

I'm still interested in trying Hack, in spite of that opinion.

------
nasalgoat
I'd love to move to Hack but the lack of support for the robust third party
plugins that I rely on, such as Redis or MongoDB, makes it a no-go.

------
cies
Is Hack-strict, apart from type annotations, a proper subset of PHP?

~~~
itafroma
> Is Hack-strict, apart from type annotations, a proper subset of PHP?

No, but it's close. Here's a fairly comprehensive list of missing language
features:
[http://docs.hhvm.com/manual/en/hack.unsupported.php](http://docs.hhvm.com/manual/en/hack.unsupported.php)

Theres also the question of HHVM—the runtime at the core of Hack—and its
current support for PHP (which indirectly affects Hack's own support for PHP
features it intends to have). It's also close, but not quite, at feature
parity with PHP's internal runtime: [http://hhvm.com/blog/2813/we-are-
the-98-5-and-the-16](http://hhvm.com/blog/2813/we-are-the-98-5-and-the-16)

------
camus2
Nice,solutions like Hack are the only way PHP can survive it's doom. With the
development of cloud solutions even beginners are not bound to whatever crap
hosting providers impose on their servers anymore, so PHP will have to improve
drastically to compete.

~~~
RussianCow
Are you kidding? PHP is by far the most supported language among web hosts,
and I don't see that changing drastically any time soon. "Beginners" aren't
switching to VPSes because they don't need them; shared hosting still makes
more sense. It's about the right tool for the job.

