24 ms·

Ending PHP Support, and the Future of Hack

429 points by dcgudeman 8y ago

deleted 8y ago
[deleted]
alexandercrohde 8y ago
Hmm, I don't really get it. But I suppose I don't really know if I bought the value proposition of HHVM in the first place.
- smsm42 8y ago
  hhvm had some performance advantages over PHP 5. They are largely gone with PHP 7 AFAIK.
  - alexandercrohde 8y ago
    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.
- jchw 8y ago
  Since PHP picked up the slack, diverging from it makes complete sense. When HHVM was released, PHP's implementation had a ton of issues, but now it's doing a lot better. However, even with PHP 7, the language itself is still riddled with confusing behaviors that will likely remain for a long time. They may as well break away from the cost of maintaining backwards compatibility and leave that to PHP, while they fix deep issues with the language and add features like typing. I still don't see myself using it, but it seems like a reasonable path forward for someone who wants to modernize a large PHP codebase and would like features like type safety.
- ksec 8y ago
  HHVM and the work of Hack is what made PHP Great again. ( Or more like bearable ) PHP 7 along with laravel can get you some insane development speed. And I argue Hack, and PHP7 is actually want made PHP's downfall stabilise. The community saw their ecosystem has a way going forward and more improvements to come. Rewriting your app in different languages and frameworks is hard, no sane person wants to do it.
sdfb 8y ago
php is amazing!
- alexandercrohde 8y ago
  I think PHP is interchangeable with PHP, ROR, and node (i.e. give me a line in any of them, and there's a one-liner in the other to do the same thing) [this wouldn't be true for something like Scala]. So, presumably for the same reason somebody would do a project in ROR.
  - sdfb 8y ago
    php stands out for being extremely simple to use for new comers
    - jadell 8y ago
      You can do event-driven and non-blocking IO in PHP. Check out a library like ReactPHP.
    - Lazare 8y ago
      There's a ton of basic CRUD apps and REST APIs being written in node for which the event-driven model is useless at best, and actively harmful at worst. Looking around at actual production node code, huge swathes of it could easily be written in Rails, Django, or Symfony with no real loss of performance or developer productivity. (And given the maturity of those ecosystems, probably a net gain in developer productivity. Example: ORMs aren't great at everything, but sometimes they save you a lot of time, and Node doesn't have an ORM that can compare to ActiveRecord, Doctrine, or SQLAlchemy.)
      - outside1234 8y ago
        CRUD is literally what node.js is built for - lightweight APIs that then have to do some slow operation async against a store - which they overlap requests across with an event-driven model
crispytx 8y ago
Diverging from PHP was a good move as PHP 7 has largely caught up with HHVM in terms of speed. That's really neat that Facebook invented their own language to meet their needs. Will have to mess around with it further sometime.
- jaytaylor 8y ago
  Agreed, Hack appears to be a move to fork into a PHP-esque language that FB engineering feels will be better for their software lifecycle goals and needs: - Handle numeric boundary cases in a more intuitive way. - Is Typed. - Replace reference parameters in favor of a new keyword, "inout". - Change package management and testing framework to be less annoying and more streamlined. This will be yarn (from npm, as in the one written in Javascript), and their own custom flavor of testing framework, hh-test, to replace PHPUnit. I wonder how many existing open-source PHP projects will remain compatible with HHVM? The post seems to indicate compatibility will not be a priority and that it's a fully breaking change. If this is true, it seems the "empty cocktail room" effect will be a major challenge and problem. Jane: "Hey, you can do this project in PHP or Hack." Alice: "Okay, I'll go with PHP because there's already a shitton of good libraries that might be useful to me or that I already know." I.e. Why would you use a language with few open source libraries over a very similar language with exponentially more? When I want types, I can already use Go, Java, or even Typescript, just to name a few terrific options. These days it seems like a no-brainer to me. The effort seems like a lot of trouble to go to just to shave off some annoyances / "rogue hairs". Curious if there's an angle I'm missing. One argument for making it an open-source language / project and trying to eventually grow it could be so FB can more easily hire folks who are already know the Hack language. Marke: "I'll do it in Hack because my only dream is to work at Facebook!" May not be that many Marke's out there.
  - eganist 8y ago
    > Why would you use a language with few open source libraries over a very similar language with exponentially more? Fewer unvetted libraries from a security and code quality angle. Not saying it's good from a general engineering angle, but in an environment like Facebook which can afford to over-engineer, the third party dependency risk mitigation is a good side effect. But my argument here is a pretty polarizing one as it implies security-through-obscurity. I promise I'm not; I'm just pragmatic about how many abandoned or poorly maintained open source libraries end up being relied-upon regardless of how that challenge is solved-for in CI/CD.
aasasd 8y ago
Welp, so much for “PHP has JIT too.”
- singlow 8y ago
  The official PHP JIT branch is nearing release which would have made HHVM less relevant. I think it is expected to be in 8.0, whenever that hits.
  - mgkimsal 8y ago
    My understanding is that a PHP 8, as it stands right now, is looking like Nov 2020.
- ehnto 8y ago
  They increased performance of the language enough that it caught up to HHVM. PHP7 is wildly faster than previous PHP versions. In other words, HHVMs value proposition of speed is no longer as relevant. PHP is still working on a JIT implementation but I honestly don't think it's that important for now.
  - postalrat 8y ago
    In my experience HHVM is still quite a bit faster once it gets going.
  - kyriakos 8y ago
    Due to the short lived nature of PHP requests JIT compilation wont be as effective as one would expect. Still though since php 7,every point release saw a measurable performance improvement.
- thawkins 8y ago
  PHP 7 has Zend OPtimizer built in, basically a caching bytecode compiler. Previous versions used to use the APC extension to serve the same purpose.
  - 8y ago
wprapido 8y ago
With PHP7, HHVM became largely irrelevant. It had played a great role and contributed to the PHP's maturing immensely though!
- mastazi 8y ago
  Rasmus Lerdorf actually acknowledged HHVM's role in numerous occasions, especially with reference to the development of PHP7 (Edit: sorry I tried to find a link but no luck so far).
- aylmao 8y ago
  I mean, I think people are somewhat missing the fact that it's not like these worlds are separate or competing. Some people have worked on both PHP and HHVM, and it seems like they've always acknowledged that they have different goals. From the comments in the post of the Hack announcement (before PHP7): Q: Do you imagine a future where Hack will merge back into PHP (like PHP 7), in the same style that Beryl & Compiz then rejoined? Or does the team intend for the two to always be adjacent-yet-separate? A: HHVM developer & PHP runtime developer here. I've got hands in both runtimes and all even I can say is: Maybe. I think the most likely outcome is that PHP will adopt some of HHVM's additional features, but remain a separate project. IMO that's a great outcome, since we'll both likely drive the other to be better. EDIT: Source, https://news.ycombinator.com/item?id=7436557 https://news.ycombinator.com/item?id=7436557
- hobofan 8y ago
  Yeah, at a previous job we used Hack around the time PHP7 was released and switched over to PHP7 pretty quickly. Performance and type checking were the only benefits over PHP5 and with those (mostly) gone, you were just left with all the downsides like all the good tooling for PHP being incompatible with Hack and, and general compiler/interpreter errors that were never getting fixes.
- icc97 8y ago
  HHVM can be more experimental than PHP so there's still potential that new features in HHVM get considered and merged into PHP, kind of like Fedora/Redhat or Neovim/Vim
- 8y ago
kijin 8y ago
I wonder how this will affect major websites outside of Facebook that rely on HHVM, such as Wikipedia. They made a big announcement when they switched to HHVM in early 2015. Have they moved over to PHP 7 yet?
- lathiat 8y ago
  They are planning to move to PHP7 largely because of this change but also since PHP7 closed the performance gap: https://phabricator.wikimedia.org/T176370 https://phabricator.wikimedia.org/T176370
- beberlei 8y ago
  A reminder, HHVM is not Hack. you can run both type of scripts with either <?php or <?hh. Wikpedia is <?php because its underlying MediaWiki is PHP and used outside by many companies. As such a migration of Wikipedia to PHP 7 is probably mostly an ops and not a software task.
muglug 8y ago
I don't think there are enough backend web developers in the world to support vibrant communities for both PHP and Hack. Unless Facebook's prepared to invest a lot in community-building, Hack and similar FB projects will go the way of VBScript and Silverlight.
- iodiniemetra 8y ago
  hack is going to become incredibly widespread before slowly dying off due to market forces?
  - arcticbull 8y ago
    You could argue that it already did become incredibly widespread (as php) then died off slowly due to market forces.
    - CleanShirt 8y ago
      I wouldn’t say Hack was ever popular as a language. The HHVM certainly had popularity as a runtime for PHP until the speed increase of PHP7.
  - elaus 8y ago
    I seriously can't remember any (incredibly) widespread use of Silverlight – could you elaborate? The only instance I noticed it was with a video streaming platform.
    - hiram112 8y ago
      I don't think Silverlight had a mass amount of public use (Flash and Applets were still available at the time - so there was no pressing need). But MS really did earn a lot of bad will from their dev community who had been pushed to learn yet another framework which ended up dead. I rarely even use my PC anymore. I basically then it on once a month to download the gigs of updates. It's interesting that Silverlight still listed at the top of optional updates. There must be a few businesses and schools who bought into the hype and built their internal app on SL.
deleted 8y ago
[deleted]
dsign 8y ago
Duly noted the desire of Hack to have more "typing". It seems that as soon as projects growth beyond a certain size, everybody starts wanting to add that. I wonder what would be the optimal lifecycle for long projects. Obviously, "start with dynamic language X until you reach 10^n lines of code, then fork X and add types to it" doesn't work for smaller companies :-(
- vnorilo 8y ago
  A similar strategy on a smaller scale could be gradual typing, for example Typescript. For me personally, clojure + spec seems very inviting.
  - wpietri 8y ago
    Yeah, I'm really excited to see people exploring gradual typing. Like dsign, I've noticed that I really like flexible languages like Ruby and Python for early work, but once something is big enough, I start to miss the things heavier languages give. I'm sure it will take us a decade to work it out, but it'll be fun getting there.
  - nickserv 8y ago
    Indeed, this seems to be the best way for a small code base that gradually grows in scope and criticality. It allows rapid development early on and better stability later in the project. I'm really glad that Python is making good progress on this front.
- exacube 8y ago
  i personally started to find dynamically/optionally typed languages troublesome to read -- i have to do type deduction in my head, which just feel burdensome. as simple and easy as python feels without static typing, a handful of files of python is my tolerance level before i start to hate it
  - jacquesm 8y ago
    Yep. A lack of typing puts an upper bound on the complexity of the code that effectively limits the line-count and relegates the language to 'glue' status. The reason is simple: typing functions as guard rails and guard rails are what keep you safe on the road when you are driving for 1000's of km. They have no function if you just putter about town at low speed. High line count projects almost always gravitate towards languages with such safeguards built in because otherwise the accumulation of subtle errors leads to too many runtime issues, and typing takes care of whole classes of bugs. IMO any mechanism that shifts that time of bug catching to development rather than operations should be preferred, ditto for any mechanism that forces a program to end when an undefined situation is detected, the closer to the root cause the better.
jrs95 8y ago
This is bad news for Slack, I would think. I believe they went all in on HHVM + Hack, which is going to be increasingly incompatible with 3rd party packages now.
- yurishimo 8y ago
  Is it possible they could find inefficiencies in their codebase to make up the performance difference with regular PHP? Or maybe they'll just need to add more servers to make up the difference?
  - aylmao 8y ago
    Adding more servers stops being a good option after a certain point. If you're a small company running on 20 servers you can increase your performance by 5% if you add just one more. Install it in one day, boom. If you're running on 200,000 servers, a 5% increase is 10,000 servers. That means opening a new building in your data-center, making sure your recruiting team has resources to hire enough staff for it, then hiring that staff, negotiating contracts with the power company, the component suppliers, building permits, hopefully you have enough network capacity otherwise you'll have to expand that too, etc. It's many months of work and a lot more expensive than hiring a handful of engineers to tackle performance and maybe build some libraries in-house.
- nitram1 8y ago
  I think it depends on whether the improvements facebook hopes to achieve by dropping support for php outweigh the drawbacks of losing 3rd party package compatibility
- dtech 8y ago
  Depends on how feasible a Hack -> PHP7 transition would be.
  - jrs95 8y ago
    If it was just typing it would be easy. If it's Hack collections and async/await...not easy at all
komodosquirrel 8y ago
If they fix problems of PHP and drop backwards compatibility if needed, I am all in.
erikb 8y ago
Wasn't HHVM created as compiler or interpreter for PHP?
- anticensor 8y ago
  Yes but they added so much features that the core became hard to maintain.
tscherno 8y ago
Poor Wikipedia will need to migrate back to php7 runtime which still could be complex despite of language compatibility.
- kreetx 8y ago
  Interestig fact that Wikipedia runs on hhvm! But I guess since php7 appears to be as fast if not faster nowdays then it's probably the right move anyway.
  - Washuu 8y ago
    MediaWiki has to support PHP 7 for the community of wikis outside Wikipedia that use it. If they dropped PHP 7 support they would be making MediaWiki a bit of an insular project.
    - debacle 8y ago
      Or Facebook could sponsor their development on hhvm and use that to promote hack lang.
      - Washuu 8y ago
        Then every single third party extension developer would also have to move to Hack. Knowing what I know about certain extension developers that will never happen and a hard fork of MediaWiki will occur.
- beberlei 8y ago
  Wikipedia was always a PHP software and just running on HHVM for the performance gain, not for the Hack language. The underlying MediaWiki software is used outside of Wikipedia a lot, always on the PHP not HHVM stack. I expect its only a project for their operations team and should be managable.
  - piotrkubisa 8y ago
    Could you tell more about MediaWiki use-cases outside Wikipedia? I know there is a lot of open-source projects which has MediaWiki installed for documentation (i.e. Arch Linux). Are there any usage in "internal documentation" software (like alternative to Confluence)? Why they have chosen the MediaWiki not other software which can be easily self-hosted / deployed on a premise?
pritambarhate 8y ago
Do you think dynamic types was a mistake? Almost all popular dynamically typed languages have some sort of type hinting. All new promising languages have chosen to be statically typed.
- fetbaffe 8y ago
  No, the problem is not dynamic typing, the problem is enforcing contracts. With type hinting on function parameters like in PHP you can get the best of two worlds, flexibility & enforcing contracts.
- joelbluminator 8y ago
  javascript has no type hinting, there's typescript but tons of people use plain javascript. Same for python (tons of code was and is being written without hints). The same goes for ruby.
- wasd884 8y ago
  Dynamic types weren't a mistake, but they were overused IMO. It's technically scripting, not programming, but can you imagine if Bash files were type hinted? For small scripts, solo projects or quick fixes, dynamic typing is great because it's fast! On the flip side, large codebases should (on the whole) not use dynamic types because of all the safety they fail to provide! As you said, most dynamically typed languages are moving towards some sort of type hinting and that's because high quality developers demand it when working on medium to large projects.
  - strzibny 8y ago
    > It's technically scripting, not programming Nope. Dynamic types have nothing to do with scripting vs programming. What a nonsense! Sorry I had to:).
    - wasd884 8y ago
      You misunderstood me. I agree that scripting and programming have nothing to do with dynamic types. > It's technically scripting, not programming, but can you imagine if Bash files were type hinted? I was clarifying that writing Bash files was scripting and not programming.
ape4 8y ago
I would have liked "Hack" to be some play on "PHP". Maybe "HPH". PHP++ or PHPPP
deleted 8y ago
[deleted]
m_st 8y ago
Article from Marco Arment about exactly this, from 2014. https://marco.org/2014/03/21/hack https://marco.org/2014/03/21/hack
Nitramp 8y ago
It's interesting to see this, and curious if you look at it from an organizational decision making standpoint. Hypothetically, because I'm not involved in any of this, but still: Facebook was initially implemented using PHP, and you can read this process as continued iteration based on this very early decision. From the outside, Facebook seems to have always taken what they had, taken the problems they currently had, and made the most incremental change they could to fix whatever problem they had. From PHP to HHVM to Hack to dropping PHP support, they continued iterating on what code base and development chain they currently had. If you take a step back though, Facebook is gradually moving to a different programming environment, from a dynamic language with very loose semantics to a statically typed system with (from code I've seen in e.g. phabricator) a very different programming style than run of the mill PHP. While iterating incrementally, they still ended up forking PHP and moving to a different language. The approach is quite different from e.g. Twitter though, who started off using Ruby on Rails, and then moved everything to an entirely different tool chain (Scala) when they found Rails couldn't hold up with their problem set. This difference in approaches isn't quite the same as the good old "rewrite vs refactor" dichotomy. Twitter's change was certainly incremental too, moving individual services to Scala bit by bit, setting them live incrementally instead of a "big bang" rewrite where everything moves to Scala one day. I think the main difference is planning horizon: do you opportunistically fix whatever is broken right now, or do you make a long term plan on what you want your future platform to be, and then set out to get there? Opportunistic fixing has the advantage that you can be pretty certain you're fixing the right problem, and don't invest in YAGNI features. On the other hand, you risk ending up in local optima. Pouring a lot of effort into PHP makes sense if you plan to continue using it - but if you end up forking the language anyway, you loose a lot of the advantages of a shared ecosystem (and arguably damage the existing ecosystem in the process through fragmentation). You could equally well imagine Facebook picking a different future tech stack five years ago, be it Rust or Go or whatever, and add the features they miss from PHP to it. I think it's an interesting thought experiment where that'd have taken them. I have no idea if taking that path would have been better for any of {Facebook, PHP, target language X, world}.
- SwellJoe 8y ago
  Very few entities have the resources that do what Facebook (or Google or Microsoft) have done, in creating an entire new language (or languages) that suit their particular needs, and in a relatively short time (hack was being used within facebook very quickly). Twitter certainly doesn't have those kinds of resources, but they do/did have the resources to migrate to a language with an existing developer community and existing tooling.
oh-kumudo 8y ago
Which makes sense. Facebook now is big enough to sustain a programming language on its own. And for Hack, I would assume it mainly to replace where the PHP used to be, which is a shallow API composition layer, no heavy lifting stuff. To fulfill that purpose alone, one need not to have super diverse ecosystem providing all kinds of libraries, just focus on a limited core functionality should suffice.
k__ 8y ago
Does this mean Facebook pulls its resources out of PHP? Weren't they THE big player that kept PHP alive in the last years?
- SwellJoe 8y ago
  PHP is still more widely deployed for small/medium websites than any other language. WordPress still powers more websites than any other single application, for example. Facebook was always an anomaly in supporting/using PHP at that scale. PHP was never a major player in very large companies...until facebook. I think this is a return to the mean, rather than a seismic shift in a new direction. That's not to say PHP isn't fading...it is. But, I don't think this is a huge hit to PHP.
  - k__ 8y ago
    I see. Last time I used it was 8 years ago and I had the impression it would have been gone by now if it wasn't for Facebook pouring money in it.
    - SwellJoe 8y ago
      A gazillion lines of code running on a few million servers has an inertia that takes more than a few years of stagnation to kill, even if newer languages get a lot more hype. There's still plenty of Perl in the wild, including in some pretty mission critical deployments, and Perl was declared dead 15 years ago (with PHP being the alleged killer). Likewise, millions of people still work in Java, C, C++, Ruby, and many others, despite there being newer languages with more momentum behind them. PHP will be around for years, even if there were never a new PHP project started from this day forward (but there will be new PHP projects started after today). So, sure, it's dying, but it's not dead yet and likely won't be for decades.
    - spdionis 8y ago
      What money is Facebook pouring into PHP? You think Facebook is deploying their own developers to maintain PHP? It is not so. Facebook doesn't really interact with the PHP community, except for when they published HHVM, and even that was limited.
giancarlostoro 8y ago
So who is using HHVM other than Facebook? Genuinly curious? Will be interesting to see where Hack goes altogether.
debacle 8y ago
I think this is a step in the right direction. PHP's refusal to break BC in the stdlib, among other things is probably the biggest impediment to the language being more widely accepted. By breaking compatibility with PHP, Hack is going to be able to adapt more quickly and create a stronger language. Hopefully, Facebook will have the wherewithal to promote Hack to PHP (and other) developers, and grow the ecosystem as it can.
- burnte 8y ago
  > PHP's refusal to break BC in the stdlib, among other things is probably the biggest impediment to the language being more widely accepted. PHP is one of the most widely used languages on the web. Their backward compatibility is absolutely part of that reason, too. Refusal to break compatibility may be holding it back in some technical areas, but it's certainly not hurting the language in popularity and use.
  - debacle 8y ago
    There's no reason not to break BC in 7.4. The people still running 5.3 aren't going to not upgrade to 7.4 because you fixed the array functions.
    - ars 8y ago
      That is a completely false sentence. People develop PHP sites, launch them and expect them to work, even if the server is upgraded to the latest PHP. Breaking their code on a PHP upgrade is a great way to strand them on old unsupported versions of PHP. Not everyone has resources to change things that used to work because of some "array function" change that doesn't really make any difference.
- andybak 8y ago
  > ... break BC in the stdlib ... (please don't abbreviate when it's unclear. You saving some typing means lots of people have to pause to parse your TLAs...)
TACIXAT 8y ago
I tried using hack once, spent a few days on it. It was a total disaster from a user-developer perspective. The documentation was poor and certain modules (the xhtml or equivalent module in particular) would not work due to versions or dependencies. If they are going to make a push they need to really make it easier to get up and running on.
kevinconaway 8y ago
From the outside looking in, the most interesting part of the post is the note about their new release cadence: > As we expect the language to evolve rapidly, we strongly recommend using the regular releases instead of the LTS releases for large projects; while this does mean you need to upgrade more often, both us and our users have found that it is generally easier to catch up on 2 months worth of changes 3 times as often than 6 months of changes in one go. We will also be re-evaluating the length of our release cycle; one possibility is that we will move to releases every 4 weeks, with these releases being supported for 6-8 weeks. That cycle will work for FB where they are constantly iterating and also have early insight as to where the language is going before they get there but for anyone on the outside or for slower moving projects, that cadence seems fairly punishing. Is that a big change from how they release now?
luord 8y ago
Another day, another weird dogmatic "static vs dynamic" discussion, with inaccurate comments like "the dynamic hype is dying", or "static is making a comeback" or "static is not really relevant anymore". Are people really that unfamiliar with the history of computer science? There's no hype, there's no comeback; both static and dynamic languages have existed for over six decades. Both styles have been around as long as computer science has been a thing and will continue to exist as long as programming is a thing.
- realharo 8y ago
  >both static and dynamic languages have existed for over six decades For a long time however, if you wanted a mainstream (well supported, large ecosystem) language with static typing, you pretty much had to deal with languages like Java or C++, with their pretty limited type systems and other unrelated design choices that may not appeal to you. It was either that, or going full dynamic. Or some niche language with poor library support. These days there are plenty of popular languages where you can get all the benefits of static typing with far fewer compromises (Kotlin, Swift, Rust, Scala, TypeScript, etc.) AND a more expressive type system. So the field has definitely changed.
  - deleted 8y ago
    [deleted]
  - tabtab 8y ago
    Kotlin, Swift, Rust, Scala, and TypeScript still have small user bases. Java, C#, and C++ are the most prominent static-typed/compiled languages. I see no evidence the first 5 listed are eating into say Python, PHP, and JavaScript.
  - norswap 8y ago
    The type system of Kotlin is pretty much the same as that of Java (the only addition is that of declaration-site variance, which essentially allows you to elide some of these annoying wildcards at the use-site). I'm not familiar enough with the others, but I have A LOT of doubts. Only Scala's type system is clearly more powerful/expressive than Java. Also, through templating, C++ type system is made quite expressive.
codr4 8y ago
Static/dynamic is obviously a gradient. I find it a bit sad that it always seems to be either or these days, either no types or a full blown static generic type system. I'm all for the ability to type variables and functions, as long as I'm still allowed to be exactly as precise as I feel like. Many would call that static typing, since there are types in the code that the compiler consumes. But my own attempts [0] at building such languages tell me that the result is still more dynamic than most. [0] https://github.com/codr4life/snabl https://github.com/codr4life/snabl
sigi45 8y ago
Aaand Hack ist dead. At least for everyone outside fb. Not sure why fb even made it public. First baiting everyone by switching and now having full control. Not sure who would risk that dependency.
- detaro 8y ago
  Do you mean HHVM or Hack?
  - sigi45 8y ago
    Both
sebastianavina 8y ago
Sincere question, but PHP is still widely used? I remember that around the year 2002 it was almost the only choice (besides Perl) on shared hosting, but on this days its just a nasty language and with so many beautiful languages like Python GoLang and Ruby why would anyone use PHP for a new development?
- dieulot 8y ago
  Yes, and it keeps growing: https://w3techs.com/technologies/history_overview/programming_language/ms/y https://w3techs.com/technologies/history_overview/programmin...

429 points by dcgudeman 8y ago

deleted 8y ago

[deleted]

Hmm, I don't really get it. But I suppose I don't really know if I bought the value proposition of HHVM in the first place.

smsm42 8y ago
hhvm had some performance advantages over PHP 5. They are largely gone with PHP 7 AFAIK.
- alexandercrohde 8y ago
  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.
jchw 8y ago
Since PHP picked up the slack, diverging from it makes complete sense. When HHVM was released, PHP's implementation had a ton of issues, but now it's doing a lot better. However, even with PHP 7, the language itself is still riddled with confusing behaviors that will likely remain for a long time. They may as well break away from the cost of maintaining backwards compatibility and leave that to PHP, while they fix deep issues with the language and add features like typing. I still don't see myself using it, but it seems like a reasonable path forward for someone who wants to modernize a large PHP codebase and would like features like type safety.
ksec 8y ago
HHVM and the work of Hack is what made PHP Great again. ( Or more like bearable ) PHP 7 along with laravel can get you some insane development speed. And I argue Hack, and PHP7 is actually want made PHP's downfall stabilise. The community saw their ecosystem has a way going forward and more improvements to come. Rewriting your app in different languages and frameworks is hard, no sane person wants to do it.

sdfb 8y ago

php is amazing!

alexandercrohde 8y ago
I think PHP is interchangeable with PHP, ROR, and node (i.e. give me a line in any of them, and there's a one-liner in the other to do the same thing) [this wouldn't be true for something like Scala]. So, presumably for the same reason somebody would do a project in ROR.
- sdfb 8y ago
  php stands out for being extremely simple to use for new comers
  - jadell 8y ago
    You can do event-driven and non-blocking IO in PHP. Check out a library like ReactPHP.
  - Lazare 8y ago
    There's a ton of basic CRUD apps and REST APIs being written in node for which the event-driven model is useless at best, and actively harmful at worst. Looking around at actual production node code, huge swathes of it could easily be written in Rails, Django, or Symfony with no real loss of performance or developer productivity. (And given the maturity of those ecosystems, probably a net gain in developer productivity. Example: ORMs aren't great at everything, but sometimes they save you a lot of time, and Node doesn't have an ORM that can compare to ActiveRecord, Doctrine, or SQLAlchemy.)
    - outside1234 8y ago
      CRUD is literally what node.js is built for - lightweight APIs that then have to do some slow operation async against a store - which they overlap requests across with an event-driven model

crispytx 8y ago

Diverging from PHP was a good move as PHP 7 has largely caught up with HHVM in terms of speed. That's really neat that Facebook invented their own language to meet their needs. Will have to mess around with it further sometime.

jaytaylor 8y ago
Agreed, Hack appears to be a move to fork into a PHP-esque language that FB engineering feels will be better for their software lifecycle goals and needs: - Handle numeric boundary cases in a more intuitive way. - Is Typed. - Replace reference parameters in favor of a new keyword, "inout". - Change package management and testing framework to be less annoying and more streamlined. This will be yarn (from npm, as in the one written in Javascript), and their own custom flavor of testing framework, hh-test, to replace PHPUnit. I wonder how many existing open-source PHP projects will remain compatible with HHVM? The post seems to indicate compatibility will not be a priority and that it's a fully breaking change. If this is true, it seems the "empty cocktail room" effect will be a major challenge and problem. Jane: "Hey, you can do this project in PHP or Hack." Alice: "Okay, I'll go with PHP because there's already a shitton of good libraries that might be useful to me or that I already know." I.e. Why would you use a language with few open source libraries over a very similar language with exponentially more? When I want types, I can already use Go, Java, or even Typescript, just to name a few terrific options. These days it seems like a no-brainer to me. The effort seems like a lot of trouble to go to just to shave off some annoyances / "rogue hairs". Curious if there's an angle I'm missing. One argument for making it an open-source language / project and trying to eventually grow it could be so FB can more easily hire folks who are already know the Hack language. Marke: "I'll do it in Hack because my only dream is to work at Facebook!" May not be that many Marke's out there.
- eganist 8y ago
  > Why would you use a language with few open source libraries over a very similar language with exponentially more? Fewer unvetted libraries from a security and code quality angle. Not saying it's good from a general engineering angle, but in an environment like Facebook which can afford to over-engineer, the third party dependency risk mitigation is a good side effect. But my argument here is a pretty polarizing one as it implies security-through-obscurity. I promise I'm not; I'm just pragmatic about how many abandoned or poorly maintained open source libraries end up being relied-upon regardless of how that challenge is solved-for in CI/CD.

aasasd 8y ago

Welp, so much for “PHP has JIT too.”

singlow 8y ago
The official PHP JIT branch is nearing release which would have made HHVM less relevant. I think it is expected to be in 8.0, whenever that hits.
- mgkimsal 8y ago
  My understanding is that a PHP 8, as it stands right now, is looking like Nov 2020.
ehnto 8y ago
They increased performance of the language enough that it caught up to HHVM. PHP7 is wildly faster than previous PHP versions. In other words, HHVMs value proposition of speed is no longer as relevant. PHP is still working on a JIT implementation but I honestly don't think it's that important for now.
- postalrat 8y ago
  In my experience HHVM is still quite a bit faster once it gets going.
- kyriakos 8y ago
  Due to the short lived nature of PHP requests JIT compilation wont be as effective as one would expect. Still though since php 7,every point release saw a measurable performance improvement.
thawkins 8y ago
PHP 7 has Zend OPtimizer built in, basically a caching bytecode compiler. Previous versions used to use the APC extension to serve the same purpose.
- 8y ago

wprapido 8y ago

With PHP7, HHVM became largely irrelevant. It had played a great role and contributed to the PHP's maturing immensely though!

mastazi 8y ago
Rasmus Lerdorf actually acknowledged HHVM's role in numerous occasions, especially with reference to the development of PHP7 (Edit: sorry I tried to find a link but no luck so far).
aylmao 8y ago
I mean, I think people are somewhat missing the fact that it's not like these worlds are separate or competing. Some people have worked on both PHP and HHVM, and it seems like they've always acknowledged that they have different goals. From the comments in the post of the Hack announcement (before PHP7): Q: Do you imagine a future where Hack will merge back into PHP (like PHP 7), in the same style that Beryl & Compiz then rejoined? Or does the team intend for the two to always be adjacent-yet-separate? A: HHVM developer & PHP runtime developer here. I've got hands in both runtimes and all even I can say is: Maybe. I think the most likely outcome is that PHP will adopt some of HHVM's additional features, but remain a separate project. IMO that's a great outcome, since we'll both likely drive the other to be better. EDIT: Source, https://news.ycombinator.com/item?id=7436557 https://news.ycombinator.com/item?id=7436557
hobofan 8y ago
Yeah, at a previous job we used Hack around the time PHP7 was released and switched over to PHP7 pretty quickly. Performance and type checking were the only benefits over PHP5 and with those (mostly) gone, you were just left with all the downsides like all the good tooling for PHP being incompatible with Hack and, and general compiler/interpreter errors that were never getting fixes.
icc97 8y ago
HHVM can be more experimental than PHP so there's still potential that new features in HHVM get considered and merged into PHP, kind of like Fedora/Redhat or Neovim/Vim
8y ago

kijin 8y ago

I wonder how this will affect major websites outside of Facebook that rely on HHVM, such as Wikipedia. They made a big announcement when they switched to HHVM in early 2015. Have they moved over to PHP 7 yet?

lathiat 8y ago
They are planning to move to PHP7 largely because of this change but also since PHP7 closed the performance gap: https://phabricator.wikimedia.org/T176370 https://phabricator.wikimedia.org/T176370
beberlei 8y ago
A reminder, HHVM is not Hack. you can run both type of scripts with either <?php or <?hh. Wikpedia is <?php because its underlying MediaWiki is PHP and used outside by many companies. As such a migration of Wikipedia to PHP 7 is probably mostly an ops and not a software task.

muglug 8y ago

I don't think there are enough backend web developers in the world to support vibrant communities for both PHP and Hack. Unless Facebook's prepared to invest a lot in community-building, Hack and similar FB projects will go the way of VBScript and Silverlight.

iodiniemetra 8y ago
hack is going to become incredibly widespread before slowly dying off due to market forces?
- arcticbull 8y ago
  You could argue that it already did become incredibly widespread (as php) then died off slowly due to market forces.
  - CleanShirt 8y ago
    I wouldn’t say Hack was ever popular as a language. The HHVM certainly had popularity as a runtime for PHP until the speed increase of PHP7.
- elaus 8y ago
  I seriously can't remember any (incredibly) widespread use of Silverlight – could you elaborate? The only instance I noticed it was with a video streaming platform.
  - hiram112 8y ago
    I don't think Silverlight had a mass amount of public use (Flash and Applets were still available at the time - so there was no pressing need). But MS really did earn a lot of bad will from their dev community who had been pushed to learn yet another framework which ended up dead. I rarely even use my PC anymore. I basically then it on once a month to download the gigs of updates. It's interesting that Silverlight still listed at the top of optional updates. There must be a few businesses and schools who bought into the hype and built their internal app on SL.

deleted 8y ago

[deleted]

dsign 8y ago

Duly noted the desire of Hack to have more "typing". It seems that as soon as projects growth beyond a certain size, everybody starts wanting to add that. I wonder what would be the optimal lifecycle for long projects. Obviously, "start with dynamic language X until you reach 10^n lines of code, then fork X and add types to it" doesn't work for smaller companies :-(

vnorilo 8y ago
A similar strategy on a smaller scale could be gradual typing, for example Typescript. For me personally, clojure + spec seems very inviting.
- wpietri 8y ago
  Yeah, I'm really excited to see people exploring gradual typing. Like dsign, I've noticed that I really like flexible languages like Ruby and Python for early work, but once something is big enough, I start to miss the things heavier languages give. I'm sure it will take us a decade to work it out, but it'll be fun getting there.
- nickserv 8y ago
  Indeed, this seems to be the best way for a small code base that gradually grows in scope and criticality. It allows rapid development early on and better stability later in the project. I'm really glad that Python is making good progress on this front.
exacube 8y ago
i personally started to find dynamically/optionally typed languages troublesome to read -- i have to do type deduction in my head, which just feel burdensome. as simple and easy as python feels without static typing, a handful of files of python is my tolerance level before i start to hate it
- jacquesm 8y ago
  Yep. A lack of typing puts an upper bound on the complexity of the code that effectively limits the line-count and relegates the language to 'glue' status. The reason is simple: typing functions as guard rails and guard rails are what keep you safe on the road when you are driving for 1000's of km. They have no function if you just putter about town at low speed. High line count projects almost always gravitate towards languages with such safeguards built in because otherwise the accumulation of subtle errors leads to too many runtime issues, and typing takes care of whole classes of bugs. IMO any mechanism that shifts that time of bug catching to development rather than operations should be preferred, ditto for any mechanism that forces a program to end when an undefined situation is detected, the closer to the root cause the better.

jrs95 8y ago

This is bad news for Slack, I would think. I believe they went all in on HHVM + Hack, which is going to be increasingly incompatible with 3rd party packages now.

yurishimo 8y ago
Is it possible they could find inefficiencies in their codebase to make up the performance difference with regular PHP? Or maybe they'll just need to add more servers to make up the difference?
- aylmao 8y ago
  Adding more servers stops being a good option after a certain point. If you're a small company running on 20 servers you can increase your performance by 5% if you add just one more. Install it in one day, boom. If you're running on 200,000 servers, a 5% increase is 10,000 servers. That means opening a new building in your data-center, making sure your recruiting team has resources to hire enough staff for it, then hiring that staff, negotiating contracts with the power company, the component suppliers, building permits, hopefully you have enough network capacity otherwise you'll have to expand that too, etc. It's many months of work and a lot more expensive than hiring a handful of engineers to tackle performance and maybe build some libraries in-house.
nitram1 8y ago
I think it depends on whether the improvements facebook hopes to achieve by dropping support for php outweigh the drawbacks of losing 3rd party package compatibility
dtech 8y ago
Depends on how feasible a Hack -> PHP7 transition would be.
- jrs95 8y ago
  If it was just typing it would be easy. If it's Hack collections and async/await...not easy at all

komodosquirrel 8y ago

If they fix problems of PHP and drop backwards compatibility if needed, I am all in.

erikb 8y ago

Wasn't HHVM created as compiler or interpreter for PHP?

anticensor 8y ago
Yes but they added so much features that the core became hard to maintain.

tscherno 8y ago

Poor Wikipedia will need to migrate back to php7 runtime which still could be complex despite of language compatibility.

kreetx 8y ago
Interestig fact that Wikipedia runs on hhvm! But I guess since php7 appears to be as fast if not faster nowdays then it's probably the right move anyway.
- Washuu 8y ago
  MediaWiki has to support PHP 7 for the community of wikis outside Wikipedia that use it. If they dropped PHP 7 support they would be making MediaWiki a bit of an insular project.
  - debacle 8y ago
    Or Facebook could sponsor their development on hhvm and use that to promote hack lang.
    - Washuu 8y ago
      Then every single third party extension developer would also have to move to Hack. Knowing what I know about certain extension developers that will never happen and a hard fork of MediaWiki will occur.
beberlei 8y ago
Wikipedia was always a PHP software and just running on HHVM for the performance gain, not for the Hack language. The underlying MediaWiki software is used outside of Wikipedia a lot, always on the PHP not HHVM stack. I expect its only a project for their operations team and should be managable.
- piotrkubisa 8y ago
  Could you tell more about MediaWiki use-cases outside Wikipedia? I know there is a lot of open-source projects which has MediaWiki installed for documentation (i.e. Arch Linux). Are there any usage in "internal documentation" software (like alternative to Confluence)? Why they have chosen the MediaWiki not other software which can be easily self-hosted / deployed on a premise?

pritambarhate 8y ago

Do you think dynamic types was a mistake? Almost all popular dynamically typed languages have some sort of type hinting. All new promising languages have chosen to be statically typed.

fetbaffe 8y ago
No, the problem is not dynamic typing, the problem is enforcing contracts. With type hinting on function parameters like in PHP you can get the best of two worlds, flexibility & enforcing contracts.
joelbluminator 8y ago
javascript has no type hinting, there's typescript but tons of people use plain javascript. Same for python (tons of code was and is being written without hints). The same goes for ruby.
wasd884 8y ago
Dynamic types weren't a mistake, but they were overused IMO. It's technically scripting, not programming, but can you imagine if Bash files were type hinted? For small scripts, solo projects or quick fixes, dynamic typing is great because it's fast! On the flip side, large codebases should (on the whole) not use dynamic types because of all the safety they fail to provide! As you said, most dynamically typed languages are moving towards some sort of type hinting and that's because high quality developers demand it when working on medium to large projects.
- strzibny 8y ago
  > It's technically scripting, not programming Nope. Dynamic types have nothing to do with scripting vs programming. What a nonsense! Sorry I had to:).
  - wasd884 8y ago
    You misunderstood me. I agree that scripting and programming have nothing to do with dynamic types. > It's technically scripting, not programming, but can you imagine if Bash files were type hinted? I was clarifying that writing Bash files was scripting and not programming.

ape4 8y ago

I would have liked "Hack" to be some play on "PHP". Maybe "HPH". PHP++ or PHPPP

deleted 8y ago

[deleted]

m_st 8y ago

Article from Marco Arment about exactly this, from 2014. https://marco.org/2014/03/21/hack https://marco.org/2014/03/21/hack

Nitramp 8y ago

It's interesting to see this, and curious if you look at it from an organizational decision making standpoint. Hypothetically, because I'm not involved in any of this, but still: Facebook was initially implemented using PHP, and you can read this process as continued iteration based on this very early decision. From the outside, Facebook seems to have always taken what they had, taken the problems they currently had, and made the most incremental change they could to fix whatever problem they had. From PHP to HHVM to Hack to dropping PHP support, they continued iterating on what code base and development chain they currently had. If you take a step back though, Facebook is gradually moving to a different programming environment, from a dynamic language with very loose semantics to a statically typed system with (from code I've seen in e.g. phabricator) a very different programming style than run of the mill PHP. While iterating incrementally, they still ended up forking PHP and moving to a different language. The approach is quite different from e.g. Twitter though, who started off using Ruby on Rails, and then moved everything to an entirely different tool chain (Scala) when they found Rails couldn't hold up with their problem set. This difference in approaches isn't quite the same as the good old "rewrite vs refactor" dichotomy. Twitter's change was certainly incremental too, moving individual services to Scala bit by bit, setting them live incrementally instead of a "big bang" rewrite where everything moves to Scala one day. I think the main difference is planning horizon: do you opportunistically fix whatever is broken right now, or do you make a long term plan on what you want your future platform to be, and then set out to get there? Opportunistic fixing has the advantage that you can be pretty certain you're fixing the right problem, and don't invest in YAGNI features. On the other hand, you risk ending up in local optima. Pouring a lot of effort into PHP makes sense if you plan to continue using it - but if you end up forking the language anyway, you loose a lot of the advantages of a shared ecosystem (and arguably damage the existing ecosystem in the process through fragmentation). You could equally well imagine Facebook picking a different future tech stack five years ago, be it Rust or Go or whatever, and add the features they miss from PHP to it. I think it's an interesting thought experiment where that'd have taken them. I have no idea if taking that path would have been better for any of {Facebook, PHP, target language X, world}.

SwellJoe 8y ago
Very few entities have the resources that do what Facebook (or Google or Microsoft) have done, in creating an entire new language (or languages) that suit their particular needs, and in a relatively short time (hack was being used within facebook very quickly). Twitter certainly doesn't have those kinds of resources, but they do/did have the resources to migrate to a language with an existing developer community and existing tooling.

oh-kumudo 8y ago

Which makes sense. Facebook now is big enough to sustain a programming language on its own. And for Hack, I would assume it mainly to replace where the PHP used to be, which is a shallow API composition layer, no heavy lifting stuff. To fulfill that purpose alone, one need not to have super diverse ecosystem providing all kinds of libraries, just focus on a limited core functionality should suffice.

k__ 8y ago

Does this mean Facebook pulls its resources out of PHP? Weren't they THE big player that kept PHP alive in the last years?

SwellJoe 8y ago
PHP is still more widely deployed for small/medium websites than any other language. WordPress still powers more websites than any other single application, for example. Facebook was always an anomaly in supporting/using PHP at that scale. PHP was never a major player in very large companies...until facebook. I think this is a return to the mean, rather than a seismic shift in a new direction. That's not to say PHP isn't fading...it is. But, I don't think this is a huge hit to PHP.
- k__ 8y ago
  I see. Last time I used it was 8 years ago and I had the impression it would have been gone by now if it wasn't for Facebook pouring money in it.
  - SwellJoe 8y ago
    A gazillion lines of code running on a few million servers has an inertia that takes more than a few years of stagnation to kill, even if newer languages get a lot more hype. There's still plenty of Perl in the wild, including in some pretty mission critical deployments, and Perl was declared dead 15 years ago (with PHP being the alleged killer). Likewise, millions of people still work in Java, C, C++, Ruby, and many others, despite there being newer languages with more momentum behind them. PHP will be around for years, even if there were never a new PHP project started from this day forward (but there will be new PHP projects started after today). So, sure, it's dying, but it's not dead yet and likely won't be for decades.
  - spdionis 8y ago
    What money is Facebook pouring into PHP? You think Facebook is deploying their own developers to maintain PHP? It is not so. Facebook doesn't really interact with the PHP community, except for when they published HHVM, and even that was limited.

giancarlostoro 8y ago

So who is using HHVM other than Facebook? Genuinly curious? Will be interesting to see where Hack goes altogether.

debacle 8y ago

I think this is a step in the right direction. PHP's refusal to break BC in the stdlib, among other things is probably the biggest impediment to the language being more widely accepted. By breaking compatibility with PHP, Hack is going to be able to adapt more quickly and create a stronger language. Hopefully, Facebook will have the wherewithal to promote Hack to PHP (and other) developers, and grow the ecosystem as it can.

burnte 8y ago
> PHP's refusal to break BC in the stdlib, among other things is probably the biggest impediment to the language being more widely accepted. PHP is one of the most widely used languages on the web. Their backward compatibility is absolutely part of that reason, too. Refusal to break compatibility may be holding it back in some technical areas, but it's certainly not hurting the language in popularity and use.
- debacle 8y ago
  There's no reason not to break BC in 7.4. The people still running 5.3 aren't going to not upgrade to 7.4 because you fixed the array functions.
  - ars 8y ago
    That is a completely false sentence. People develop PHP sites, launch them and expect them to work, even if the server is upgraded to the latest PHP. Breaking their code on a PHP upgrade is a great way to strand them on old unsupported versions of PHP. Not everyone has resources to change things that used to work because of some "array function" change that doesn't really make any difference.
andybak 8y ago
> ... break BC in the stdlib ... (please don't abbreviate when it's unclear. You saving some typing means lots of people have to pause to parse your TLAs...)

TACIXAT 8y ago

I tried using hack once, spent a few days on it. It was a total disaster from a user-developer perspective. The documentation was poor and certain modules (the xhtml or equivalent module in particular) would not work due to versions or dependencies. If they are going to make a push they need to really make it easier to get up and running on.

kevinconaway 8y ago

From the outside looking in, the most interesting part of the post is the note about their new release cadence: > As we expect the language to evolve rapidly, we strongly recommend using the regular releases instead of the LTS releases for large projects; while this does mean you need to upgrade more often, both us and our users have found that it is generally easier to catch up on 2 months worth of changes 3 times as often than 6 months of changes in one go. We will also be re-evaluating the length of our release cycle; one possibility is that we will move to releases every 4 weeks, with these releases being supported for 6-8 weeks. That cycle will work for FB where they are constantly iterating and also have early insight as to where the language is going before they get there but for anyone on the outside or for slower moving projects, that cadence seems fairly punishing. Is that a big change from how they release now?

luord 8y ago

Another day, another weird dogmatic "static vs dynamic" discussion, with inaccurate comments like "the dynamic hype is dying", or "static is making a comeback" or "static is not really relevant anymore". Are people really that unfamiliar with the history of computer science? There's no hype, there's no comeback; both static and dynamic languages have existed for over six decades. Both styles have been around as long as computer science has been a thing and will continue to exist as long as programming is a thing.

realharo 8y ago
>both static and dynamic languages have existed for over six decades For a long time however, if you wanted a mainstream (well supported, large ecosystem) language with static typing, you pretty much had to deal with languages like Java or C++, with their pretty limited type systems and other unrelated design choices that may not appeal to you. It was either that, or going full dynamic. Or some niche language with poor library support. These days there are plenty of popular languages where you can get all the benefits of static typing with far fewer compromises (Kotlin, Swift, Rust, Scala, TypeScript, etc.) AND a more expressive type system. So the field has definitely changed.
- deleted 8y ago
  [deleted]
- tabtab 8y ago
  Kotlin, Swift, Rust, Scala, and TypeScript still have small user bases. Java, C#, and C++ are the most prominent static-typed/compiled languages. I see no evidence the first 5 listed are eating into say Python, PHP, and JavaScript.
- norswap 8y ago
  The type system of Kotlin is pretty much the same as that of Java (the only addition is that of declaration-site variance, which essentially allows you to elide some of these annoying wildcards at the use-site). I'm not familiar enough with the others, but I have A LOT of doubts. Only Scala's type system is clearly more powerful/expressive than Java. Also, through templating, C++ type system is made quite expressive.

codr4 8y ago

Static/dynamic is obviously a gradient. I find it a bit sad that it always seems to be either or these days, either no types or a full blown static generic type system. I'm all for the ability to type variables and functions, as long as I'm still allowed to be exactly as precise as I feel like. Many would call that static typing, since there are types in the code that the compiler consumes. But my own attempts [0] at building such languages tell me that the result is still more dynamic than most. [0] https://github.com/codr4life/snabl https://github.com/codr4life/snabl

sigi45 8y ago

Aaand Hack ist dead. At least for everyone outside fb. Not sure why fb even made it public. First baiting everyone by switching and now having full control. Not sure who would risk that dependency.

detaro 8y ago
Do you mean HHVM or Hack?
- sigi45 8y ago
  Both

sebastianavina 8y ago

Sincere question, but PHP is still widely used? I remember that around the year 2002 it was almost the only choice (besides Perl) on shared hosting, but on this days its just a nasty language and with so many beautiful languages like Python GoLang and Ruby why would anyone use PHP for a new development?

dieulot 8y ago
Yes, and it keeps growing: https://w3techs.com/technologies/history_overview/programming_language/ms/y https://w3techs.com/technologies/history_overview/programmin...