Live data from Hacker News

Ask HN: State of PHP at Facebook?

news.ycombinator.com

71–80 of 88 posts

Re: Ask HN: State of PHP at Facebook?

#71

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"?

Not quite an answer to your question but slack engineering wrote a paper [1] on migrating their code base from PHP proper to Hack. Specifically they used [2] 'partial mode' since "this loosens several restrictions to ease migration" [1] https://slack.engineering/hacklang-at-slack-a-better-php/ [2] https://docs.hhvm.com/hack/source-code-fundamentals/program-... EDIT: This would indicate that Hack may perhaps support s…

They stopped supporting interoperability a while ago [0].

[0]: https://hhvm.com/blog/2018/09/12/end-of-php-support-future-o...

Re: Ask HN: State of PHP at Facebook?

#72

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.

Maybe read what I said instead of leaping in to defend against things I didn't say.

For example:

>I'm sure every language has its success story(ies) along with a long list of failures.

is actually in your reply to:

>Some people like pretending that other languages don't have their own warts.

I don't think node is a bad platform. I think the language it's based on is terrible, and nobody who is willfully writing backend code in node has any real justification to complain about someone else's choice to use PHP.

Re: Ask HN: State of PHP at Facebook?

#73

Earlier quoted context omitted.

Personally, I still default toward PHP as a backend for most web apps. While it's not a joy like writing for Nodejs, you don't have to worry about routing or something unforeseen blocking the main thread. I also have to manage servers 24/7 for the apps and sites I build. I simply don't trust Node as much in production.

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, not get woken up at 4am because "the server is down". I use PM2 when I manage Node and it does a fairly good job of keeping things running and well-logged, but to me the Node event loop is just a single point of failure I don't need unless I'm building something that really needs Node's architecture, like a fast-paced game or chat. (And I've even done those with PHP). And then in cases where I need the server to do a few seconds of heavy data processing like collating large reports once they come back from a database, with Node you need to spin up a worker pool to not block the loop with those operations, which complicates reliability even more; with PHP you can get away in a lot of cases with letting the thread spawned by the call just take its time to chew through a bunch of math.

I've always been a fan of stateless code wherever I can get away with it. My casino, for instance, ran on PHP, and although it upgraded the connection to a socket where possible, it created a new DB connection and loaded the game state from SQL, then stored a new game state, for every single action a player took within a game, e.g. every hit within a hand of blackjack. The database was at all times a consistent snapshot of the entire state of the casino. A single player's action might fail and roll back, but it wouldn't bring down the whole site and lose all the other actions in progress.

In some respects, it's also just that I think setting up an Express router (or Koa, my preference) and graceful handlers and 404 handlers and everything in Node is overkill if you just want to serve web pages, validate forms or handle RESTful API calls. DB connections go down and you may need to recover from a slew of failed queries in rapid succession instead of just counting on a new DB connection being tried for each incoming request.

Node really shines with anything that requires statefulness on the server, low latency, push data, etc. And for me the nicest thing about Node is the ability to share the same unified data classes between client and server. But I view Node kinda like a Porsche. High performance, a bit unreliable and dangerous. Great to have in the garage. But when you're just driving to the market you're better off taking the Subaru.

Re: Ask HN: State of PHP at Facebook?

#74

Earlier quoted context omitted.

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.

Maybe read what I said instead of leaping in to defend against things I didn't say. For example: >I'm sure every language has its success story(ies) along with a long list of failures. is actually in your reply to: >Some people like pretending that other languages don't have their own warts. I don't think node is a bad platform. I think the language it's based on is terrible, and nobody who is willfully writing backe…

I took your comment to instill a sort of "pecking order" among back-end languages. In this case, it sounded an awful lot like "it goes from _insert language(s) you approve of_ to PHP to JavaScript". Basically that you'd lump PHP and JavaScript into the "terrible" bin. I'm simply pointing out while you may have disdain for those languages (and perhaps even rightfully so) the users are free to love them and still hate other languages.

If I misrepresented your stance, I apologize.

Re: Ask HN: State of PHP at Facebook?

#75

Earlier quoted context omitted.

> The tooling now revolves around VS Code When I was there a couple of years ago, doing Hack development using vim was well supported. Not as slick as the official IDE, but more than good enough for my day to day tasks. > There's literally no reason to justify the massive investment a complete rewrite would be, like literally none. It's not even close. Definitely, and my (relatively ancient) background is as a PHP-mo…

Are you able to share some more about what makes the tooling at Facebook so great? edit: typo

I can answer only briefly, and that's a pretty big topic!

I'll skip the apparently pretty amazing integration between the IDE and source control and the build/test system since I didn't use the IDE very much.

I'll just very briefly mention Tupperware, which one might characterize as an internal kind of Kubernetes, except it's so much more, but more importantly, it's way easier to use.

I did write a small, fairly simple stand alone service in Python. It's super, super easy to get something like that 'going', as far as permissions, ingress and egress, storage, all of the real-life complications I've had to deal with, with variable levels of automation/'ease', at other organizations.

I'm out of time for now!

Re: Ask HN: State of PHP at Facebook?

#77

Earlier quoted context omitted.

I assume this thread was inspired by the other one. I too am actually interested in the current state of PHP jobs. I previously assumed it mostly entailed working on legacy projects, which is what I do occasionally. I have a younger friend who is primarily interested in working with PHP. I wanted to advise against pursuing it too much due to questionable future prospects, but he’s found gainful employment in a couple…

Personally, I still default toward PHP as a backend for most web apps. While it's not a joy like writing for Nodejs, you don't have to worry about routing or something unforeseen blocking the main thread. I also have to manage servers 24/7 for the apps and sites I build. I simply don't trust Node as much in production.

I wouldn't call nodejs a joy though.

Re: Ask HN: State of PHP at Facebook?

#79

Earlier quoted context omitted.

Are you able to share some more about what makes the tooling at Facebook so great? edit: typo

I can answer only briefly, and that's a pretty big topic! I'll skip the apparently pretty amazing integration between the IDE and source control and the build/test system since I didn't use the IDE very much. I'll just very briefly mention Tupperware, which one might characterize as an internal kind of Kubernetes, except it's so much more, but more importantly, it's way easier to use. I did write a small, fairly simp…

Thanks for sharing!

Re: Ask HN: State of PHP at Facebook?

#80
post #11

All of the “www” code (backend which serves all the web apps and APIs) is Hack. And a lot of that code is generated via internal frameworks like Ent which is a graph abstraction over database access. There doesn’t seem to be any incentive to switch www away from Hack: it wouldn’t reduce the learning curve very much due to all those internal frameworks, and would remove the opportunity to optimize the language for the…

For anyone interested, it looks like there's an open-source version (close, at least) to Ent at https://github.com/ent/ent .

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.

Post reply on HN