Live data from Hacker News

Hack: a new programming language for HHVM

code.facebook.com

211–220 of 422 posts

Re: Hack: a new programming language for HHVM

#211
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 might have some legacy Rails hanging around, but it's a beastly Scala system these days.

Re: Hack: a new programming language for HHVM

#212

Earlier quoted context omitted.

As a frequent user of R, this is one of my biggest pet peeves. There are a practically infinite number of unique, interesting, pronounceable, google-able names for a new programming language, yet we continue to get stuck with this shit.

A few months ago, "Martini" came out for "Go". I love the framework, but man, searching for stuff on Google was a PITA.

At least go says in their official docs, when posting/searching for the language, use "Golang"

Re: Hack: a new programming language for HHVM

#213
post #71

Are there any plans for a Hack -> PHP transpiler? Or is that impossible? It would be nice to develop on Hack, transpile back to vanilla PHP where we still have to use the PHP.net runtime (shared hosts, Google app engine, Engine Yard, etc)

Hack is more than just a type system. At the type level, it would be trivial to erase the types and run the code on vanilla PHP. Dealing with everything else is much harder (xhp, containers, lambda, etc.), at which point it just makes more sense to use HHVM.

Re: Hack: a new programming language for HHVM

#214
post #170

Earlier quoted context omitted.

PHP is a "crumbling foundation" in exactly the same way DOS, Windows, COBOL, and C and C++ were, are, "crumbling foundations". I don't see how you are disagreeing with me. You are proving the point. You aren't actually going to claim that Windows was well-conceived and theoretically well-founded, are you? Windows has been a never ending refinement on exceptionally shaky ground.

I'm appalled and little bit insulted that you group PHP in the same group with COBOL, C and C++ in terms of their foundation. COBOL and C were designed by some of the greatest pioneers of the field, and indeed PHP is built on C.

Just because they are remembered as being first doesn't mean they were well designed, or actually pioneers. At the same time C was being written others were working on Lisp, and ML. It has taken nearly half a century for some of their innovations to be recognized as good ideas and taken up by main stream languages, while C was a small improvement upon existing language design.

Re: Hack: a new programming language for HHVM

#215
post #15

Earlier quoted context omitted.

whats the state of the type system like? Here[1] it suggests that it may have bugs, is this a 'covering backside' thing or is it currently unsound? [1] - http://hacklang.org/manual/en/hack.annotations.summary.php

Engineer working on Hack here. It's complicated. If you use partial mode, which doesn't enforce that every function is fully typed, then it's trivial to break the type system by just using an untyped function. In order to ease conversion, we just assume the programmer knows what they are doing with untyped functions and let anything pass. If all of your code is in strict mode, then we believe the type system to be so…

> If all of your code is in strict mode, then we believe the type system to be sound. We haven't done any formal proof of this of course, and there have been plenty of bugs in the past. But that's the goal.

When I look at this from the docs, it seems unsound:

"Hack treats traits as a stand-alone entity during the type checking process. In other words, it ensures type consistency within the trait (i.e., as a black box, so to speak), but does not "copy and paste" the code into all of the classes that use the trait and check for type consistency there. The reason this is done comes down to performance."

Is there something I'm missing that does make this sound?

Re: Hack: a new programming language for HHVM

#216
post #3

I'm the manager of the team that developed Hack, and I'm sitting here with some of the language designers. Happy to answer your questions.

Thank you for your work on this and for open sourcing it. It looks like it can make large code bases in PHP a great deal more manageable.

Do you expect Hack to be stable without large breaking changes going forward?

The documentation doesn't say much about the scheduling for asynchronous tasks. Can async functions be used to batch requests to e.g. caches and databases? Can Awaitable be used to interface with code that expects chainable Future or Promise-style interfaces?

Can HHVM/Hack use standard PHP extensions, or how much work is it to port an extension?

Is there a Hack plugin for IntelliJ?

Does the Hack project have a mailing list or forum?

Re: Hack: a new programming language for HHVM

#217
post #156

Earlier quoted context omitted.

> Some people (quite reasonably) initially thought of Hack errors as lint-like stuff that it was safe to ignore, when in fact they indicate real logical inconsistencies in code. Interesting, thanks! One followup: what has it been like from an ops perspective? Similar to PHP, or is there a better frame of reference?

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?

Re: Hack: a new programming language for HHVM

#218

Earlier quoted context omitted.

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…

Do you think perl would have been much better? Either way, the point that he was making was that there were pretty slim pickings back then. Certainly the dominant languages/frameworks of WD these days (python, ruby, node) didn't exist. Or by another token, the only dominant one that was also strong back then is PHP, the one they chose.

Yeah, Node didn't exist.

Python was over ten years old in 2003. In Python web development there had already been CGIs, mod_python and two major releases of Zope, with hope of Zope 3 on the horizon.

Ruby is almost as old as Python.

Re: Hack: a new programming language for HHVM

#219
post #124

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 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.

Re: Hack: a new programming language for HHVM

#220
post #137

Earlier quoted context omitted.

Pretty star-studded cast you have on the core team, there. What's your motivation, aside from modernizing Facebook's code base? What language niche does Hack serve which is not served by other languages? Why Facebook at all (aside from the rarity of finding a company to pay you to write a compiler :))?

The sweet spot that Hack hits is that it combines gradual typing (an idea that hasn't yet seen much real-world adoption) with an incredibly fast typechecker. This lets you choose the pace and extent to which you want to adopt the safety of static typing, while preserving your dynamically typed code -- and without sacrificing the rapid turnaround of PHP. That's a unique combination, in my experience.

How does your approach compare to Typed Racket and Typed Clojure? Could they conceivably achieve the same performance or is there a fundamental difference?
Post reply on HN