The Future of HHVM
hhvm.com
hhvm.com
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-langspec
Maybe 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.
In the short term, docker works rather nicely.
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.
I can understand the plus points are an enviably simple deployment story and ease of recruiting developers. Is there anything else that you would argue makes PHP especially suited to the web over other competing languages?
I really dislike working with Ruby because, you know, who knows what the hell the code does until you try running it, and the IDE support is terrible.
On the other hand, working in "modern" OO PHP feels a little like working in a weird, older version of Java. PHPStorm can give a great IDE experience, I can add type declarations everywhere, the code is generally predictable once you learn some PHP quirks, etc. Also, in my opinion, Symfony is way better designed than Rails, and definitely closer than ASP.NET MVC than Rails is.
I feel like it'd be a pretty different story if I were working on Wordpress or some ancient legacy PHP code or whatever, but I'm not, so that's not really my concern.
Until you start playing with sockets or things like kafka then you really want languages which are made for long lived processes. But if you're just making a REST API, blog or anything which is not an app with sockets php is a good choice. Especially since 7.0, composer and the current leading frameworks Laravel and Symfony changed the landscape.
I also find that developmemt time is quite fast, even without using frameworks.
You probably don't need templating languages or frameworks, php makes it easy without it, it's built for it.
The performance is quite good, way better that most people think. It's also easy to write functionality in C if you really need to go all out.
For other stuff than web development PHP has it's downsides. It's made for building websites and in my opinion it's doing that job very well, but most other languages are general languages that works better for most other things.
I think most people would enjoy PHP way more without a heavy and insanely slow framework.
A programmers response is “I can throw Django in a container” or “I can just buy a digital ocean droplet”, and that’s true for a Developer, but it’s like putting Linux on your grandma’s laptop - you can maintain it, but the target audience can’t
The reason people build sites in PHP is that the people for whom they’re building the sites can trivially support it. Forever.
They're dropping PHP5 support, but it sounds like they're not actively trying to be incompatible with PHP5, so I doubt that gets worse right away. There's no existing codebase that's PHP7 already that would consider Hack, is there?
Now 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.
At what point do you stop using the hammer to put in a screw and just use a screwdriver?
"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.
If you're a SV company with unlimited cash flow: never.
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.
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.
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.
https://github.com/facebook/hhvm/blob/master/hphp/hack/PATEN...
It gives you more rights. Full stop, end of story.
React has managed to bring together people in C#, Python, Ruby, and Erlang to name a few languages... who all previously used different frameworks, or just jQuery.
/sarcasm
This is a multi horse race and even if you are not scared of patents it might be unwise to bet on the horse you think will scare other people. (Case in point, Wordpress.)
Fact of the matter is, it's just posturing. Software patents are utter bullshit and the facebook license clause reflects this.
But this basically gives a BSD plus patent grant, and reverts to BSD if there are any patent litigations. And now people are complaining.
https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revok...
- 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
HHVM is way too niche to bother with it, sorry.
So there's not really a choice to make. HHVM was tiny anyway.
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?
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 supported
As for building/working on HHVM itself, it's basically modern C++ using CMake, and the Hack typechecker is OCaml.
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
Remember BML, bradfitz' attempt to do this with Perl?
I would love to see someone do something similar for Python.
== has always been working in PHP. I know maybe that optional type coercition trips up some noobs occasionally before they made any effort to learn the language (hint === doesn't coerce types for equality), but how low effort does a complaint have to be?
Type coercition is actually pretty cool when you're not really sure what the browser or client is about to http at you and you just want it to work. It's much better than crashing at runtime because '12' isn't a number. If you're input isn't sane, throw an exception or use a validation library.
Now if we're talking about a good type system that can be enforced at compile time like rust, Scala, etc. Sign me up. But if it's run time, it's run time, we gotta keep going.
something something yell at you for breaking their door
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.
https://laravel.com/docs/5.5/facades
- edited to remove snark
Anyway, it's proven that without competitors to Zend Engine, the PHP team simply doesn't care to pay much attention to performance. (Snide comments about performance from maintainers and internal PHP contributors can be found all over the Internet to prove this point.) I am afraid this will continue as HHVM splits from PHP and moves more towards a JVM-type future.
Hack will be the "serious" language while PHP7 will serve a solid niche, and one I'm continually proud to support and use in production.
Nuclide works well enough with Hack and the typechecker is really solid.
I'm excited to see the future of both projects, but again, it is important to note that HPHPc by Facebook pushed PHP's project team into caring about a lot of this stuff over the years. I hope it doesn't take that kind of disruption to continue development, as I think PHP is in a really good spot now and don't want it to stagnate.
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.
While this is probably still true[1], it's certainly less of a concern now than it was with 5.x. Would (often negligible) performance boosts be enough for someone with a 5.x PHP codebase to choose Hack over PHP 7.x? I can't see that for most cases.
https://kinsta.com/blog/the-definitive-php-7-final-version-h...
PHP is IMHO the most productive and easiest platform for web development:
- a request
- a response
- templating
- no shared stated
And 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.
Have a look at Python & Flask! There is nothing easier than that!
The Slack article posted elsewhere in these comments https://slack.engineering/taking-php-seriously-cf7a60065329 has some excellent arguments about why PHP's approach is different in interesting ways.
What? PHP is significantly easier to roll out for your beginner/intermediate junior developer on a VPS. There isn't any comparison.
This comes from someone who leans on Python hard for ML work / scraping / signal processing (what it was born to do) and PHP for web development (what IT was born to do).
That's called the Web. :-/
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.
Also, I run a pretty big MediaWiki site and the last time I tried moving everything to HHVM (~6 months ago, I think) stuff appeared to be working initially but randomly broke from time to time (probably because of Scribunto or some other extension; couldn't manage to pinpoint the exact reason). PHP 7 didn't give me any problem at all; it's fast enough (way faster than PHP 5) and most pages are served by the Redis cache anyway. I suspect that Wikipedia will consider a move back to PHP, they're moving the most expensive logic to Lua modules anyway...
So if we get to a point where HHVM is completely irrelevant, it simply means "Mission Accomplished".
I never hear about anyone using it...
I'm really going to miss XHP. Native XML support has ruined me for templating frameworks. I never want to write HTML as concatenated strings ever again.
I'm interested in things like this as well. Can you provide an example of what you're thinking of? Something like JSX? Other data structures that are transformed into HTML by a library? The latter seems to be counter to your argument about requiring the use of some framework or library, but I can't think of any alternatives off the top of my head.
But with XML as a native data structure you can do things like typehint a tag:
public function setTitle(:document:base $base, string $title): void
{
$base->setAttribute("pagetitle", $title);
}
A template engine can give you context-sensitive escaping, template caching and inheritance, macros, and other features that increasingly become necessary for modern web development, and many of which you would probably wind up implementing anyway, once a project reaches sufficient scale and complexity. While raw PHP is arguably faster, it's also more difficult to do properly.
Also, culturally, the PHP community isn't as centralized as other web development language communities seem to be. It doesn't have one 'correct' framework or one 'correct' templating language you're expected to use, so there is competition between multiple engines.
But the end result is still the same in either case, basic CRUD - taking an HTTP request, getting some data, pushing it into a template, and sending a response back.
> But the end result is still the same in either case, basic CRUD - taking an HTTP request, getting some data, pushing it into a template, and sending a response back.
Sure, that's what most PHP apps do... but it's also what most Rails, ASP.NET MVC/WebAPI, Spring, etc. apps do too. And it involves a fair bit more than templating -- database access, data validation, security, etc.
It's true that PHP is rarely used off the Web (although it's possible), but I can't see how what you're describing makes PHP different from any other technology commonly used for Web dev.
E.g. FunctionName() vs function_name().
Or
E.g. return 5x20; vs return "5"x10;
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...)
Why not make all functions (standalone and methods) either snake or camel case?
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.
HHVM will not aim to target PHP7
When you say:
We're unlikely to change the PHP builtins
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.
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.
This is definitely an area we're planning on working on - and this post is meant to be announcing the start of this work, not that it's ready :)
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.
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.
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.
No-one's upgrading from Grails version 2 to version 3, or starting new projects in it any more.
Apache Groovy's good for scripting on the JVM -- just don't build any systems with it. Systems on the JVM should be built in languages that were statically typed from the ground up, like Java, Kotlin and Scala. Static typing was grafted on to Groovy in version 2, and not used very much, hence no-one's sure about its quality. Best use Groovy for glue code and build scripts only, which was its original purpose back in 2003.
> The skill level of Python and Java/Groovy developers tends to be higher than PHP
Now this is starting to look like an advert for Groovy, assuming all Java programmers also use Groovy, and associating it with Python in contrast to PHP.