/
Hack for HHVM Converting Facebook Hack for HHVM Converting Facebook

Hack for HHVM Converting Facebook - PowerPoint Presentation

karlyn-bohler
karlyn-bohler . @karlyn-bohler
Follow
346 views
Uploaded On 2018-12-06

Hack for HHVM Converting Facebook - PPT Presentation

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

code type error int type code int error php hack annotation strict ide tools checker types gradual day runtime server messages release

Share:

Link:

Embed:

Download Presentation from below link

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.


Presentation Transcript

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!

FASTSlide4
Slide5

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?