Hack: a new programming language for HHVM • Hacker News Board

Re: Hack: a new programming language for HHVM

#241

Post by dirtyaura » Thu, Mar 20, 2014, 8:55 PM UTC

teacup50 wrote: post #219

gfodor wrote: post #124

Earlier quoted context omitted.

"I am baffled as to why you'd build your castle atop a crumbling foundation." Congratulations for admitting your ignorance, and lending open ears to experts as to why they made certain engineering decisions. Oh wait, you weren't doing that, you were just warming up to go on a diatribe about how stupid Facebook engineers must be.

> Congratulations for admitting your ignorance, and lending open ears to experts as to why they made certain engineering decisions. Yes, they made certain engineering decisions now because the decisions they made back then were stupid, and they have to dig themselves out.

What was the stupid decision "made back then"?

That Zuck wrote the first version of thefacebook.com in PHP, the language he was the most productive at?

That the initial team didn't rewrite Facebook in Python/Perl/Ruby/Haskell during the fast growth phase? If you have ever experienced the growth phase, you understand how ludicrous the idea of rewrite would be. I've personally experienced and heard only horror stories about rewrites. We underestimate how much hidden wisdom a production code base has and that the messiness is often there for good reasons.

Re: Hack: a new programming language for HHVM

#242

Post by ausjke » Thu, Mar 20, 2014, 8:57 PM UTC

reikonomusha wrote: post #48

I am baffled as to why you'd build your castle atop a crumbling foundation. I have wondered why FB didn't use a proper language with proper typing to begin with. I mean, I "understand" logistically: they already had a giant codebase in PHP, migrating a codebase is expensive, and it's difficult to hire and train 1000s of hackers in e.g., OCaml. (They do have some OCaml people, but they are outliers. OCaml was my favor…

I have seen many python programmers that are PHP haters, are you one of them? just curious, no offence. I like both Python and PHP, but use PHP for commercial applications.

Re: Hack: a new programming language for HHVM

#243

Post by fzltrp » Thu, Mar 20, 2014, 9:02 PM UTC

julienv wrote: post #200

fzltrp wrote: post #130

Earlier quoted context omitted.

Great work! A question about the type inference mechanism: in PHP, while it is possible to define object interfaces which classes may be defined against, by the dynamic nature of the language, functions don't necessarily need that interface specification to accept an object conforming to it, explicitely or implicitely. OCaml provides something "similar" with its object system, but much more powerful with static infer…

There seem to be 2 questions here: 1) Is Hack type inference total? Answer no: you must annotate parameters and return types. It would be pretty much impossible to implement total type-inference without loosing separate compilation in Hack. PHP projects are not organized around a module system, which means that you have "spaghetti" dependencies, and even better, cyclic dependencies all over the place. So trying to im…

Thanks! I was mostly thinking about point 2, and I understand your motivations in going in a different direction after trying it. Very good and enlightening answer!

Re: Hack: a new programming language for HHVM

#244

Post by fzltrp » Thu, Mar 20, 2014, 9:05 PM UTC

jwatzman wrote: post #188

fzltrp wrote: post #130

Earlier quoted context omitted.

Great work! A question about the type inference mechanism: in PHP, while it is possible to define object interfaces which classes may be defined against, by the dynamic nature of the language, functions don't necessarily need that interface specification to accept an object conforming to it, explicitely or implicitely. OCaml provides something "similar" with its object system, but much more powerful with static infer…

Engineer working on Hack here. We don't do any type inference across function boundaries, so we largely dodge the issue that I think you are getting at. (Please elaborate if I misunderstand!) We rely on interface and class definitions in order to know what methods are available, and even though the runtime resolves everything at runtime so you can call any method that happens to exist at that time ("duck typing"), we…

Thank you! You brought an interesting point with the example you gave, it is one of the things I was thinking about. Thank you for your work, and for making it available!

Re: Hack: a new programming language for HHVM

#245

Post by coldtea » Thu, Mar 20, 2014, 9:06 PM UTC

reikonomusha wrote: post #48

I am baffled as to why you'd build your castle atop a crumbling foundation. I have wondered why FB didn't use a proper language with proper typing to begin with. I mean, I "understand" logistically: they already had a giant codebase in PHP, migrating a codebase is expensive, and it's difficult to hire and train 1000s of hackers in e.g., OCaml. (They do have some OCaml people, but they are outliers. OCaml was my favor…

>I have wondered why FB didn't use a proper language with proper typing to begin with.

Because there are factors like an existing codebase that works that trump BS idealism.

Re: Hack: a new programming language for HHVM

#246

Post by juchem » Thu, Mar 20, 2014, 9:08 PM UTC

lectrick wrote: post #230

lbrandy wrote: post #85

Earlier quoted context omitted.

> I am baffled as to why you'd build your castle atop a crumbling foundation. Because perfect is not the enemy of the good? Because "build atop a crumbling foundation" has demonstrated time and again to be, by far, the most successful way to accomplish anything in computing? Unless you have some example of perfect, now dominant, technologies that have been created ex nihilo that I'm missing? I mean we (facebook) are…

Given a programming task, it will be written faster, easier, and in a more maintainable and less bug-prone fashion if it is not PHP. The opposite opinion is basically indefensible. Sure, you can still dig a trench with a spoon (and if you have enough money to wield a bunch of workers with a spoon), even if a shovel would do a better job. Let's begin. 1) PHP autocraptastically converts strings that look like numbers,…

It's interesting how most people seem to attribute the quality and longevity of a software to the language it is written in or the frameworks it uses rather than to the amount of thought that was put into its design. Sure, the former is important, but largely overrated.

Re: Hack: a new programming language for HHVM

#247

Post by GhostHardware » Thu, Mar 20, 2014, 9:26 PM UTC

vhata wrote: post #178

derefr wrote: post #138

Earlier quoted context omitted.

> Just so we are clear, you ask why Facebook didn't rewrite 10,000 human-years of code into a mythical unnamed "proper" ... You don't need to rewrite anything (at least, not all at once.) Personally, I'd have expected you to make something akin to CoffeeScript or ClojureScript that targets PHP, and can "link with" your existing PHP modules (or rather, with their HHVM bytecode representations.) Then treat the PHP code…

That is essentially what Hack is.

Very suitable name for a language then.

Re: Hack: a new programming language for HHVM

#248

Post by [deleted] » Thu, Mar 20, 2014, 9:43 PM UTC

amenghra wrote: post #94

wvenable wrote: post #72

Earlier quoted context omitted.

PHP is based on C. It's way more consistent with C, Java, C# , etc to do the former. So the real question is why function foobar() : int { .. } instead of function int foobar() { .. }

1. function foobar() makes it easier to grep for. 2. if I recall correctly, it made some parts of the grammar easier.

[deleted]

Re: Hack: a new programming language for HHVM

#249

Post by nbm » Thu, Mar 20, 2014, 9:46 PM UTC

wiremine wrote: post #217

nbm wrote: post #156

Earlier quoted context omitted.

Can you rephrase your question about the ops perspective? Is there something in particular you want to know about?

Sure. I guess I'm wondering how it compares to running plain old Apache/PHP in a production environment. Or, is it more like a Django/Rails stack? Does it use the same memory footprint as PHP, etc?

Facebook hasn't used plain old Apache/PHP in production for several years (HipHop for PHP was announced in Feb 2010), so it is hard to compare.

HHVM is its own web server (although it supports FastCGI for easier use with existing infrastructure like nginx), and that's how we use it in production. It's hard to compare memory usage, except at scale, where it benefits from not having a whole bunch of interpreters (in different processes) running at the same time and some other benefits by using more appropriate types to store values through type inference.

Re: Hack: a new programming language for HHVM

#250

Post by teacup50 » Thu, Mar 20, 2014, 9:49 PM UTC

dirtyaura wrote: post #241

teacup50 wrote: post #219

Earlier quoted context omitted.

> Congratulations for admitting your ignorance, and lending open ears to experts as to why they made certain engineering decisions. Yes, they made certain engineering decisions now because the decisions they made back then were stupid, and they have to dig themselves out.

What was the stupid decision "made back then"? That Zuck wrote the first version of thefacebook.com in PHP, the language he was the most productive at? That the initial team didn't rewrite Facebook in Python/Perl/Ruby/Haskell during the fast growth phase? If you have ever experienced the growth phase, you understand how ludicrous the idea of rewrite would be. I've personally experienced and heard only horror stories…

> What was the stupid decision "made back then"?

Using PHP to begin with was a bad technical decision. Failing to establish a reasonable migration strategy was a bad business decision likely rooted in bad engineering management that fell out of starting with bad technical decisions.

It's much harder to hire people that can pull you out of a mess like PHP when, at the same time, you have to hire people that can keep writing PHP for you.

> That the initial team didn't rewrite Facebook in Python/Perl/Ruby/Haskell during the fast growth phase?

That would have been a good time to bring on new engineering blood as part of scaling out, which would have provided opportunities to enact mitigation and transition strategies. Imagine if the massive amount of talent currently devoted to HHVM had been devoted to Facebook's actual business?

There are migration strategies other than "rewrite everything immediately", and in fact, I'd bet that's exactly what HHVM is. It's just a shame they waited so long that the most cost-effective migration strategy was to tackle an enormously difficult computer science and engineering problem that the world's biggest software companies already invest hundreds of millions of dollars on and provide to the world largely for free.

> If you have ever experienced the growth phase, you understand how ludicrous the idea of rewrite would be.

Yes, and I've also (repeatedly) been the team brought in to rewrite the mess of a code base that was about to torpedo the growth phase.

There's not much correlation between funding, initial success, and engineering talent. Which is why you so often wind up with a mess that has to be cleaned up once you can hire people who know what the hell they're doing, instead of the ones you happened to be stuck with because you didn't know how to grow an engineering team.

> We underestimate how much hidden wisdom a production code base has and that the messiness is often there for good reasons.

Messiness is never there for good reasons other than that replacing it is more expensive than not touching it. You don't strive for hidden wisdom and inescapable messiness -- that's just what you get when you let engineering slip up.