{"id":11775,"date":"2020-04-14T09:35:53","date_gmt":"2020-04-14T09:35:53","guid":{"rendered":"https:\/\/slackhq.com\/engineering\/?p=11775"},"modified":"2023-11-21T22:31:45","modified_gmt":"2023-11-21T22:31:45","slug":"hacklang-at-slack-a-better-php","status":"publish","type":"post","link":"https:\/\/slack.engineering\/hacklang-at-slack-a-better-php\/","title":{"rendered":"Hacklang at Slack: A Better PHP"},"content":{"rendered":"

Slack launched in 2014 with a PHP 5 backend. Along with\u00a0several<\/a>\u00a0other<\/a>\u00a0companies<\/a>, we switched to\u00a0HHVM<\/a>\u00a0in 2016 because it ran our PHP code faster. We stayed with HHVM because it offers an entirely new language:\u00a0Hack<\/a>\u00a0(searchable as Hacklang).<\/p>\n

Hack makes our developers faster by improving productivity through better tooling. Hack began as a superset of PHP, retaining its\u00a0best parts<\/a>\u00a0like the edit-refresh workflow and request-oriented memory model that enable speedy development. In addition to a number of quality-of-life improvements, Hack adds a better type system and a static type checker, which help catch bugs and allow developers to code and refactor with more confidence.<\/p>\n

In this post we\u2019ll talk about how and why we migrated to Hack, the benefits it gave us, and things to consider for your own codebase.<\/p>\n

Static type checking is a game changer<\/h2>\n

PHP\u2019s type system has come a long way\u00a0since PHP 5<\/a>, when it was not possible to annotate return types,\u00a0class properties<\/a>, or scalar types. Its remaining holes, like the lack of\u00a0generics<\/a>, may be resolved in the future. But its biggest flaw is that types are only checked at runtime. This is the most costly time to find out about type-related bugs, either by breaking a test suite or worse \u2014 a user report or production error log.<\/p>\n

With Hack, type checking happens\u00a0statically<\/strong>\u00a0(without running the code) and\u00a0as you type<\/strong><\/a>.\u00a0<\/em>Change the signature of a function with hundreds of call sites, and you\u2019ll see errors for the ones that need updating before even hitting save.<\/p>\n

This is a\u00a0game changer<\/em><\/strong>\u00a0<\/em>for productivity \u2014 the difference between finding a bug milliseconds after typing compared to waiting for a comprehensive test suite (or finding out after deploying) is hard to overstate. It\u2019s akin to the productivity difference between developing websites in PHP vs. C. With Hack, you don\u2019t bother trying to run the code until the type checker is passing, and by then it usually\u00a0just works<\/em>. This allows Slack developers to build, and refactor, with confidence, focusing testing efforts on higher value areas like\u00a0logic bugs<\/strong>\u00a0which static typing can\u2019t help prevent.<\/p>\n

Static type checking is possible in PHP with\u00a0community<\/a>\u00a0packages<\/a>, and if you\u2019re using PHP I\u2019d strongly recommend using one of these. However, Hack\u2019s type checker has the advantage of a much more full-featured type system to work with. Hack is built from the ground up to enable static type checking, with features PHP lacks like\u00a0generics<\/a>,\u00a0shapes<\/a>,\u00a0enums<\/a>,\u00a0hack arrays<\/a>, and a well-typed\u00a0standard library<\/a>\u00a0to enable rigorous static analysis.<\/p>\n

Gradual typing enables a migration<\/h2>\n

We started with Hack in\u00a0partial mode<\/a>, which treats all untyped values as the \u201cany\u201d type, usable for any purpose. TypeScript takes the\u00a0same approach<\/a>. This enabled an incremental migration\u2014adding types over time. As files became fully typed, we changed them to the default\u00a0strict<\/em>\u00a0mode so that they stayed that way.<\/p>\n

Surprisingly, gradually adding types to a weakly-typed codebase made me\u00a0more thoughtful about type safety<\/strong>\u00a0than I ever was working in strongly-typed languages like Java or Go. Instead of a requirement to get the compiler to run, types were a conscious decision to add value to the codebase. We had to justify spending time adding types by observing how they changed our working lives. Some parts of the codebase were easy to type, but others required refactoring to enable type safety.<\/p>\n

Not only have we found and prevented bugs, but types serve as a form of in-line documentation that are\u00a0verifiable<\/strong>\u00a0(unlike comment blocks), helping everyone read and understand the code. They also serve as a\u00a0contract<\/strong>\u00a0between different parts of the codebase. This has been crucial to productivity in a large, shared codebase like Slack\u2019s backend.<\/p>\n

Hack\u2019s type system has one feature in particular, Shapes, that caught on like wildfire at Slack, and I believe it\u2019s the reason we never looked back once we introduced Hack to our codebase.<\/p>\n

Shapes help represent complex structures<\/h2>\n

PHP\u2019s\u00a0array<\/code>\u00a0type, bewilderingly, can act as both a list (an ordered set of values) and a map (a set of key value pairs) at the same time. Most programming languages use separate types for these. In my experience, this is an endless source of bugs in PHP code, especially as functions like\u00a0array_merge<\/code><\/a>\u00a0treat list-like and map-like arrays differently.<\/p>\n

Hack improves upon this by separating these into\u00a0different types\u00a0<\/a>and using\u00a0generics<\/a>\u00a0to describe the types of their keys and values. A list-like array containing strings is a\u00a0vec<string><\/code>, and a map-like array with string keys and integer values is a\u00a0dict<string, int><\/code>.<\/p>\n

But what about dicts that contain multiple types?<\/h2>\n

dict<string, mixed><\/code>\u00a0is a valid, but not particularly useful type annotation, which says the dict contains\u00a0string<\/code>\u00a0keys and values of\u00a0any<\/em>\u00a0type.<\/p>\n

Enter\u00a0shapes<\/a>. A\u00a0shape<\/code>\u00a0is an array that contains known keys with specific types. Keys may be optional if preceded by\u00a0?<\/code>. These example shape definitions represent the arguments of an http POST request, which has many optional fields:<\/p>\n

type http_post_options = shape(\n  ?'timeout' => int,\n  ?'port' => int,\n  ?'http_basic_auth' => string,\n  ?'headers' => dict<string, string>,\n  ?'form_data' => dict<string, string>,\n  ?'json_payload' => JsonSerializable,\n  ?'user_agent' => string,\n  ?'follow_redirects' => bool,\n);<\/code><\/pre>\n
This function signature uses that shape to type the\u00a0$options<\/code>:<\/p>\n
function http_post(\n  string $url,\n  http_post_options $options\n): http_response {\n  \/\/ ... implementation here\n}<\/code><\/pre>\n
A call site might look like this:<\/p>\n
$result = http_post('https:\/\/example.com', shape(\n  'timeout' => 10,\n  'form_data' => <em>dict<\/em>['example' => 'test'],\n));<\/code><\/pre>\n
Not only does this help ensure the correct types are used for each field, it also helps prevent typos for the names of keys both in the call site and in the function body where the shape is accessed. This makes the shape much more impactful to developer productivity than a simple\u00a0array<\/code>\u00a0type annotation. Before shapes, assembling a call to such a function would require reading its body or a large doc block (which may not be fully up to date) to understand the names, expected types, and \u201coptional vs. required\u201d status for each argument.<\/p>\n
Shapes are used for a variety of use cases at Slack, including:<\/p>\n