Live data from Hacker News

Hack: a new programming language for HHVM

code.facebook.com

221–230 of 422 posts

Re: Hack: a new programming language for HHVM

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

I'm a little confused as to the need for Hack unless you have a code base in PHP and need to ship tighter code (which is a problem Facebook has and my team probably has as well).

Adding lambdas makes PHP more Ruby-like and generics and type checking are straight out of Java. I'm still unconvinced in how this makes programming websites more efficient or bug-free than existing languages. Can you please elaborate on that?

Re: Hack: a new programming language for HHVM

#223
post #108

Earlier quoted context omitted.

I don't see why not. It's possible to have done it any any mainstream language.

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

Engineering decisions made in 2003 need not dictate the future of the company more than a decade later. Keep the systems that are written in PHP around for their nature life. Write new systems in whatever is more sensible at the time. Lazy-load your way out of shitsville.

Of course this is vastly complicated if they been neglecting modularity and SOA for the past decade and most of facebook is still a monolith.....

Re: Hack: a new programming language for HHVM

#224
post #190
post #179

Earlier quoted context omitted.

Can you expand on "Wordpress folks dont care about PHP.next" ?

look at Wordpress codebase.It's not modern PHP because old PHP versions support.

And your best explanation is that WordPress core devs just don't care?

Re: Hack: a new programming language for HHVM

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

Yes and the OP is criticizing the decisions being made now as "yak shaving." Could it perhaps be that the "yak shavers" made a conscious and well-reasoned decision to go in the direction of "extend PHP" vs "throw it all out and rewrite everything in language-of-the-month?"

Re: Hack: a new programming language for HHVM

#226

Earlier quoted context omitted.

Hi Bryan, How do you protect from type errors when a value crosses from the untyped to typed fragment? Do you use contracts?

Not Bryan, but I am an engineer who works on Hack :) We don't (statically) protect against type errors when you cross from untyped into typed code. If you call an untyped function, we assume the programmer knows what they are doing -- just like PHP does. You might get a runtime exception if you are calling a method on null, for example. This is actually a pretty important part of the conversion process. You don't hav…

Oh I see, so there's no change in code generation for typed code, then?

Re: Hack: a new programming language for HHVM

#227
post #223
post #108

Earlier quoted context omitted.

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

Engineering decisions made in 2003 need not dictate the future of the company more than a decade later. Keep the systems that are written in PHP around for their nature life. Write new systems in whatever is more sensible at the time. Lazy-load your way out of shitsville. Of course this is vastly complicated if they been neglecting modularity and SOA for the past decade and most of facebook is still a monolith.....

Pretty much only the front-end code is written in PHP (or Hack, I guess).

Services (things like the feed, the typeahead, graph search, messages, &c.) are written in C++ and other languages - ie, the things it is sensible to write them in...

Re: Hack: a new programming language for HHVM

#228
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…

Perl was a possibility, but CGI is/was a pain to use. To get started you had to understand things like headers. You frequently had scripts refusing to run for whitespace issues relating to CRLF vs LF. You'd need to come up with your own templating language... It was just much more difficult.

Also Perl libraries typically require superuser rights to install. That's a big deal if you're a poor student using shared hosting on your fun hacking projects.

Python really wasn't an option. mod_python by default required you to restart Apache whenever a python file changed. It was designed to be configured by sysadmins on dedicated servers... if you wanted something you could hack together an put on a shared host, it just wasn't an option.

Also the hot Python framework in 2003 was Zope. No one uses Zope anymore. For good reason.

Ruby was much smaller, and this was pre-rails so it didn't have any significant web framework. I'm not even sure if there was a production ready way of hosting ruby scripts.

Re: Hack: a new programming language for HHVM

#229
post #111

Earlier quoted context omitted.

AFAIK large PHP libraries(Doctrine/Symfony) generate PHP code (from config files for instance) that is then required and executed. You cant be more meta than that. I dont know if you can do that with Hack, but that's definetly a big PHP pattern.

It depends on what you mean by "with Hack". You cannot do this in Hack code -- we disallow the dynamic features of the language you need to do this; they are impossible to statically typecheck and verify. However, Hack code iteroperates seamlessly with PHP code, so there's nothing stopping you from having some PHP files in your codebase that do anything that standard PHP can do.

So.. my question remains unanswered... if you cannot do meta-programming in hack, how can you say it "offers the best of both dynamically typed and statically typed languages"?

Re: Hack: a new programming language for HHVM

#230
post #85

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. 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, into numbers, resulting in all sorts of weirdness like this: https://eval.in/111886

2) PHP 5.4's OWN TEST SUITE has 91 failures and only 70% coverage. There is NOTHING more "WTF" than that! Why even bother having a test suite?? http://gcov.php.net/viewer.php?version=PHP_5_4

3) Why the fuck are all of these different things equal, and how does this NOT result in problems? http://i.imgur.com/pyDTn2i.png

4) String increment is dumb to begin with, but why does it not even match the behavior of string decrement? https://eval.in/60631

5) Why the hell can you jump back into a try block from a catch block? Recipe for disaster: http://phpmanualmasterpieces.tumblr.com/post/33091353115/the...

6) PHP comparison operators. I'm sorry, but this level of complexity might make you feel smart once you master all its idiotsyncrasies [sic], but it's actually dumb: http://stackoverflow.com/questions/15813490/php-type-jugglin...

That's a small fraction of not-thought-out PHP language features that result in REAL bugs and security holes. Which consume large swathes of programmer time. Which, apparently, Facebook can afford to swallow.

I'm sorry, but your position, as valiant as you are defending it, is literally indefensible. And I don't give a fuck how big Facebook is, they would STILL be better-served by switching SOME of their code to a different language. ANY modern programming language wouldn't suffer from this imbecilic, immature language design.

Post reply on HN