Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HHVM 3.0.0

hhvm.com

Post reply on HN
Print view View original

21–30 of 32 posts

Re: HHVM 3.0.0

#21

Post by nnq »

What worries me is the large list of 'unsupported PHP features': http://docs.hhvm.com/manual/en/hack.unsupported.php .

I know they can be considered bad practice, but in practice you use at at least a couple of them at least once in every project! And you use it because the alternative would be even uglier. (Also, what's the point in having a language with a separate namespace for functions and variables - Perl and Common Lisp being the only other ones I know of - if you can't at least have fun with variable variables and using a string directly as a function :) )

...also, they've "downgraded" PHP's closures mechanism. I mean, with:

    return function foo($a, $b) use ($outer1, $outer2) { ... }
...PHP managed to do things better then all other dynamic languages - finally a way of being explicit about what variables from the outer scope you drag into a closure! The Hack guys totally missed the point - they've made everything stricter, but they relaxed this constraint and reverted one of the few good ideas in PHP.

Their VM may be awesome, but their language is horrid - they take away the "fun" features of PHP but don't fix any of the bad language design issues. It's like throwing away the baby and keeping the bath water - yeah, the water will keep you alive for a few more days in the desset, but the baby can actually be fun to play with.

Re: HHVM 3.0.0

#22

Post by stephenr »

nnq wrote: post #21

What worries me is the large list of 'unsupported PHP features': http://docs.hhvm.com/manual/en/hack.unsupported.php . I know they can be considered bad practice, but in practice you use at at least a couple of them at least once in every project! And you use it because the alternative would be even uglier. (Also, what's the point in having a language with a separate namespace for functions and variables - Perl and C…

The list of "unsupported" features is attrocious but not suprising.

When a language makes dick jokes in syntax, you shouldn't expect much.

Re: HHVM 3.0.0

#23

Post by nnq »

stephenr wrote: post #22
nnq wrote: post #21

What worries me is the large list of 'unsupported PHP features': http://docs.hhvm.com/manual/en/hack.unsupported.php . I know they can be considered bad practice, but in practice you use at at least a couple of them at least once in every project! And you use it because the alternative would be even uglier. (Also, what's the point in having a language with a separate namespace for functions and variables - Perl and C…

The list of "unsupported" features is attrocious but not suprising. When a language makes dick jokes in syntax, you shouldn't expect much.

==> jokes aside, they are pulling in a very different direction from the one of the core PHP devs... this alone makes me expect less from the entire PHP system as a whole. They just made the PHP equivalent of Perl 6 vs Perl 5. But at least they are using their "Perl 6" and it works fine for them.

If we could at least start to see shared hosts offering support for Hack and XHP it would seem more hopeful. (btw, you think PHP devs would like this? I was kinda pondering over it as a business idea...)

Re: HHVM 3.0.0

#24

Post by jules »

nnq wrote: post #21

What worries me is the large list of 'unsupported PHP features': http://docs.hhvm.com/manual/en/hack.unsupported.php . I know they can be considered bad practice, but in practice you use at at least a couple of them at least once in every project! And you use it because the alternative would be even uglier. (Also, what's the point in having a language with a separate namespace for functions and variables - Perl and C…

Why would you want to be explicit about that? The information is already there in the body of the closure. It's Foo x = new Foo(); all over again.

Re: HHVM 3.0.0

#25

Post by dan15 »

alexgartrell wrote: post #5
adamors wrote: post #4

Earlier quoted context omitted.

Considering that you can convert PHP files to Hack by just changing the opening tag, I think it would be very similar to the way HHVM is used currently.

Sorry, to be clear I'm more curious about how it's integrated with version control and how things like MVC are done. I really haven't got a clue. For that matter, are people mostly using HHVM via fast-cgi?

I work at Facebook as well, but mainly in JavaScript so I haven't done a lot of PHP either :)

You could use a common PHP framework like FuelPHP, Laravel or Kohana. I'm not sure which frameworks are 100% compatible with HHVM, but I think they're all getting quite close to 100% (or may even be at 100% with the 3.0 release). It's fine to mix PHP and Hack in the one project, so you could use a PHP framework and use Hack just for your code.

Re: HHVM 3.0.0

#26

Post by dan15 »

Terr_ wrote: post #19
elgenie wrote: post #14

Earlier quoted context omitted.

(I work on HHVM/Hack at FB) We have an on-call rotation in which one person has the job of cutting (and testing) the internal named release. That person has final choice for the name, often subject to lobbying by the more rap-enlightened members of the team. /me was pushing for C = Common

Quick sidequestion: Does HHVM support the Weakref extension? I ask because while it is not listed on the github wiki[1] but does appear in the manual[2]. I'm assuming the manual is an oversight, branched from PHP's manual and not pruned. That said, weak-references are indispensable for certain problems, and I'd love to see them standard. [1] https://github.com/facebook/hhvm/wiki/Extensions [2] http://docs.hhvm.com/ma…

If you click on any of the methods in the manual, you'll see "NOT SUPPORTED IN HHVM" in a large font. I'm guessing it's an oversight that that text is missing from the topic index as well.

Re: HHVM 3.0.0

#27

Post by nnq »

jules wrote: post #24
nnq wrote: post #21

What worries me is the large list of 'unsupported PHP features': http://docs.hhvm.com/manual/en/hack.unsupported.php . I know they can be considered bad practice, but in practice you use at at least a couple of them at least once in every project! And you use it because the alternative would be even uglier. (Also, what's the point in having a language with a separate namespace for functions and variables - Perl and C…

Why would you want to be explicit about that? The information is already there in the body of the closure. It's Foo x = new Foo(); all over again.

To know that the returned function can keep state? And if it does, to easily scan for side-effects via modified state? And to do this without carefully reading the entire body of the closure? It's a little bit like a "poor man's replacement for what a monad can be useful at" or `[Pure]` in C#. True, not much use in code you have written, but great for working with and even refactoring other people's code that you don't fully understand.

...to be honest, it's the kind of feature that I'd like to see in Javascript, not in PHP, to help me easily scan through callback hells in other people's code. It's true that callbacks don't tend to be abused in PHP and we don't have event labyrinths and long running event driven apps that can grow in memory usage, but these things will crop up, and when they do we'll have one less tool to make code more explicit and easier to read.

I guess the fate of all good ideas that land in PHP is to be ignored, hated and then forgotten :)

Re: HHVM 3.0.0

#28

Post by thefreeman »

nnq wrote: post #23
stephenr wrote: post #22

Earlier quoted context omitted.

The list of "unsupported" features is attrocious but not suprising. When a language makes dick jokes in syntax, you shouldn't expect much.

==> jokes aside, they are pulling in a very different direction from the one of the core PHP devs... this alone makes me expect less from the entire PHP system as a whole. They just made the PHP equivalent of Perl 6 vs Perl 5. But at least they are using their "Perl 6" and it works fine for them. If we could at least start to see shared hosts offering support for Hack and XHP it would seem more hopeful. (btw, you thi…

They have a heroku buildpack https://github.com/hhvm/heroku-buildpack-hhvm

That's not quite "shared host easy", but it's still pretty easy to get up and running on heroku if you know what you are doing.

Re: HHVM 3.0.0

#29

Post by thefreeman »

cookerware wrote: post #17

What server can I use with HHVM to get the performance boost claimed in the video? Does it have a built in HTTP server? Are there any benchmarks proving that HHVM improves performance? Can I get a better performance than my current setup of Nginx + uWSGI + Flask ?

It says it works via FastCGI, so you should be able to use any web server you want.

edit: Seeing as how Flask is Python, and HHVM is for PHP, you may have some trouble there.

Re: HHVM 3.0.0

#30

Post by igouy »

cookerware wrote: post #17

What server can I use with HHVM to get the performance boost claimed in the video? Does it have a built in HTTP server? Are there any benchmarks proving that HHVM improves performance? Can I get a better performance than my current setup of Nginx + uWSGI + Flask ?

Presumably it depends on the task, on how much the previous code-tuning prevents hhvm jit, on how much the code is changed with type hints, ...

Compare PHP fannkuch-redux with Hack Vector fannkuch-redux:

http://benchmarksgame.alioth.debian.org/u64/program.php?test...

http://benchmarksgame.alioth.debian.org/u64/program.php?test...

Post reply on HN