Live data from Hacker News

Hack: a new programming language for HHVM

code.facebook.com

351–360 of 422 posts

Re: Hack: a new programming language for HHVM

#351
post #253

Earlier quoted context omitted.

As much as I prefer not to engage trolls... Which language would have been a good technical decision in 2002-2003? It needs to be fast enough in terms of iteration. It needs to not require more resources than PHP. It must be easy to onboard people who don't know it onto. It needs to be easy to operate, and not be costly to deploy on the tens, hundreds, and then thousands of servers necessary. (Spending time learning…

> Which language would have been a good technical decision in 2002-2003? It must be easy to onboard people who don't know it onto. It needs to be easy to operate, and not be costly to deploy on the tens, hundreds, and then thousands of servers necessary. You mean, like the JVM? 2003 wasn't the pliocene epoch, we had a working JVM. If you remember back to the last bubble, in the 90s , we were shipping "easy to operate…

> You mean, like the JVM?

In 2002-2003 I'd have quit in disgust if anyone tried to introduce the JVM anywhere I worked.... I still probably would, frankly.

Re: Hack: a new programming language for HHVM

#352
post #185

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…

But at the same time, layering FP with a home rolled static type checking server (??) is bug prone Clearly the home rolled stuff is working out for facebook. Twitter was/is on RoR and continues(!!) to have major downtime issues.

Twitter could have been written in any language and worked, but given their old architecture decisions, they'd been just as likely to mess it up in every language.

They blamed RoR a lot because they needed an explanation for their problems, but "many to many" messaging even at their scale is a "solved" problem and has been for decades and is fairly easy to scale.

(Think of Twitter as a bunch of mailing lists and mailboxes; you scale it by decomposing it: map accounts to virtual "buckets" that becomes the domain part, and map tweets to messages; break apart large follower lists into smaller ones and introduce a forwarding reflector; break apart large following lists by splitting "mailboxes" and doing zipper merges on reading it; add a caching layer -- this is not rocket science, and you could do it properly in any language)

Note: I think RoR was a horrible choice for them, though I love Ruby, but I also don't for a second believe RoR was their real problem.

Edit: Your overall point stands, though. Especially given that Facebook is a far more complicated application.

Re: Hack: a new programming language for HHVM

#353
post #92

Earlier quoted context omitted.

If you're looking for a statically-typed version of Python/Ruby, I'd say nimrod gets fairly close. It's also fantastically fast and compiles to portable ANSI C.

Nimrod is not a statically typed version of Python in the sense Hack is a statically typed version of PHP. Not at all. Hack is gradually typed, Nimrod is not. Big difference.

I thought it was clear I wasn't trying to draw an analogy between PHP/Hack and Python/Nimrod, but rather pointing out that Nimrod is a very nice language for someone who enjoys Python but wants static typing.

Re: Hack: a new programming language for HHVM

#354
It's good to see gradual typing rising!

2 things are not obvious from the article:

1. Why a new language, and not just a gradual typing tool for PHP (like Typed Racket and Typed Clojure)?

2. Is type information somehow passed to runtime to assist JIT compilation?

Re: Hack: a new programming language for HHVM

#356

Earlier quoted context omitted.

How do you do it in java? Compile (takes time) -> hotswap (takes time), or can't hotswap since changes to signature, will need to restart server (takes lot of time).

http://docs.codehaus.org/display/JETTY/Maven+Jetty+Plugin

Yeah, that's the one we're using. Still takes a couple of seconds, though. And as I said, big changes can't be reloaded, so the whole server will have to be restarted.

Re: Hack: a new programming language for HHVM

#357
post #278

Earlier quoted context omitted.

> 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. We took a similar approach to what you described. Then we called it Hack. This is what we mean by seamless inter-operation: the HHVM runtime understands both syntaxes and runs both <?php and <?hh code in the same process. Whether Hack integrates into the runtime…

But the syntax you've got now is effectively a superset of PHP, and comes with all the problems of PHP. You've effectively wrapped your Big Ball of Mud... in slightly different-colored mud. The whole point of a clean-break-targeting-interoperability like this is that you can stop using mud at all , and it'll still work with what you've got now. In fact, what other reason would you have ? If you mean that future versi…

I think you are putting way too much emphasis on syntax here. The important contribution of Hack is the type system and this is something that a syntactic-sugar translator like Coffeescript can't hope to achieve.

I also wouldn't count Clojurescript here. Its a whole different language that just happensto compile down to JS.

Re: Hack: a new programming language for HHVM

#358
post #269
post #47

Earlier quoted context omitted.

Yes and no. Yes, because TypeScript is bringing a type-system to a dynamically typed language and so did Hack. No: because Hack is bringing some additional language features affecting the runtime. Modest changes for now, but we intend to carry on in that direction.

> No: because Hack is bringing some additional language features [...] TypeScript added classes, interfaces, modules, and arrow functions.

The key difference is affecting the runtime. All those typescript features can be compiled down to regular JS and typescript-generated javascript can be run in a browser without extending the JS engine.

Re: Hack: a new programming language for HHVM

#359
post #344

Earlier quoted context omitted.

Engineer working on Hack here. Yeah, I think Hack is a good language to start a new project in. For as much flak as PHP gets, there are actually a lot of good things about the language. The fast development cycle -- edit php script, refresh -- is something amazing that you don't get in a lot of statically typed languages, which usually have a compilation step. The crazy dynamic things you can do also occasionally hav…

Do you know if other languages have static null checking i.e. your null annotation/propagation (apart from Haskell's Maybe union type etc)? I'm intrigued, because it's such a good idea (especially when null's originator claimed it was a "billion dollar mistake"), though Java doesn't have it. I'm wondering if there's some subtle problem with it...? Also, how do you make your vim typechecker fast enough? Usually, even…

Java 8 adds this exact feature through extending annotation capability and adding hooks for pluggable type checkers, including a null propagation checker: http://docs.oracle.com/javase/tutorial/java/annotations/type...

and an Optional class (references to which can still be null for maximum hilarity): http://download.java.net/jdk8/docs/api/java/util/Optional.ht...

I'm stoked. And disappointed the "elvis" operator didn't make it in.

I hope some day Java breaks backwards compatibility and eliminates null entirely. Then again, that's already happened with the proliferation of other JVM languages. But that doesn't me at my day job, where we have a large legacy code base... which would need to be ported to a backwards-incompatible version of non-null Java anyway. Hm.

Well, with Java 8 I can at least start to grow null-safe code within our codebase.

Re: Hack: a new programming language for HHVM

#360
post #108

Earlier quoted context omitted.

Which mainstream language would you have chosen in 2003 that you think would have had similar success?

Any. Really, any. Facebook is throwing a lot of engineering effort into fixing things that now matter to them, but didn't when they started (and were small). They could have picked Perl CGI's and it'd still have happened (perhaps Perl 6 would be a success these days). I don't think PHP has played any role in bringing FB to the size it is today (programming language does not translate to number of users signing up). S…

The point you "Anything but PHP" guys seem to conveniently ignore (or perhaps, not comprehend), is that at Facebook scale, you are going to have issues with many of these things regardless of what language you chose. They have specifically made this point many times. You and others point to some hand-wavy magical language which somehow doesn't have any issues when serving hundreds of millions of users. That doesn't exist.
Post reply on HN