PHP 7 will (likely) have return types

PHP 7 continues tightening towards becoming a good general purpose high level language. Having return types is one of those “means business” things, which may increase the demand for top-tier work in PHP.

// Here is a brief example of the syntax in action:
function foo(): array {
    return [];

We always want the interpreter to help us catch situations when things aren’t working the way they should, but the interpreter knows only so much about your expectations. Even though PHP is meant to be a quite dynamic language, more often than not we do know what type of data a function is always meant to return. So, why not share that information with the interpreter? There’s zero advantage to keeping it to ourselves.

It’s important to note that this is not a prescriptive requirement. If you don’t care about the returned type, or you are cowboy-coding and need the output before you need tighter type safety, you don’t have to specify. The cognitive burden is negligible and, in fact, it saves us having to write our own type check, then throw an exception, then make everybody else aware of what the error is going to look like — it all will be standardized through the return type declaration and the associated exception.

Let’s say we have this code:

function file_name( $path ) {
    // do_something
    return $file_name;

function output_file( $f ) {
    return basename( $f ) . '.to.xml';

foreach ( $path in $all_files ) {
    try {
        $i = file_name( $path );
    } catch ( Exception $e ) {
        // handle errors
    $o = output_file( $i );
    $xml = convert_to_xml( file_get_contents( $i ) );
    file_put_contents( $o, $xml );

Lack of proper validations and other questionable behaviors aside, in the code above we are assuming output_file() will always get a String from file_name() (it even has a try catch block, which may give us a false sense of security). But maybe we did some changes in the “// do something” part of file_name() and now it unexpectedly returns false instead.

The thing is, no exception will be triggered, basename will take the false, and it will happily turn it into an empty string. Our code will then proceed to overwrite again and again the file “.to.xml”, until it finishes looping and exits without having told us there was anything wrong.

On PHP 7, by just writing:

function file_name( $path ) string: {

any issues that return a wrong type will trigger a “function answer was expected to return an object of class” exception, which can be caught before it does any damage — it won’t free us from performing other validations, but a whole lot of worries have been removed by adding a single word, which happens to double as function documentation (no more adding a docblock comment just to indicate the @return.)

On service quality alerts, by a Google engineer

It definitely does feel right when your tests are sitting on the same side as the users. No ifs and buts regarding how you hooked your test to the back-end — what you see is what you get.

Alert on the data unavailability. Alert on the symptom: the 500, the Oops!, the whitebox metric that indicates that not all servers were reached from the database’s client. Why?

You’re going to have to catch the symptom anyway. Maybe it can happen because of network disconnection, or CPU contention, or myriad other problems you haven’t thought of yet. So you have to catch the symptom.

LinkHacker News comments.

PHP’s creeping back

Nobody wants to like PHP as a general-purpose, server-side web language — so every year we have a new popularity shift to other languages that address some of its shortcomings. And still, it seems none of them are being adopted fast enough (and I mean, really really fast) to displace PHP from its home turf on the web and overrun its evolution pace.

You likely know that Facebook’s engineers have been working on upgrading PHP’s interpreter —the part that runs the scripts— and language, adding stuff like optional static typing. While currently PHP’s vanilla performance sits in the “slow” pack together with Ruby and Python, Facebook’s HHVN interpreter and Hack language extensions are a whole lot faster. This is, by the way, parallel to PHP’s group own development, which will provide similar improvements on PHP 7.0. No matter where you look at there’s a big push to improve the humblest of the web languages.

So, logically, Wikipedia, one of the biggest users of PHP, has been actively working on making the migration possible:

In March 2014, a group of MediaWiki developers started working on ensuring that the codebase, along with the various PHP extensions used on Wikimedia servers, were compatible with HHVM.

Users will see performance improvements in many places, especially when editing extremely large articles. If you’re interested in helping the development team out with finding bugs, or just want your editing experience to be faster, you can enable the “HHVM” betafeature in your preferences.

Yes, PHP is still the overweight city guy that for a long time ate whatever and didn’t try to work out or do things outside his familiar routine. But he’s got now a half-decent diet, an okay bicycle to zip around urban congestion, and he still has a job with lots of demand.

On a practical level, outrunning the guy is definitely not as easy as it seemed in the past. Neither Ruby, Python or Perl (not to speak of other more system-level languages) really nudged it from web dominance when PHP was sloppy — a fair assumption would be that the window of opportunity to do so is closing, as PHP’s remaining shortcomings become less and less critical, and therefore PHP will remain the main language of general web applications in the future.

So going forward businesses and professionals are looking at CSS, HTML and JavaScript, which are likely staying. If you can filter out bad coders and have no special need for something like Go’s performance, you have Hacklang/PHP for server-side code. Then you’ll probably need some Bash, a general purpose scripting language (which is typically Python, although this role is a lot about whichever language offers you the libraries you need), and a systems level language (C, C++, Java, etc., maybe Rust eventually.)

But obviously, there’s always a temptation to minimize your polyglotism needs. Until recently, there was this feeling that PHP was the one going to be squeezed out soon by either Ruby, Python or even server side JavaScript. That’s not so clear cut nowadays, which probably means someone else’s favorite is actually the closest one to falling out of favor.

I’m not a fan myself of the idea that a multiplicity of production languages is the normal state of things (although I prefer it very much to being locked into an horrendous, unwieldy one). We had multiple languages in the past for plenty of reasons: proprietary standards, lack of standards, closed standard setting communities, immature or quickly evolving technologies, not enough shared and proven knowledge on what works and what not, different hardware limitations, incompatible hardware platforms, wild differences on available libraries, plain money making decisions, etc.

I do love that so many different ideas are being tried and explored — I find it relieving when proposed changes include examples of how they worked in other languages. But I also love to get things done, and it’s still weird when the choice of Turing-complete language to do so is such a huge day-one roadblock. It’s not that easy to remember situations where the underlying language’s virtues were decisive to a product’s success — Twitter made it with failwhales, bugs and all —, it seems the most dramatic factor to success is having a viable product, not just the best plan on paper.

So in the real world’s day to day there’s going to be only so many other priorities than productivity, which means there’s going to be only so many languages needed to do something optimally. We haven’t figured out which ones yet, but PHP is not anymore the one trailing behind — and a kind of big final rush seems to be on.