fredemmott

The warnings about MacOS are mostly being cautious, as I don't think anyone actually runs it in production.

I work with open source Hack code a lot, and I almost always use the MacOS binaries instead of Linux for development.

For my workflows, it's more that there's two major missing things - I'm not seeing random issues. The big things are:

- a lot of the profiling features are Linux-only

- the mcrouter extension is Linux-only. If you're using memcached, this extension is useful even without mcrouterd, as it provides a true async (Awaitable) client.

To clarify, xhp-js was not server-side rendering - it's a framework for generating javascript code, and getting an DOM element ID for a react element that the hack code can refer to and use elsewhere, e.g. by passing to some other generated JS.

> Are there any large Hack codebases I can explore?

depends what you mean by 'large' - perhaps https://github.com/hhvm/user-documentation ?

> Does anyone know if FB tracks changes to PHP so Hack is "up to date"?

No, for the most part, Hack no longer considers PHP 'upstream'. Exceptions are things like security fixes to extension functions, if that particular extension function was derived from PHP.

Facebook doesn't. Open source users of Hack do, and it uses packagist.org - however if a package is written in PHP, Hack code can't use it.

Not 100% accurate, but if a package's composer.json does not require HHVM, it will most likely install into a hack project, but be unusable.

There's also https://github.com/hhvm/hack-codegen/tree/master/examples/do..., along with the article at https://engineering.fb.com/2015/08/20/open-source/writing-co...

This is modern Hack code, but not representative of the state of the Ent framework nowadays - ent/ent is closer design-wise, but not usable from Hack.

> Now I also don't know if I buy that MAX_INT + 1 and pass-by-reference is a pressing enough use case to break compatibility. I'd be open to hearing why, but I'd be starting from a position of skepticism.

This is an example of a change that will be made, not a rationale for the decision.

https://github.com/hhvm/hack-router/ and https://github.com/hhvm/hack-router-codegen/ power docs.hhvm.com and some of our other users; they do have problems such as extremely lacking documentation, which I'm going to be addressing soon.

This is definitely an area we're planning on working on - and this post is meant to be announcing the start of this work, not that it's ready :)

For completeness: Sara Golemon started porting Facebook's old PHP5 implementation of XHP to PHP7 - you can find it here: https://github.com/phplang/xhp + https://github.com/phplang/xhp-lib

we're currently leaning towards out/inout parameters, with copy semantics, not byref (and in most cases, we'll probably be able to optimize away the copy); not certain yet though.

You'll also see a few of these on http://php.net/manual/en/migration70.incompatible.php :p

Sorry, I know this is a pain; I'm hoping to fix it by the end of the year (along with bringing back nightly debs, and supporting more recent versions of debian/ubuntu). For homebrew build times, there's https://github.com/hhvm/homebrew-hhvm/issues/5

In the short term, docker works rather nicely.

> my ask is to just make a better language and drop ALL of PHP baggage.

Long-term, we hope to make pure-hack projects more practical, and we're aiming to make Hack the best web development language. This will take time - both to decide what parts of PHP we want to keep (it definitely does have excellent parts), and how we want to change the things we think need improvement.

> Because why even break support from PHP7 if you don't plan to change (fix) the builtins?

Sorry, I was unclear: changing the behavior of the PHP builtins will break BC with PHP, and the result would still not be what we want for hack. We're likely to build Hack-only replacements for the PHP builtins, instead of changing the behavior of them.

I'll leave the first part of your question for someone less close to the project.

For the toolchain, when using it: it's currently mostly the PHP toolchain (e.g. composer) with some additions:

- the typechecker: this is a fast (I usually get full results in well under a second) static analysis tool, fully integrated with Nuclide (our IDE), and with excellent support in VSCode via a third-party plugin. This is a massive improvement in developer experience, especially when refactoring. Usually the unit tests pass first try once I've fixed the problems that Hack finds.

- an autoloader that can handle any definition (e.g. functions, typedefs, constants), not just classes

- the built-in webserver isn't just for development - no need for fastcgi + apache etc, though that is supported

As for building/working on HHVM itself, it's basically modern C++ using CMake, and the Hack typechecker is OCaml.

Function naming:

We're moving towards functions_like_this(), instanceAndStaticMethodsLikeThis(), and async functions like foo_async() and methods like fooAsync(). We're unlikely to change the PHP builtins, but we're fairly likely to build replacements - for example, Hack Arrays are best used with https://github.com/hhvm/hsl instead of the PHP array functions, and this also provides replacements for common string operations that are consistent and fit well with the Hack type system (e.g. nullable or throw an exception instead of falseable).

For return values, I'm not sure exactly what you mean - could you give a full example? If I take your example verbatim, it's a syntax error in both Hack and PHP - if I go for "5"*10, it's a Hack error (https://gist.github.com/fredemmott/90c5f8eca17d1d4e1204f0085...)

Thanks; we don't feel that the framework authors have to make a choice here:

- short-term, those of us working on HHVM - not the frameworks - need to make sure that HHVM can run the frameworks that Hack developers require

- long-term, we expect Hack and HHVM to continue to diverge from PHP; it's unlikely that targeting both HHVM and PHP will be a practical long-term strategy

There's https://github.com/facebook/squangle for MySQL, though it's lacking documentation, and requires a https://github.com/facebook/mysql-5.6 or WebScaleSQL client library

No - it still renders the element client-side so that it supports interactive components. See:

https://github.com/hhvm/xhp-js/blob/master/src/XHPReact.php

https://github.com/hhvm/xhp-js/blob/master/xhpjs.js#L94-100

RE exceptions: in HHVM at least you can change this:

1. set hhvm.error_handling.call_user_handler_on_fatals=true in your ini file 2. throw exceptions from your handler :)

People are having lots of success with https://github.com/mongofill/mongofill-hhvm

also, if this is an open source workload, any chance you could submit it to https://github.com/hhvm/oss-performance ? We generally optimize based on those benchmarks, and Facebook itself.

do you have any profiling information to share? if you could post it as a github issue, we'd be very interested. This sounds unusual.

Here's one :) https://github.com/facebook/vim-flow/