Like me, on Facebook

Posted on by

Well here’s something I never thought I’d write in Fabulous Adventures in Coding when I started this blog more than ten years ago:

Today is my first day at Facebook.

It still feels weird to say it. But as it turns out, Facebook has a language design team and they have very generously asked me to be a part of it.

Now perhaps it is clear why I have been working frantically to learn OCaml for the last couple of months; several of Facebook’s compilers are written in OCaml, and so I’m going to need to have a working knowledge of that language very quickly. I figured that writing a Z-machine interpreter (and, spoiler alert, a debugger) in OCaml might be a good way to get some practice in while waiting to start on the real thing! And I figured that learning F# and then having to un-learn all the ways in which F# differs from OCaml would not serve my interests.

It is still not entirely clear what exact aspects of developer tools I’ll be working on. Facebook has a lengthy and intensive “boot camp” process to get new hires up to speed, so I’ll be heads-down on that for the next eight weeks or so – which is another reason why I wanted to have a lengthy blog series already queued up.

Odds are pretty good that I’ll be working on the Hack compiler first; Hack is a gradually typed extension to PHP that looks remarkably like C#. I’ll post more – lots more! – once I have my feet under me here.

Another fabulous adventure! I can’t hardly wait!

43 thoughts on “Like me, on Facebook”

  5. Congratulations! I’m in week 5 of boot camp myself. If you’re ever in MPK and want to chat about the Z-machine or Inform, my calendar’s open. 🙂

    Reply ↓

  8. It would be interesting to read your perspective on working with what are concerned bad languages (PHP and JavaScript) after coming from one of the best designed mainstream languages. Satisfaction from working with something of quality vs satisfaction from beating a serious challenge. On the other hand you did work on jscript so it is probably not a new experience.

    Reply ↓

      • Interesting re: tooling. And from a language point of view – did you / are you finding it easy or hard making the transition to problem solving with things like ADTs, type inference, expressions rather than statements and so on having previously worked deeply in C# (and yes, C# has some of those features, but not to this extent)?

        Reply ↓

        • Pretty easy, but I’ve worked in a fairly functional style in C# for a long time. I am loving pattern matching. Type inference, I like how clean the code looks, and I like how most of the time, the error message is a nice “I expected this type, I got that type”. What I don’t like so much is how the error message is often far removed from the actual error; being able to see the chain of inference would be nice. And sometimes of course the error messages are quite long and complicated for something straightforward like a missing argument.

          Reply ↓

          • Yeah, that’s a common problem I have too, especially with curried functions. I find the quickest way to short-circuit these issues (at least in F#) is to put in a couple of explicit type annotations up the stack to give some temporary guidance to the compiler – that usually helps identify the issue a bit quicker.

          • I still remember leaning Prolog over 20 years ago at university, whatever error I made with types or spelling, the system just responded with “NO”. (Needless to say that due to the poor error messages from the Prolog compiler that UK universities could get cheaply, none of us had any inclination to every touch Prolog again. )

          • I’m about 1 year late to the discussion, but nonetheless …

            >What I don’t like so much is how the error message is often far removed from the actual error

            That is a fundamental problem with whole-program type-inference (and is one of the reasons why C♯ and Scala deliberately restrict themselves to local type inference, and why Haskell programmers advocate explicitly annotating all public interfaces and module boundaries): since the type inferencer “sees” all code at once, it can often chug along very far, inferring nonsense types, until it finally gets stuck with two types it just cannot reconcile at a place that is very far from where the *actual* (type) error happened.

            >being able to see the chain of inference would be nice

            I find it interesting that you say that, especially having previously (or would that be pre-previously now?) worked for a company that takes tooling *very* seriously, and even having worked *on* the tool. Martin Odersky made a similar observation a couple of years ago: languages with powerful type systems and type inference essentially allow you to run type-level programs at type-checking time. (In the case of Scala and Haskell, those programs are even Turing-complete! And even in C♯ we know thanks to you that overload resolution can solve 3-SAT. And let’s not even get into Template Metaprogramming in C++.) The type checker / type inferencer is essentially an interpreter for the type-level program.

            Yet, we don’t have any of the tools available for writing type-level programs that we have for term-level programs. There is no IDE, no highlighting, no debugger, no single-stepping, and, as you noticed, the error messages are pretty horrible.

            Thankfully, all of that is slowly changing. Compiler authors take *useful* error messages very seriously, e.g. Clang++. In Scala, they even refuse to add features to the language if they think that they can’t implement good error messages for them! GHC has been getting a lot better. Elm even explicitly calls out their helpful error messages as an important feature (and they have a catchy name for it: *compilers-as-assistants*).

            And there is movement on the tooling front, too. I already mentioned Elm’s error messages. Odersky’s group at EPFL is thinking about type-level debuggers and type-level tooling. Idris has some interesting features.

  12. From one Evil Empire to the next! Hopefully Coverity was a nice breather 🙂

    Best of luck. I’m hugely excited for the Z-machine series!

    Reply ↓

  15. Hum…..
    Makes sense considering their recognized investments in serious research.

    ….Hum…..

    This gives me an idea of essay. Best of luck and thank you for your work on C#

    Reply ↓

  16. Pingback: Dew Drop – February 9, 2016 (#2184) | Morning Dew

  17. Congratulations Eric for your new job!

    When you moved to Coverity, you assured your .NET followers that C# was still in good health and that was proven by the fact that you were going to work on a C# static analyzer.
    Now that you have professionally abandoned .NET and C#, is it time for us to invest on a different platform / framework / language?
    What do you suggest?

    Reply ↓

    • Thanks!

      I am *super impressed* by how Microsoft is making the transition to open source. I’ve been following the evolution of C# as a C# MVP, talking with people on the language design team, and so on, for some time now. I think C# 6 was a bit thin on the feature front, but I expected that; getting Roslyn out the door was the high order bit. C# 7 is going to be great, and the .NET platform is going to be more broadly available and applicable than ever. It’s a great time to be a .NET developer on any operating system!

      Reply ↓

  18. “they have very generously asked me to be a part of it.”

    When are you buying a Ferrari then Eric? In all seriousness i have heard a lot of good things about their generous salaries

    Reply ↓

    • Well I meant that thinking of me for the role was a generous thing to do. But yes, the compensation package is better than average.

      I think I will stick with my Miata for now though!

      Reply ↓

  21. Hack seems to be a lot like TypeScript adding optional static typing with a compiler/checker that tries to prove there is a type error.
    Do you think that is the way forward for language design, or just the “least bad option” if you are not able to switch to a language with static typing like C#?
    Would it be a good way to add “not nullable” to C#?

    Reply ↓

    • It is very much like TypeScript, yes. Whether that’s “the way forward” in language design, I don’t know. The language design is a response to the situation that the industry got itself into: large companies building multi-MLOC programs with large teams in languages that were designed, as I often point out, to make the monkey dance when the mouse moves. Imposing some discipline and enabling programming-in-the-large while still maintaining the scripty, dynamic nature of the language that made it so popular in the first place, seems like a natural solution.

      Reply ↓

      • Fantastic to read your insight on that one. The dancing monkey thing is a very good point. It is somehow like RDBMS that were intended to cop with a few dozens users without application layer between the server and the client but which had then to adapt to the very demanding – and different – usage of web apps.

        The technical challenges between this JS are very different, but I find interesting that as an industry we tend to stretch to the extreme our usage of certain things. I’d be tempted to call it a wrong choice of tools, but at the same time I think 1) was there any other choice then, and 2) Would we have Typescript today if people sticked to the dancing monkeys and put everything else in the server ?

        I love the perspective you opened.

        Reply ↓

  22. Many people have congratulated you for joining FaceBook, but really I think FaceBook should be the one being congratulated instead!

    I hope the good folks there will provide you with many a fantastic experience, and I look forward to reading even more absurdly fabulous adventures on your blog henceforth.

    Reply ↓

Leave a comment