Julien Verlaguet Software Engineer Facebook A large PHP codebase gt 10M lines Thousands of engineers Performance matters HipHop HHVM The development cycle is fast w e push twice a day ID: 737359
Download Presentation The PPT/PDF document "Hack for HHVM Converting Facebook" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Hack for HHVMConverting Facebook
Julien Verlaguet
Software
EngineerSlide2
FacebookA large PHP codebase (> 10M lines)
Thousands of engineers
Performance matters! (
HipHop
, HHVM)
The development cycle is fast:
w
e push
twice a day
!
PHP is a good technical choice to iterate quicklySlide3
PHP: how it all started!
FASTSlide4Slide5
HackA statically typed
language for
HHVM
Compatible with PHP:
Interoperates with no overhead
Same representation at runtime
Instantaneous type-checking
Designed
for incremental adoption
:Gradual typing
Allows different “modes” (strict, partial, decl)Slide6
A simple exampleSlide7
Hack TypesAll PHP types: int,
MyClassName
,
array
Nullable:
?int
,
?MyClassNameMixed: anything (careful)
Tuples: (int, bool, X)
Closures: (function(int): int)Collections:
Vector<int>, Map<string, int>Generics:
A<T>
,
foo<T>(T $x): T
Constraints:
foo<T as A>(T $x): TSlide8
HackWe knew we wanted an IDE from day one:
Usually, the IDE and the type-checker are distinct entities
Hack is both a type-checker and an IDE
The type-checker is a server (
hh_server
)
:
The server type-checks all the filesKeeps track of the dependencies
Recomputes types when something changedSlide9
QuestionCan we convert millions of lines?Slide10
Prerequisites for conversionAddress concerns regarding static-typing
Have a backup plan
Zero friction for developers (they can always bail out)
Automated conversionSlide11
The concernsToo slow!Too verbose!Bad error messages!Not flexible enough!Slide12
Hack: you have nothing to lose!Too slow!Response time < 200msToo verbose!Types are inferredBad error messages!Error messages tell you how to solve the problemNot flexible enough!It’s gradually typedSlide13
When things go wrong?We are always strictly MORE restrictive
In the type-checker:
Removing a type-annotation never introduces an error
Removing a type-annotation never changes the behavior at runtime
At runtime:
We introduce new constructions distinct from the old ones
We make old constructions more warn or failSlide14
Different modes<?hh // strictIf all the code is strict then it’s sound<?hhDynamic code is assumed to be correct
<?
hh
//
decl
Don’t check the code, only consider definitions
// UNSAFETrust me: I am an engineer!Slide15
Gradual typingSlide16
Error messagesYou can try it online: http://hacklang.orgSlide17
The rulesIf the entire code is strict, the code is type-safeAdding an annotation should never force you to add anotherRemoving an annotation should never introduce an errorSimple mental modelBe “dumb” by default
ScaleSlide18
Conversion strategy: tighten the beltConvert everything to <?hhAdd annotations graduallyBuild awarenessMore coverage for toolsThe problems:Gives a false sense of securityRefactoring tools not really usable Slide19
Tighten the beltA global type-inference system to “guess” annotationsA monitoring system to detect mistakesRefactoring tools to remove (or harden) annotationsSlide20
Where are we at?Slide21
Question: can we scale this?Constant refactoring for language changes became a habit!Slide22
Let’s go back to the 90sSlide23
Release day (1999)Slide24
What happened?A cultural change (release early, release often)Tools (git, mercurial etc …)More code is visible (github etc …)
What use to be painful became easy
Thanks to a gradual process: every morning I “
git
rebase”Slide25
Can we do the same with programming languages?Slide26
The Facebook conversionLarge enough / Small enoughLesson learnt, programmers must be able to choose:When (find the right time to upgrade)How much? (the upgrade process must be incremental)Where? (They can leave the parts that they don’t care about)Sometimes, the opposite is true, flip a switch (return types)
Keep a simple mental model
Controlling the code is a
HUGE
unfair advantageSlide27
The future of HackCollaborate with the open-source communityTune the experienceProvide more tools (IDE)Carry-on improving the languageMake our own codebase more and more strictSlide28
Questions?