4 ms·

Right, this is part of what I don't get. PHP is open source. Instead of building a way to compile PHP and then a VM, and making all the adjustments necessary f

Right, this is part of what I don't get. PHP is open source. Instead of building a way to compile PHP and then a VM, and making all the adjustments necessary for Hack, why didn't FB just spend that energy submitting a patch to make PHP faster? 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.

mattnewton 8y ago
I think they did submit changes to make php faster, by making those changes. I think those issues are just a few of many terrible gotchas hiding in the language they can move past by focusing on Hack.
ramy_d 8y ago
I'm not super well informed about this but if I remember it's because FB would have had to play nice with the community, make RFCs or whatever it is they use, discuss with the community and then the biggest hurdle: vote. by making hhvm, it allowed them to move at break-neck speeds with absolutely no reason to ask for permission. The social aspect of it probably turned them off at a corporate level, if that makes sense. Where as throwing more hackers at the problem was totally in their wheel house. IMO.
jasone 8y ago
The people who initially developed HPHP (the PHP-to-C++ transpiler) were not the same people who initially developed HHVM (the VM/JIT). I was one of the people who started the HHVM project, and we recognized early on that we must base our work on HPHP to have any hope of eventually replacing HPHP on Facebook's production systems. Indeed, had we chosen otherwise, our project would certainly have failed. It took us three years to initially ship HHVM, and HPHP's ancillary ecosystem dramatically diverged from PHP during that time. Furthermore, the people who initially developed Hack were yet another team, and they based their work on HHVM for much the same reason as HHVM was based on HPHP. In an ideal world of perfect cooperation, perhaps all these projects would have been enhancements to PHP, but a chain of independent rational decisions produced very different results.
- wpietri 8y ago
  Has anybody written up the history? I'd be fascinated to read a blog post series on all that.
deleted 8y ago
[deleted]
smsm42 8y ago
> why didn't FB just spend that energy submitting a patch to make PHP faster? Several reasons. First, it's not that easy. It took years of work by some very smart people to get the jump from PHP 5 to PHP 7, and Facebook needed the performance much earlier that this way could deliver (and it wasn't at all certain that it would deliver at all). Second, Facebook needed their own language anyway to be able to add stuff they - with their particular use case, which is dissimilar to the use case of the vast majority of PHP users - need and for the model they use to run servers and operations. So for Facebook having something that both delivers performance that they need and is under their total control and can be made to do exactly what they need it to do makes a lot of sense. > 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. It's not about that, that part is small change. The point is they don't want to be restrained by what PHP does, but want to have their own way with HHVM. Which is very understandable, they have their needs and they found a way to support them. Of course, for the open source community might be better if Facebook continued to support PHP - but if for Facebook it makes more sense to do their own thing without worrying about being compatible with PHP, then that's what they should do.
ivanhoe 8y ago
Perhaps they need a bit more control over the project? PHPs voting system is a bit weird, in the past a lot of great proposals had been voted against. If there was no for a few individuals investing a lot of personal time and energy to push for votes many of the features that are now highly praised in PHP7 wouldn't even be there. I can only presume that this is not a very good solution for Facebook, as they probably need a way to have a better control over the roadmap...
onion2k 8y ago
why didn't FB just spend that energy submitting a patch to make PHP faster The maintainers wouldn't have to accept it, and there are plenty of devs in the community that would have issues with Facebook code making it's way in to the core of a language. If the patch wasn't accepted then Facebook would have to have forked PHP anyway. Rather than bother with the politics and PR downside of their code being rejected, they went straight to creating a fork. It may have been the less optimal technical solution, but like so many technical decisions it was really a business decision in disguise.
aylmao 8y ago
Well, the compiler was its own thing and had very different goals. I'm sure that wouldn't have flown for most use-cases and from what I've read it was used only for running production code because compilation took a while. HHVM also adds a lot of syntax to make Hack. And moreover I don't doubt Facebook wanted the option to remove backwards compatibility in the future. Issues like MAX_INT and pass-by-reference don't seem pressing enough if you're using the language, but if you're building a compiler or VM small language quirks will be the one exception that break whole potential optimizations and/or ways of architecting things. Facebook is not concerned with backwards compatibility because they can just change their source code, but PHP is, in order to remain relevant to the community. I honestly think trying to work on the same VM would've caused more issues in the long-run.
zaphar 8y ago
They want to break backwards compatibility. That would arguably be a bad thing for PHP as a language. It's apparently something they need for themselves though. The only choice that isn't being a bad citizen is to break away from PHP. PHP. Can freely being in any improvements that fit their model, but the goals of the two projects are no longer compatible.
fredemmott 8y ago
> 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.

mattnewton 8y ago

I think they did submit changes to make php faster, by making those changes. I think those issues are just a few of many terrible gotchas hiding in the language they can move past by focusing on Hack.

ramy_d 8y ago

I'm not super well informed about this but if I remember it's because FB would have had to play nice with the community, make RFCs or whatever it is they use, discuss with the community and then the biggest hurdle: vote. by making hhvm, it allowed them to move at break-neck speeds with absolutely no reason to ask for permission. The social aspect of it probably turned them off at a corporate level, if that makes sense. Where as throwing more hackers at the problem was totally in their wheel house. IMO.

jasone 8y ago

The people who initially developed HPHP (the PHP-to-C++ transpiler) were not the same people who initially developed HHVM (the VM/JIT). I was one of the people who started the HHVM project, and we recognized early on that we must base our work on HPHP to have any hope of eventually replacing HPHP on Facebook's production systems. Indeed, had we chosen otherwise, our project would certainly have failed. It took us three years to initially ship HHVM, and HPHP's ancillary ecosystem dramatically diverged from PHP during that time. Furthermore, the people who initially developed Hack were yet another team, and they based their work on HHVM for much the same reason as HHVM was based on HPHP. In an ideal world of perfect cooperation, perhaps all these projects would have been enhancements to PHP, but a chain of independent rational decisions produced very different results.

wpietri 8y ago
Has anybody written up the history? I'd be fascinated to read a blog post series on all that.

deleted 8y ago

[deleted]

smsm42 8y ago

> why didn't FB just spend that energy submitting a patch to make PHP faster? Several reasons. First, it's not that easy. It took years of work by some very smart people to get the jump from PHP 5 to PHP 7, and Facebook needed the performance much earlier that this way could deliver (and it wasn't at all certain that it would deliver at all). Second, Facebook needed their own language anyway to be able to add stuff they - with their particular use case, which is dissimilar to the use case of the vast majority of PHP users - need and for the model they use to run servers and operations. So for Facebook having something that both delivers performance that they need and is under their total control and can be made to do exactly what they need it to do makes a lot of sense. > 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. It's not about that, that part is small change. The point is they don't want to be restrained by what PHP does, but want to have their own way with HHVM. Which is very understandable, they have their needs and they found a way to support them. Of course, for the open source community might be better if Facebook continued to support PHP - but if for Facebook it makes more sense to do their own thing without worrying about being compatible with PHP, then that's what they should do.

ivanhoe 8y ago

Perhaps they need a bit more control over the project? PHPs voting system is a bit weird, in the past a lot of great proposals had been voted against. If there was no for a few individuals investing a lot of personal time and energy to push for votes many of the features that are now highly praised in PHP7 wouldn't even be there. I can only presume that this is not a very good solution for Facebook, as they probably need a way to have a better control over the roadmap...

onion2k 8y ago

why didn't FB just spend that energy submitting a patch to make PHP faster The maintainers wouldn't have to accept it, and there are plenty of devs in the community that would have issues with Facebook code making it's way in to the core of a language. If the patch wasn't accepted then Facebook would have to have forked PHP anyway. Rather than bother with the politics and PR downside of their code being rejected, they went straight to creating a fork. It may have been the less optimal technical solution, but like so many technical decisions it was really a business decision in disguise.

aylmao 8y ago

Well, the compiler was its own thing and had very different goals. I'm sure that wouldn't have flown for most use-cases and from what I've read it was used only for running production code because compilation took a while. HHVM also adds a lot of syntax to make Hack. And moreover I don't doubt Facebook wanted the option to remove backwards compatibility in the future. Issues like MAX_INT and pass-by-reference don't seem pressing enough if you're using the language, but if you're building a compiler or VM small language quirks will be the one exception that break whole potential optimizations and/or ways of architecting things. Facebook is not concerned with backwards compatibility because they can just change their source code, but PHP is, in order to remain relevant to the community. I honestly think trying to work on the same VM would've caused more issues in the long-run.

zaphar 8y ago

They want to break backwards compatibility. That would arguably be a bad thing for PHP as a language. It's apparently something they need for themselves though. The only choice that isn't being a bad citizen is to break away from PHP. PHP. Can freely being in any improvements that fit their model, but the goals of the two projects are no longer compatible.

fredemmott 8y ago

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