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.
> 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.
> 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.
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.
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
> 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.
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
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.
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.