6 ms·
Ex-Facebooker here. Hack isn't going away. Ever. It's actually quite pleasant to develop in. The tooling now revolves around VS Code, which I personally don't
by cletus 5y ago
Ex-Facebooker here.
Hack isn't going away. Ever.
It's actually quite pleasant to develop in. The tooling now revolves around VS Code, which I personally don't like. I wish they'd based this on a Jetbrains core.
One thing I learned to love with the Hack type system is that nullability is a distinct type (eg you can assign a T to a ?T but not a ?T to a T; ? here means "nullable"). The static type checking is smart enough to figure out here:
function foo(?Foo $foo): void {
if ($foo is nonnull) {
bar(foo);
}
}
function bar(Foo $foo): void {
...
}
that the null check changes the type from ?T to T within that block.
There's literally no reason to justify the massive investment a complete rewrite would be, like literally none. It's not even close.
HHVM and Hack at this point are extremely mature technologies.
- arenaninja 5y agoThis is the second such PHP thread I've seen in the last 24 hours (the other one was on a different web property); gotta love people shitting on PHP like it's 1998
- MisterBastahrd 5y agoSome 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.
- ithrow 5y agoI don't think that anyone who uses Javascript as part of their backend stack has any room to criticize. Nodejs is a solid server runtime these days, widely test by big companies with big traffic as their frontend servers. And there is a mature option for static typing if you want that.
- nobleach 5y agoWalmart.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.
- MisterBastahrd 5y agoMaybe 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.
- nobleach 5y agoI 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.
- ksec 5y ago> Shopify and Stripe are successful with Rails! Shopify and Github are successful with Rails. Stripe uses Ruby only.
- woodruffw 5y ago> This is the second such PHP thread I've seen in the last 24 hours (the other one was on a different web property); gotta love people shitting on PHP like it's 1998 I don't care for language wars (or the kind of petty language elitism that people get into with PHP), but: isn't Hack effectively its own language (and ecosystem) at this point? I don't think that Facebook sinking tens of millions of dollars into a custom language dialect because on the initial technical decision to use PHP is a positive testament to it as a language. It instead suggests that Facebook bit the bullet.
- noduerme 5y agoI thought the original reason for it was that Zuckerberg didn't want to have the site rewritten by engineers in a language he didn't know. i.e. find a way to scale up this dorm room code without rewriting it.
- woodruffw 5y agoYeah, that's what I meant by the "initial technical decision." Perhaps "technical and ego driven" would have been more precise :-)
- mypastself 5y agoI 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 of PHP shops. The knowledge is transferable to other languages anyway, so even if PHP jobs do dry up in the near future, it won’t have been a waste.
- dayvid 5y agoI haven't checked recently, but PHP jobs tend to pay less than other languages. I've also been at interviews where the interviewer mocked PHP and I would probably have been marked lower if I tried to write my answers in PHP. Overall, PHP has matured a lot in recent years and gained in features that was missing from other popular languages (e.g. Composer/Packagist, Laravel, PHP 7 and PHP the Right Way probably contributing the most).
- noduerme 5y agoPersonally, 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.
- vineyardmike 5y agoCan 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.
- noduerme 5y agoI 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.
- golergka 5y agoWow, 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.
- notsureaboutpg 5y agoI don't know why people dislike PHP. It's a lot like React (which is so popular and beloved). I mean, React was developed at Facebook...
- vjeux 5y agoAll of the language features in ES6 / Flow / JSX that Facebook has been pushing through as part of the React ecosystem have been pioneered by Hack/HHVM at Facebook and then ported very closely to the JavaScript ecosystem.
- klodolph 5y agoIt 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/introduction https://docs.hhvm.com/hack/XHP/introduction JSX is based on XHP, of course, not the other way around.
- fredemmott 5y agoThe 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.
- 5y ago
- the_only_law 5y agoDoes anyone use Hack outside of Facebook. Disclaimer: it’s been years since I looked at it and even at the time it was a very cursory look as PHP 7 was buzzing.
- Diederich 5y ago> 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-mocking Perl developer. In the end, the tooling is far, far more important and relevant than the language, and the tooling at Facebook is better than anything I've seen elsewhere, by a long shot.
- connordoner 5y agoAre you able to share some more about what makes the tooling at Facebook so great? edit: typo
- Diederich 5y agoI 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!
- connordoner 5y agoThanks for sharing!