Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: State of PHP at Facebook?

news.ycombinator.com

Post reply on HN
Print view View original

81–88 of 88 posts

Re: Ask HN: State of PHP at Facebook?

#81

Post by fredemmott »

TekMol wrote: post #23
yuliyp wrote: post #20

Migrating to Hack from PHP was huge undertaking requiring years to conclude, and that almost kept the same syntax and semantics where possible. What would the benefit of spending thousands of engineer years (read: billions of dollars) on a rewrite be? Especially when it would nearly certainly come with a huge performance regression compared to continuing to use HHVM which has come with years of optimization for worki…

Do you know if Facebook uses Composer to manage PHP dependencies?

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.

Re: Ask HN: State of PHP at Facebook?

#82

Post by fredemmott »

ThinkBeat wrote: post #25

Are there any large Hack codebases I can explore? I am interested to see how different from straight PHP it is. Does anyone know if FB tracks changes to PHP so Hack is "up to date"?

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

Re: Ask HN: State of PHP at Facebook?

#83

Post by fredemmott »

connordoner wrote: post #34
nkozyra wrote: post #29

Earlier quoted context omitted.

I haven't seen a huge emphasis on SSI + client other than projects like Next (which is ok but kind of clunky). My experience with Hack was that it was just server-side ... is there some front-end aspect to Hack?

There is: it's called XHP ( https://docs.hhvm.com/hack/XHP/introduction ). That said, I'm not sure how you'd go about server-side rendering React from Hacklang, as it seems that the open-source solution to do so is no longer supported ( https://github.com/hhvm/xhp-js ).

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.

Re: Ask HN: State of PHP at Facebook?

#84

Post by fredemmott »

klodolph wrote: post #39
golergka wrote: post #28

Earlier quoted context omitted.

Wow, that's almost the same thing that Typescript is to Javascript. Is all of that openly available to outsiders? If it is, I think I might to rethink my stance of php that I had for the last 15 years.

It is available. My understanding is that, unlike PHP, it really only has first-class support on Linux. You can run it on macOS, but you may have to fix some issues yourself. I've been tempted to use it for things like static website generation, since it has the "XHP" stuff, which is like JavaScript's JSX... and I'd undoubtedly prefer writing code in Hack to writing code in JavaScript. https://docs.hhvm.com/hack/XHP/…

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.

Re: Ask HN: State of PHP at Facebook?

#85

Post by ksec »

nobleach wrote: post #68
MisterBastahrd wrote: post #42

Earlier quoted context omitted.

Some people like pretending that other languages don't have their own warts. There are thousands of mature SAAS products that use PHP and don't rely on Wordpress for anything. I don't think that anyone who uses Javascript as part of their backend stack has any room to criticize.

Walmart.com (during Black Friday) would beg to differ. LinkedIn might want a word too. I'm sure every language has its success story(ies) along with a long list of failures. Shopify and Stripe are successful with Rails! JavaScript is no different here.

> Shopify and Stripe are successful with Rails!

Shopify and Github are successful with Rails.

Stripe uses Ruby only.

Re: Ask HN: State of PHP at Facebook?

#86

Post by mtberatwork »

noduerme wrote: post #73
vineyardmike wrote: post #67

Earlier quoted context omitted.

Can you elaborate on this? Not the first time I've heard a similar sentiment (and the proliferation of PHP over the years def provides some justification) but I've never heard people explain why .

I trust Apache to spin up a new PHP process for each request. Except under DOS attack or with some horrendous memory leak, it's just solid. Obviously it's a lot more overhead. But if there's some uncaught exception in a corner of PHP code, it doesn't crash the main thread and drop all the other processing on incoming requests. This means that a bug a user discovers is usually something I can fix during business hours…

> I trust Apache to spin up a new PHP process for each request. Except under DOS attack or with some horrendous memory leak, it's just solid. Obviously it's a lot more overhead.

FWIW, PHP-FPM has been the standard way of deploying PHP in production for many years now [1]. No need for running PHP as an Apache module.

[1] https://cwiki.apache.org/confluence/display/httpd/PHP-FPM

Re: Ask HN: State of PHP at Facebook?

#87

Post by vineyardmike »

noduerme wrote: post #73
vineyardmike wrote: post #67

Earlier quoted context omitted.

Can you elaborate on this? Not the first time I've heard a similar sentiment (and the proliferation of PHP over the years def provides some justification) but I've never heard people explain why .

I trust Apache to spin up a new PHP process for each request. Except under DOS attack or with some horrendous memory leak, it's just solid. Obviously it's a lot more overhead. But if there's some uncaught exception in a corner of PHP code, it doesn't crash the main thread and drop all the other processing on incoming requests. This means that a bug a user discovers is usually something I can fix during business hours…

Wow thanks for the detailed response! I really appreciate it.

Re: Ask HN: State of PHP at Facebook?

#88

Post by Apofis »

Shish2k wrote: post #70
Apofis wrote: post #54

Earlier quoted context omitted.

I used HHVM for a while and it was good before PHP7, but then it quickly became irrelevant once the PHP core and community got their act together.

PHP still doesn’t have XHP though :(

Why would you want this when you have blade templates or further down .jsx or .vue templates?
Post reply on HN