GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-09-18) - page 1 of 10
 
___________________________________________________________________
The Future of HHVM
158 points by mwpmaybe
http://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html
___________________________________________________________________
 
sunseb - 2 hours ago
I'm excited! :)PHP is IMHO the most productive and easiest platform
for web development:- a request- a response- templating- no shared
statedAnd that's it! But the language syntax has so many quirks. So
it's cool if Hack redesign the language and make it more beautiful
and consistent. Many developers switch to Ruby or Python because
these languages are better designed. I think Hack could attract a
lot of these developers who want more beauty in the tools they use.
 
  dna_polymerase - 36 minutes ago
  Oh boy they really got you!Have a look at Python & Flask! There
  is nothing easier than that!
 
rrdharan - 4 hours ago
This is fascinating. It's a well-written post and their plan makes
sense to me, but I imagine there's a tough choice ahead for
framework authors (the Laravels and Drupals of the world) about
whether they want to fork their communities, stay with PHP7, or try
to target both with the same codebase (in the near term or long
term)?At any rate at least the fact that the HHVM folks are
communicating the strategy effectively and transparently should
help everyone involved make reasonable decisions.
 
  HugoDaniel - 4 hours ago
  That and PATENTS:https://github.com/facebook/hhvm/blob/master/hph
  p/hack/PATEN...
 
    dingdingdang - 3 hours ago
    Exactly like React - means the language will be abandoned by
    wider community. The Facebook peeps are gradually building
    themselves into corporate self-invented mono-culture.
 
      m00x - 35 minutes ago
      I'd like to see any concrete numbers on this. I'm seeing
      React getting stronger and stronger in my area, and patent
      worries are mostly accepted as crazy hypotheticals.
 
    zimbatm - 2 hours ago
    If Facebook had released the code under BSD then nobody would
    have complained.But this basically gives a BSD plus patent
    grant, and reverts to BSD if there are any patent litigations.
    And now people are complaining.
 
      [deleted]
 
      s73ver_ - 30 minutes ago
      Because it is them saying, "We can take all of your patents,
      but if you sue us for it, then you don't get to use this."
 
    cstrasen - 4 hours ago
    Woah. Its bad enough with react which many did not expect.  Now
    also this BS. No thanks really.
 
  fredemmott - 4 hours ago
  Thanks; we don't feel that the framework authors have to make a
  choice here:- short-term, those of us working on HHVM - not the
  frameworks - need to make sure that HHVM can run the frameworks
  that Hack developers require- long-term, we expect Hack and HHVM
  to continue to diverge from PHP; it's unlikely that targeting
  both HHVM and PHP will be a practical long-term strategy
 
  wolco - 2 hours ago
  I can't imagine any large framework spliting or supporting this
  in place of php 7.  This is more of a new beginning with new hack
  frameworks.
 
  chx - 4 hours ago
  If I still were a Drupal core developer (and I was the #1 core
  contributor for 5, 6 and #4 for 7 and still #10 for 8 though I
  regret that) I would tell you there's no tough choice here, I
  would target PHP 7.x and forget the rest. Currently, others
  steers the core and they struggle mightily with just the
  transition to PHP 7.0 requirement. Check the issue queue. I filed
  https://www.drupal.org/node/2605226 in 2015 fall but it was voted
  down, the current open issue is
  https://www.drupal.org/node/2842431HHVM is way too niche to
  bother with it, sorry.
 
  TazeTSchnitzel - 3 hours ago
  PHP packages are dropping HHVM support right and left right now
  because HHVM has already been? lagging in its PHP support.So
  there's not really a choice to make. HHVM was tiny anyway.
 
  dabernathy89 - 1 hours ago
  Laravel dropped HHVM support a year ago, and i'm sure many other
  CMS's / frameworks have either followed suit (if they ever
  supported it) or will soon.
 
foxfired - 45 minutes ago
I think HHVM was equivalent to what jQuery was to JavaScript.
jQuery forced JavaScript to be better, and the better JavaScript
becomes, the less jQuery is needed.So if we get to a point where
HHVM is completely irrelevant, it simply means "Mission
Accomplished".
 
  [deleted]
 
  VeejayRampay - 34 minutes ago
  In terms of language, jQuery didn't innovate in anything though.
  It was a great framework mind you, but there's nothing special
  about it that influenced the choices in design for the more
  recent versions of JS.
 
memracom - 44 minutes ago
I think that these changes mean the death knell for PHP in any
version, for small companies. There is still a place for Hack or
PHP7 in very large operations, but startups, and businesses that
run at smaller scale, really should walk away from PHP entirely as
soon as possible.Two reasonable directions to choose are Python
Three with a framework like Flask (lighweight) or Django (heavy
duty). Or go to the JVM with something like Grails framework (heavy
duty) on the Groovy language. Ratpack is a lightweight framework
for Groovy and there is also an interesting option to use Vaadin 8
which lets you put your GUI code into the main app rather than
writing separate Javascript code.When making your decision, be sure
to consider the huge JVM ecosystem that integrates quite easily
with Groovy including development tools like Jenkins and SOAPUI
that can be scripted with Groovy. And the Python side also has a
fairly extensive ecosystem of libraries as well.The skill level of
Python and Java/Groovy developers tends to be higher than PHP which
has always attracted people who would learn just enought to get
by.The software dev community has gone through an explosion of
diversity in the past 2 decades and that has enabled a lot of
experimentation with new ways of doing this. There is a lot of good
in this. But now we are in a period of contraction. Some of this is
manifested in the spread of functional capabilities via libraries
such as reactive extensions and functional features being added to
languages like Java and Javascript. Another manifestation is the
fading of PERL from prominence, and this is now happening to PHP as
well as Ruby.This is evolution. Embrace it or face your personal
extinction as a software developer.
 
  segmondy - 9 minutes ago
  If you believe this, then you are very bad at predicting the
  future.  I'm very bad at that too.  But I can assure you, "better
  languages" don't win the war.  PHP has a lot of software out
  there and what's going to have it leading HHVM.   You will have
  the "cutting edge" folks give HHVM a shot, but all the practical
  folks don't care.  The only way HHVM will have a chance will be
  to be 100% backwards compatible.
 
  muglug - 27 minutes ago
  > This is evolution. Embrace it or face your personal extinction
  as a software developer.Woah there Mr Hyperbole.The reason PHP is
  still in use, and not dead or dying, is that it's one of the
  simplest languages to write server-side code in.That means it's
  remarkably easy to hack something together quickly, with no
  compilation step to get in the way.Unless that changes in a
  drastic fashion, projects will continue to get started in PHP,
  and PHP's user base will continue to grow, and (hopefully) the
  language will continue to improve to accommodate that growth.
 
ryangordon - 1 hours ago
Here's the interesting thing about all this; HHVM will always be
developed because it's important to Facebook's bottom line and Open
Source because it only benefits them to keep it out there and have
other people testing it and improving on it.Now that they're
getting rid of direct PHP support, HHVM is only going to get
better. This will unlock a whole host of language improvements that
HHVM couldn't otherwise make.HHVM is faster relative to PHP now,
and it will only get faster with these changes. Typing is an
important part of making JITed code fast and unless PHP ever
decides to fully add it, it will never have the potential to catch
up. This is important to PHP-based companies as they grow and want
to optimize on cost and development efficiency.Undoubtedly, this
split will be painful initially for those of us who are bought into
the symbiosis of the HHVM and PHP ecosystem together. How painful
it is to split will just be a question of where members of the PHP
community want to go (or both). The nice thing is that converting
something from PHP to HHVM isn't terribly hard; not anywhere near
like converting from PHP to Golang. For HHVM, it's mostly just
adding type annotations.
 
pbiggar - 1 hours ago
> Eliminating references. PHP references have unusual semantics,
where the function specifies the binding of parameters with no
indication at the callsite.I feel like I called this one in
https://circleci.com/blog/critiquing-facebooks-new-php-spec:> This
is interesting because they?re changing the definition of the
language through a sort of back-channel. They?re allowing breaking
changes by effectively deciding that other implementation choices
are equally valid.> I?ll give you an example, which I?ll get into
more below. There?s a little known bug in the Zend engine around
copying arrays that contain references. IBM wrote a paper about
this bug in 2009. Basically, this bug was necessary in Zend to make
copying arrays fast, and IBM figured out a way to do it in a way
that was actually correct, for only a 10% performance penalty.
 
  fredemmott - 4 minutes ago
  You'll also see a few of these on
  http://php.net/manual/en/migration70.incompatible.php :p
 
crescentfresh - 3 hours ago
First I'm hearing of Hack! Didn't realize HHVM had under it's wing
two languages.
 
tiffanyh - 4 hours ago
This is pure syntax sugar but will Hack now clean up the PHP
inconsistency with function naming and return values?E.g.
FunctionName() vs function_name().OrE.g. return 5x20; vs return
"5"x10;
 
  fredemmott - 4 hours ago
  Function naming:We're moving towards functions_like_this(),
  instanceAndStaticMethodsLikeThis(), and async functions like
  foo_async() and methods like fooAsync(). We're unlikely to change
  the PHP builtins, but we're fairly likely to build replacements -
  for example, Hack Arrays are best used with
  https://github.com/hhvm/hsl instead of the PHP array functions,
  and this also provides replacements for common string operations
  that are consistent and fit well with the Hack type system (e.g.
  nullable or throw an exception instead of falseable).For return
  values, I'm not sure exactly what you mean - could you give a
  full example? If I take your example verbatim, it's a syntax
  error in both Hack and PHP - if I go for "5"*10, it's a Hack
  error
  (https://gist.github.com/fredemmott/90c5f8eca17d1d4e1204f0085...)
 
    tiffanyh - 3 hours ago
    From the blog post:  HHVM will not aim to target PHP7  If you
    don't plan to support PHP5 anymore and HHVM is not targeted at
    PHP7 ... then my ask is to just make a better language and drop
    ALL of PHP baggage.When you say:  We're unlikely to change the
    PHP builtins  That concerns me. Because why even break support
    from PHP7 if you don't plan to change (fix) the builtins?
 
      mxawng - 3 hours ago
      As fredemmott said above, we're hoping to build replacements
      for the various PHP builtins that we want to be a core part
      of Hack.  I think that replacing the functionality provided
      by PHP builtins will be a less confusing transition
      experience than retrofitting them with modified behaviors
      would.Once we do have a compelling and comprehensive Hack
      Standard Library, I wouldn't be surprised if we dropped PHP
      builtins in favor of that.
 
      mic47 - 2 hours ago
      Maybe because there will be replacements instead? I guess
      that changing behavior (and type signatures) of builtins is
      not backward compatible with projects that want to use Hack.
      This way they will be able to migrate at their own pace.
 
      fredemmott - 2 hours ago
      > my ask is to just make a better language and drop ALL of
      PHP baggage.Long-term, we hope to make pure-hack projects
      more practical, and we're aiming to make Hack the best web
      development language. This will take time - both to decide
      what parts of PHP we want to keep (it definitely does have
      excellent parts), and how we want to change the things we
      think need improvement.> Because why even break support from
      PHP7 if you don't plan to change (fix) the builtins?Sorry, I
      was unclear: changing the behavior of the PHP builtins will
      break BC with PHP, and the result would still not be what we
      want for hack. We're likely to build Hack-only replacements
      for the PHP builtins, instead of changing the behavior of
      them.
 
    the_duke - 3 hours ago
    That naming convention seems quite confusing.Why not make all
    functions (standalone and methods) either snake or camel case?
 
      takeda - 3 hours ago
      I hope the previous post was a joke, because it felt like
      one.Edit: "We're moving towards functions_like_this(),
      instanceAndStaticMethodsLikeThis(), and async functions like
      foo_async() and methods like fooAsync()." C'mon. That doesn't
      sound like much improvement compared to the original PHP.
 
dcgudeman - 2 hours ago
I wonder what this means for wikipedia? Will they be migrating to a
hack only stack now?
 
maxpert - 3 hours ago
I am way less sad about HHVM now (specially after React license
debacle). I think Facebook now has opportunity to think about this
fork as a fresh take on PHP and maybe make the language awesome
both from syntax/performance perspective. I don't think living with
a weird hybrid with current language landscape is an option.
 
fiatjaf - 27 minutes ago
I don't like Ruby, but I can see why would people like. I don't
like Python a lot either, but I do write some Python, because it
has some clear advantages. Now what are the advantages that PHP
brings to the table?
 
  segmondy - 2 minutes ago
  Faster than Python and Ruby. PHP7 is actually a better OOP
  language than Python is. PHP is much easier to get started in and
  find "talent" for, tons of PHP developers out there.A lot of
  money has been made with PHP, the only reason many companies
  switched from PHP is that the developers wanted to "feel grown
  up" and switched to something else.
 
  grzm - 17 minutes ago
  There are plenty of places where you can view arguments for and
  against PHP alone and in comparison to Python and Ruby  on the
  internet. This submission is specifically about HHVM. Asking
  people to justify the use of PHP in such a context is just
  inviting a language flame war. Please don't.
 
bepotts - 4 hours ago
How is Hack? Has anyone built anything with it and would like to
share their thoughts? How's the HHVM community?I've always thought
that PHP was an underrated language that got a bad rep due to
whacky design choices and PHP developers being seen as "less
skilled" (a stereotype I know, but it is prominent) than others.
Object Oriented PHP and frameworks like Laravel were a nice change
of pace in my opinion, and there's plenty of good PHP coders out
there if they had the right experience and stuck to a good coding
guideline.Alas, I confess I stepped away from PHP due the
stereotypes against it, but HHVM always seemed promising. I haven't
heard much about it over the years though.What's the toolchain for
HHVM?
 
  kmavm - 3 hours ago
  I'm chief architect at Slack, and we migrated to Hack from PHP 5
  throughout 2016.The toolchain for HHVM is all installed as a
  single big deliverable, which gives you the language engine and
  supporting runtime libraries itself, an in-address-space web
  server (Facebook's Proxygen), a debugger in the form of hhvm -a,
  and the Hacklang toolchain accessed via hh_client and appropriate
  editor/IDE integrations.I share your intuition that there is
  actually a glittering core of "stuff-that-makes-you-successful"
  hiding in the incidental complexity of PHP, and we wrote this
  blog post trying to put some substance behind that intuition:
  https://slack.engineering/taking-php-seriously-cf7a60065329
 
  hobofan - 2 hours ago
  I have worked on a somewhat large-ish backend that was built with
  Hack. In the end, we dropped it in favor of PHP7, due to all the
  small incompatibilities it had, and all the non-standard things
  we had to do to use it. With PHP7 the performance difference was
  negligible (our original reason for choosing it), and the type
  annotations of PHP7 were good enough for us.With switching, we
  were also able to use phan[0] and other tools that helped us
  write better PHP code that were previously unusable due to
  Hack.[0]: https://github.com/phan/phan
 
  fredemmott - 3 hours ago
  I'll leave the first part of your question for someone less close
  to the project.For the toolchain, when using it: it's currently
  mostly the PHP toolchain (e.g. composer) with some additions:-
  the typechecker: this is a fast (I usually get full results in
  well under a second) static analysis tool, fully integrated with
  Nuclide (our IDE), and with excellent support in VSCode via a
  third-party plugin. This is a massive improvement in developer
  experience, especially when refactoring. Usually the unit tests
  pass first try once I've fixed the problems that Hack finds.- an
  autoloader that can handle any definition (e.g. functions,
  typedefs, constants), not just classes- the built-in webserver
  isn't just for development - no need for fastcgi + apache etc,
  though that is supportedAs for building/working on HHVM itself,
  it's basically modern C++ using CMake, and the Hack typechecker
  is OCaml.
 
  thinkindie - 2 hours ago
  Laravel is probably not the best example in terms of improving
  PHP landscape in terms of code/architecture quality: Symfony is
  way more prominent in that. It's not a case that Laravel is using
  many components from Symfony.
 
    akoncius - 1 hours ago
    it is weird for me why Laravel is so popular now given that as
    far as I've read documentation, a lot of it is written in
    static class calls, which is opposite of OOP and all good
    pratices coming with OOP.. I understand that it's kind of rails
    and gives short-term productivity, but if you have complex
    project, it will become an issue if majority of project code is
    spaghetti code without DI, IoC and so on.
 
      dabernathy89 - 1 hours ago
      Laravel's facades are not static method calls, and they are
      all configurable through Laravel's dependency
      container:https://laravel.com/docs/5.5/facades- edited to
      remove snark
 
        akoncius - 1 hours ago
        thanks for link, it explains a lot!
 
      cosmok - 1 hours ago
      Laravel encourages DI via Service Containers:
      https://laravel.com/docs/5.5/container And, Laravel static
      methods (as you see in the docs as Facades) are not truly
      static (and testable/mockable).
      https://laravel.com/docs/5.5/facades#facades-vs-
      dependency-i... http://usman.it/laravel-4-uses-static-not-
      true/
 
        akoncius - 1 hours ago
        thanks for response, will read it!
 
ankyth27 - 3 hours ago
Parse, react and now this. Why would I now learn any new Facebook
tech?
 
  cdelsolar - 1 hours ago
  what happened with React?
 
    hibbelig - 1 hours ago
    BSD+Patents license.
 
merb - 2 hours ago
I wonder why they just don't deprecate HHVM altogether and maybe
create a HACK version on top of GraalVM. This would probably be way
more performant and probably might be better for integration into
other systems.
 
the_duke - 3 hours ago
Has Hack actually gotten meaningful adoption outside of Facebook?I
never hear about anyone using it...
 
  muglug - 3 hours ago
  Slack does, and some (all?) of MediaWiki. Outside of that, I
  don't think it's enjoyed the sort of penetration of other OS
  projects from FB
 
    connorshea - 1 hours ago
    I don't think MediaWiki uses Hack, only PHP with HHVM (though I
    could be wrong).
 
  [deleted]
 
TazeTSchnitzel - 3 hours ago
Given HHVM is already being dropped from PHP packages because of
its lagging compatibility, announcing that they're not targeting
PHP compatibility any more might be the nail in the coffin for HHVM
(and thus Hack) as a viable ?upgrade? from PHP for existing
codebases.I mean, it's great that Hack will work for new Hack code
and existing Hack codebases, but there aren't a lot of those. It
makes sense for Facebook ? why waste your efforts on maintaining
part of your runtime that you don't need? ? but I wonder if this
will consign HHVM to irrelevance in the long term. Maybe Hack is a
compelling platform for new code, but then, why use this obscure
proprietary Facebook thing that's a bit better than PHP when you
could use any of the numerous other languages out there that are
also better than PHP but have much better ecosystems?Personally
this makes me sad because I wanted to see a standardised, multiple-
implementation PHP language. Facebook did, even. They paid someone
to write a spec: https://github.com/php/php-langspecMaybe someone
will write a new PHP implementation to take that idea forward. Or
maybe we'll be stuck with Zend forever.The future is strange.
 
  Twirrim - 1 hours ago
  It may be just my lack of familiarity with the PHP / Zend, but it
  seems like one of the most significant things that HHVM achieved
  was a wake-up call to Zend.  It seemed like they suddenly started
  putting some serious effort in to PHP7's runtime, and publicising
  what they were doing.  A bit of a wake-up call to a language that
  was languishing for performance.
 
  NightlyDev - 36 minutes ago
  Just wondering: "numerous other languages out there that are also
  better than PHP but have much better ecosystems"What languages
  are you thinking of?I've used a lot of different languages, but I
  still think PHP is awesome for web developmemt. Being normally
  limited to "one request, one execution" might be an annoying
  limitation in some situations, but other than that I think PHP
  does the job quite well. So that's why I'm wondering what you
  think is a better existing alternative.
 
  muglug - 1 hours ago
  It makes me sad that, as a Mac-based developer, installing &
  updating HHVM takes half an hour (via Homebrew). I imagine that
  has taken the wind out of many people's sails, when contemplating
  migrating/updating codebases to HHVM's (superior) syntax.
 
    fredemmott - 1 hours ago
    Sorry, I know this is a pain; I'm hoping to fix it by the end
    of the year (along with bringing back nightly debs, and
    supporting more recent versions of debian/ubuntu). For homebrew
    build times, there's https://github.com/hhvm/homebrew-
    hhvm/issues/5In the short term, docker works rather nicely.
 
ohdrat - 3 hours ago
Guess I'll mosey on back to OCaml then...
 
muglug - 3 hours ago
HHVM & Hack solved two big problems that made PHP difficult for
Facebook and other large companies with large existing PHP
codebases: Speed, and the lack of type checkingNow the PHP
ecosystem is more mature ? PHP 7 eliminated the speed differences
between HHVM and PHP, and a bunch of static analysis tools find 95%
of the bugs that HHVM's typechecker finds.It makes sense that this
would be an inflection point for the future of HHVM.I hope that
more features from HHVM make it into PHP core ? especially property
types and generics ? because, whatever FB decides to do with HHVM,
PHP is here for the long-haul.
 
  jimktrains2 - 2 hours ago
  > HHVM & Hack solved two big problems that made PHP difficult for
  Facebook and other large companies with large existing PHP
  codebases: Speed, and the lack of type checkingAt what point do
  you stop using the hammer to put in a screw and just use a
  screwdriver?
 
    muglug - 2 hours ago
    When the cost of buying screwdrivers for your entire workforce
    would likely bankrupt the company.
 
      jimktrains2 - 2 hours ago
      I'm not sure what you're analogy is here.  You wouldn't
      switch every nail to a screw in the same moment.
 
        muglug - 2 hours ago
        Right, but you're still investing time in doing that
        switch. No matter which way you cut it, you're still
        replacing every single nail."We'll just update as we go",
        you say. That's fine, but it means that some parts of the
        house ? normally the oldest and most integral to the entire
        structure - will use nails for years to come. And your
        developers will need to be trained in both hammers and
        screwdrivers to be able to work on the house in totality.
 
          jimktrains2 - 2 hours ago
          Sure, but if those nails are also causing structural
          instability, then it might be prudent to do the
          investment.  It seems now, no one will be using your type
          of nail anymore either, so now you have to have them
          custom made at expense.
 
    mahyarm - 2 hours ago
    When you want to replace all the nails in your house with
    screws, so you can throw away the hammer ;)
 
    [deleted]
 
  noir_lord - 1 hours ago
  If you are a PHP user and use Intellij/Phpstorm then this
  https://plugins.jetbrains.com/plugin/7622-php-inspections-ea...
  is utterly incredible.It catches so much stuff, I've been using
  PHP since 2009 and it there was still stuff I was doing day to
  day it flagged me for, it's not only that it makes you write
  better code but it catches so much stuff that you no longer have
  to hold in your head (things like "Method throws an unhandled
  exception" etc).In terms of "wow" (impact vs amount of effort
  required) it's second only to TypeScript in the last year or so
  for me.Not a co-incidence that both tools add better type
  checking (amongst a lot of other useful stuff) to the languages I
  was stuck using.
 
    minxomat - 42 minutes ago
    Thank you, that's a very useful plugin.
 
    muglug - 1 hours ago
    Thanks for the recommendation ? I've used PHPStorm when doing
    large refactors, and it's incredible.Unfortunately, you can't
    force everyone to use it (especially given its price). That's
    why a bunch of people have written separate PHP static analysis
    tools:Phan (https://github.com/phan/phan), PHPStan
    (https://github.com/phpstan/phpstan) and Psalm
    (https://github.com/vimeo/psalm), the last of which I created.
 
      exceptione - 30 minutes ago
      Psalm looks good, would be nice to integrate it into eclipse
      pdt as a plugin.