4 ms·
In Hack, collection objects were one of the biggest early mistakes that the took a huge amount of effort to undo. It turns out that the copy-on-write semantics
by yuliyp 1y ago
In Hack, collection objects were one of the biggest early mistakes that the took a huge amount of effort to undo. It turns out that the copy-on-write semantics of PHP array were extremely important for performance and good APIs. Being able to pass arrays to things without fear of mutation allowed for tons of optimizations and not needing to copy things just in case. This is why Hack switched to using `dict`, `vec`, and `keyset` rather than collection objects.
More generally, it's weird to see a whole blog post about generics for PHP not even mentioning Hack's generics designs. A lot of thought and iteration went into this like 5-10 years ago.
See https://docs.hhvm.com/hack/arrays-and-collections/object-collections https://docs.hhvm.com/hack/arrays-and-collections/object-col... and https://docs.hhvm.com/hack/arrays-and-collections/vec-keyset-and-dict https://docs.hhvm.com/hack/arrays-and-collections/vec-keyset...
- maxloh 1y agoI thought Hack is dead or not intended for public use anymore. But after some quick checking, I learned that Hack is still actively maintained, surprisingly.
- phplovesong 1y agoIt is, and Hack exists ONLY because PHP was not cutting it for a big project like facebook. Its the biggest example out there why should not use PHP for anything close to, say 10% of facebook scale.
- nolok 1y ago> Its the biggest example out there why should not use PHP for anything close to, say 10% of facebook scale. What a weird take to base your current belief on something that happened more than a decade ago. Not only the condition for Hack creation (speed, memory usage and strict type checking) have been fixed a long time ago since php 7.0 But also if you reach 10% of facebook scale, it doesn't matter what language you used, you will need to rewrite anyway. Show me a company where PHP is the issue because they reached 10% of facebook scale, and what you're showing is a company that succeeded thanks to PHP. Applies to other language the same. Picking your stack based on "but what if I reach that scale" has to be the mother of all premature optimisations.
- phplovesong 1y agoThere are many large projects out there written in say, Java (the old boring dog) that did not have to rewrite. I can add C# as another traditional corpororate language. There are many others too. PHP not so much.
- nolok 1y agoYeah you will have to provide a list of "10% of facebook scale" projects using those language and didn't need to have any rewrite
- 4ndrewl 1y agoI doubt anyone here is working to 1% of fb scale, let alone 10%. The answer to "why Hack" needs to be viewed in the historical context of "when Hack" and what was happening (or not) in the php ecosystem at that time. Things have changed a lot since, in terms of performance, language longevity, ecosystem etc. Its a perfectly reasonable language to adopt for many orgs.
- rob74 1y agoMore specifically, Hack was developed during the time when it looked like the PHP project wasn't going anywhere (it was stuck at version 5.x for ten years while version 6 was in the works, then abandoned, then version 7 was developed based on version 5 and finally released in 2015).
- mrkeen 1y agoGiven that Hack had generics as early as 2014, it seemed that those who were worried about PHP being stuck were right. Unless I'm misunderstanding what this proposal (not finished artifact) is about.
- ZiiS 1y agoSome people here work at (exactly) 100% of fb scale.
- mrkeen 1y agoSeems to line up with what the authors say: At Facebook scale — with thousands of engineers shipping new code twice a day — slowdowns like these are even more problematic. https://engineering.fb.com/2014/03/20/developer-tools/hack-a-new-programming-language-for-hhvm/
- meindnoch 1y agoThe backend of Facebook's frontend is written in Hack. For longest time, I wouldn't believe it... and then I saw the code with my own eyes.