Slack uses PHP for most of its server-side application logic, which is an unusual choice these days. Why did we choose to build a new project in this language? Should\u00a0you?<\/p>\n
Most programmers who have only casually used PHP know two things about it: that it is a bad language, which they would never use if given the choice; and that some of the most extraordinarily successful projects in history use it. This is not quite a contradiction, but it should make us curious. Did Facebook, Wikipedia, WordPress, Etsy, Baidu, Box, and more recently Slack all succeed in spite of<\/em> using PHP? Would they all have been better off expressing their application in Ruby? Erlang?\u00a0Haskell?<\/p>\n Perhaps not. PHP-the-language has many flaws, which undoubtedly have slowed these efforts down, but PHP-the-environment has virtues which more than compensate for those flaws. And the options<\/a> for improving on PHP\u2019s language-level flaws are pretty impressive<\/a>. On the balance, PHP provides better support for building, changing, and operating a successful project than competing environments. I would start a new project in PHP today, with a reservation or two, but zero apologies.<\/p>\n Uniquely among modern languages, PHP was born in a web server<\/strong>. Its strengths are tightly coupled to the context of request-oriented, server-side execution.<\/p>\n PHP originally stood for \u201cPersonal Home Page<\/a>.\u201d It was first released in 1995 by Rasmus Lerdorf, with an aim of supporting small, simple dynamic web applications, like the guestbooks and hit counters that were popular in the web\u2019s early\u00a0days.<\/p>\n From PHP\u2019s inception, it has been used for far more complicated projects than its creators anticipated. It has been through several major revisions, each of which brought new mechanisms for wrangling these more complex applications. Today, in 2016, it is a feature-rich member of the Mixed-Paradigm Developer Productivity Language (MPDPL<\/em>) family[<\/strong>1<\/strong><\/a>]<\/strong>, which includes JavaScript, Python, Ruby, and Lua. If you last touched PHP in the early \u2018aughts, a contemporary PHP codebase might surprise you with traits<\/a>, closures<\/a>, and generators<\/a>.<\/p>\n PHP gets several things very deeply, and uniquely, right.<\/p>\n First, state<\/strong>. Every web request starts from a completely blank slate. Its namespace and globals are uninitialized, except for the standard globals, functions and classes that provide primitive functionality and life support. By starting each request from a known state, we get a kind of organic fault isolation; if request t<\/em> encounters a software defect and fails, this bug does not directly interfere with the execution of subsequent request t+1<\/em>. State does reside in places other than the program heap, of course, and it is possible to statefully mess up a database, or memcache, or the filesystem. But PHP shares that weakness with all conceivable environments that allow persistence. Isolating request heaps from one another reduces the cost of most program\u00a0defects.<\/p>\n Second, concurrency<\/strong>. An individual web request runs in a single PHP thread. This seems at first like a silly limitation. But since your program executes in the context of a web server, we have a natural source of concurrency available: web requests. Asynchronously curl\u2019ing to localhost (or even another web server) provides a shared-nothing, copy-in\/copy-out way of exploiting parallelism. In practice, this is safer and more resilient to error than the locks-and-shared-state approach that most other general-purpose languages provide.<\/p>\n Finally, the fact that PHP programs operate at a request level means that programmer workflow<\/strong> is fast and efficient, and stays fast as the application changes. Many developer productivity languages claim this, but if they do not reset state for each request, and the main event loop shares program-level state with requests, they almost invariably have some startup time. For a typical Python application server, e.g., the debugging cycle will look something like \u201cthink; edit; restart the server; send some test requests.\u201d Even if \u201crestart the server\u201d only takes a few seconds of wall-clock time, that takes a big cut of the 15\u201330 seconds<\/a> our finite human brains have to hold the most delicate state in\u00a0place.<\/p>\n I claim that PHP\u2019s simpler \u201cthink; edit; reload the page\u201d cycle makes developers more productive. Over the course of a long and complex software project\u2019s life cycle, these productivity gains compound.<\/p>\n If all of the above is true, why all the hate<\/a>? When you boil the colorful hyperbole away, the most common complaints about PHP cluster around these root\u00a0causes:<\/p>\n Lest I seem like an unreflective PHP apologist: these are all serious problems that make defects more likely<\/strong>. And they\u2019re unforced errors. There\u2019s no inherent trade-off between the Good Parts of PHP and these problems. It should be possible to build a PHP that limits these downsides while preserving the good\u00a0parts.<\/p>\n That successor system to PHP is called\u00a0Hack<\/a>[<\/strong>3<\/strong><\/a>]<\/strong>.<\/p>\n Hack is what programming language people call a \u2018gradual typing system<\/a>\u2019 for PHP. The \u2018typing system\u2019 means that it allows the programmer to express automatically verifiable invariants about the data that flows through code: this function takes a string and an integer and returns a list of Fribbles, just like in Java or C++ or Haskell or whatever statically typed language you favor. The \u2018gradual\u2019 part means that some parts of your codebase can be statically typed, while other parts are still in rough-and-tumble, dynamic PHP. The ability to mix them enables gradual migration of big codebases.<\/p>\n Rather than spill a ton of ink here describing Hack\u2019s type system and how it works, just go play with it<\/a>. I\u2019ll be here when you get\u00a0back.<\/p>\n It\u2019s a neat system, and quite ambitious in what it allows you to express. Having the option of gradually migrating a project to Hack, in case it grows larger than you first expected, is a unique advantage of the PHP ecosystem. Hack\u2019s type checking preserves the \u2018think; edit; reload the page\u2019 workflow, because the type checker runs in the background, incrementally updating its model of the codebase when it sees modifications to the filesystem. The Hack project provides integrations with all the popular editors and IDEs so that the feedback about type errors comes as soon as you\u2019re done typing, just like in the web\u00a0demo.<\/p>\n Let\u2019s evaluate the set of real risks that PHP poses in light of\u00a0Hack:<\/p>\n Hack provides an option that no other popular member of the MPDPL family has: the ability to introduce a type system after initial development, and only in the parts of the system where the value exceeds the\u00a0cost.<\/p>\n Hack was originally developed as part of the HipHop Virtual Machine<\/a>, or HHVM, an open source JIT environment for PHP. HHVM provides another important option for the successful project: the ability to run your site faster and more economically. Facebook reports<\/a> an 11.6x improvement in CPU efficiency over the PHP interpreter, and Wikipedia<\/a> reports a 6x improvement.<\/p>\n Slack recently migrated its web environments into HHVM, and experienced significant drops in latency for all endpoints, but we lack an apples-to-apples measurement of CPU efficiency at this writing. We\u2019re also in the process of moving portions of our codebase into Hack, and will report our experience here.<\/p>\n We started with the apparent paradox that PHP is a really bad language that is used in a lot of successful projects. We find that its reputation as a poor language is, in isolation, pretty well deserved. The success of projects using it has more to do with properties of the PHP environment<\/em>, and the high-cadence workflow it enables, than with PHP the language. And the advantages of that environment (reduced cost of bugs through fault isolation; safe concurrency; and high developer throughput) are more valuable than the problems that the language\u2019s flaws\u00a0create.<\/p>\n Also, uniquely among the MPDPLs, there is a clear migration path to a higher performance, safer and more maintainable medium in the form of Hack and HHVM. Slack is in the later stages of a transition to HHVM, and the early stages of a transition to Hack, and we are optimistic that they will let us produce better software, faster.<\/p>\n\t\tBackground<\/h2>\n
Virtues of\u00a0PHP<\/h2>\n
The Case Against\u00a0PHP<\/h2>\n
\n
HHVM and\u00a0Hack<\/h2>\n
\n
HHVM<\/h2>\n
Looking Ahead<\/h2>\n