I'm chief architect at Slack, and we migrated to Hack from PHP 5 throughout 2016.

The toolchain for HHVM is all installed as a single big deliverable, which gives you the language engine and supporting runtime libraries itself, an in-address-space web server (Facebook's Proxygen), a debugger in the form of hhvm -a, and the Hacklang toolchain accessed via hh_client and appropriate editor/IDE integrations.

I share your intuition that there is actually a glittering core of "stuff-that-makes-you-successful" hiding in the incidental complexity of PHP, and we wrote this blog post trying to put some substance behind that intuition: https://slack.engineering/taking-php-seriously-cf7a60065329

I have essentially created a private facebook that has no friends, yet the same person continues to show up as the first person in the pymk, javascript in the HTTPWATCH that I downloaded.. why is that? I already removed them from the suggested friends when it was pulled up - but every single time they have pulled up as the very first after my ID in the code. If I were to send you the code privately could you explain it to me??

Wouldn't it make more sense to take the parts of the PHP runtime environment that enable rapid prototyping and figure out how to implement them in a language that has a working == operator rather than trying to graft type safety on a language that has both strpos() and str_rot13()?

Remember BML, bradfitz' attempt to do this with Perl?

I would love to see someone do something similar for Python.

> a language that has a working == operator

== has always been working in PHP. I know maybe that optional type coercition trips up some noobs occasionally before they made any effort to learn the language (hint === doesn't coerce types for equality), but how low effort does a complaint have to be?

Type coercition is actually pretty cool when you're not really sure what the browser or client is about to http at you and you just want it to work. It's much better than crashing at runtime because '12' isn't a number. If you're input isn't sane, throw an exception or use a validation library.

Now if we're talking about a good type system that can be enforced at compile time like rust, Scala, etc. Sign me up. But if it's run time, it's run time, we gotta keep going.

> It's much better than crashing at runtime because '12' isn't a number.

something something yell at you for breaking their door

You also helped start HHVM, Keith :).

I have worked on a somewhat large-ish backend that was built with Hack. In the end, we dropped it in favor of PHP7, due to all the small incompatibilities it had, and all the non-standard things we had to do to use it. With PHP7 the performance difference was negligible (our original reason for choosing it), and the type annotations of PHP7 were good enough for us.

With switching, we were also able to use phan[0] and other tools that helped us write better PHP code that were previously unusable due to Hack.

[0]: https://github.com/phan/phan

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.

I've worked on HyperPHP / HipHopPHP (HPHPc, known by a million different things in its lifespan) in the past doing a lot of documentation and edge case testing. I absolutely loved the compiler, turning PHP scripts into C++, and running it through its paces using ANN libraries. I have a lot of love for the project and was onboard very early in the lifecycle. I really, really miss it. I thought it was a great learning tool.

Anyway, it's proven that without competitors to Zend Engine, the PHP team simply doesn't care to pay much attention to performance. (Snide comments about performance from maintainers and internal PHP contributors can be found all over the Internet to prove this point.) I am afraid this will continue as HHVM splits from PHP and moves more towards a JVM-type future.

Hack will be the "serious" language while PHP7 will serve a solid niche, and one I'm continually proud to support and use in production.

Nuclide works well enough with Hack and the typechecker is really solid.

I'm excited to see the future of both projects, but again, it is important to note that HPHPc by Facebook pushed PHP's project team into caring about a lot of this stuff over the years. I hope it doesn't take that kind of disruption to continue development, as I think PHP is in a really good spot now and don't want it to stagnate.

Laravel is probably not the best example in terms of improving PHP landscape in terms of code/architecture quality: Symfony is way more prominent in that. It's not a case that Laravel is using many components from Symfony.

it is weird for me why Laravel is so popular now given that as far as I've read documentation, a lot of it is written in static class calls, which is opposite of OOP and all good pratices coming with OOP.. I understand that it's kind of rails and gives short-term productivity, but if you have complex project, it will become an issue if majority of project code is spaghetti code without DI, IoC and so on.

Laravel encourages DI via Service Containers: https://laravel.com/docs/5.5/container And, Laravel static methods (as you see in the docs as Facades) are not truly static (and testable/mockable). https://laravel.com/docs/5.5/facades#facades-vs-dependency-i... http://usman.it/laravel-4-uses-static-not-true/

thanks for response, will read it!

Laravel's facades are not static method calls, and they are all configurable through Laravel's dependency container:

https://laravel.com/docs/5.5/facades

- edited to remove snark

thanks for link, it explains a lot!

Everyone else answered your questions/misconceptions about Laravel, but Laravel owes a lot of its popularity to Laravel Forge [0] and the tooling around deployment and code management. It is a tremendous tool.

[0] https://forge.laravel.com/

It cannot be both underrated and born from whacky design choices. The reason it's underrated is because it's not well-designed.