展开查看详情
1 .Hack for HHVM Converting Facebook Julien Verlaguet Software Engineer
2 .Facebook A 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 quickly
3 .PHP: how it all started! FAST
5 .Hack A 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 )
7 .Hack Types All PHP types: int , MyClassName , array Nullable: ?int , ?MyClassName Mixed: 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): T
8 .Hack We 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 files Keeps track of the dependencies Recomputes types when something changed
9 .Question Can we convert millions of lines?
10 .Prerequisites for conversion Address concerns regarding static-typing Have a backup plan Zero friction for developers (they can always bail out) Automated conversion
11 .T he concerns Too slow! Too verbose! Bad error messages! Not flexible enough!
12 .Hack: you have nothing to lose! Too slow! Response time < 200ms Too verbose! Types are inferred Bad error messages! Error messages tell you how to solve the problem Not flexible enough! It’s gradually typed
13 .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 fail
14 .Different modes <? hh // strict If all the code is strict then it’s sound <? hh Dynamic code is assumed to be correct <? hh // decl Don’t check the code, only consider definitions // UNSAFE Trust me: I am an engineer!
16 .Error messages You can try it online: http:// hacklang.org
17 .The rules If the entire code is strict, the code is type-safe Adding an annotation should never force you to add another Removing an annotation should never introduce an error Simple mental model Be “dumb” by default Scale
18 .Conversion strategy: tighten the belt Convert everything to <? hh Add annotations gradually Build awareness More coverage for tools The problems: Gives a false sense of security Refactoring tools not really usable
19 .Tighten the belt A global type-inference system to “guess” annotations A monitoring system to detect mistakes Refactoring tools to remove (or harden) annotations
21 .Question: can we scale this? C onstant refactoring for language changes became a habit!
22 .Let’s go back to the 90s
24 .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”
25 .Can we do the same with programming languages?
26 .The Facebook conversion Large enough / S mall enough Lesson 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 advantage
27 .The future of Hack Collaborate with the open-source community Tune the experience Provide more tools (IDE) Carry-on improving the language Make our own codebase more and more strict
热门城市
