 was not expecting that introduction, so thank you. I did not know any of that stuff. Alright, so good morning. Welcome to PHP Comp Asia. Thank you for having me. My name is Davey Schaffick. And I am a developer evangelist at Akamai. We're the world's largest CDN, so check us out. So this is actually my first time in Singapore. My first time in Asia, actually, if you don't count Guangzhou Airport on the way over. So I'm really, really excited to spend some time getting to know the area, and more importantly, the community in the area that's know you people. So thank you for that. Every time I speak, you would have seen this last night, I always mention prompt. This is an initiative to get people talking about mental health and technology. It's really, really important. So mhprompt.org, check that out. So some of you may know, I am the release manager for PHP 7.1. I did not realize when I signed up that that is a three-year commitment, but it is. And luckily, I have a co-release manager, Joe Watkins. And so I'd like to start this morning off with an announcement. PHP is dead. Right? That's what people say. PHP is dying. Ruby's dying. Java's already dead. So you may ask, you know, as PHP developers, if PHP is dead, what are we going to do next? Right? So I'm going to tell you that today. Single page applications of the future. Right? That's what people are saying. And as you can clearly see in this graph from Google Trends, it's gaining popularity. So if single page applications of the future, what that means is that client-side MVC frameworks of the future. Right? Because that's what we write them in. And so here, again, from Google Trends, we can see Angular doing really well. React, which was released a couple years later, definitely catching up. So given this, you know, these client-side applications, building single page applications, we can definitively say that JavaScript is the future, the web. Right? So JavaScript, right? It's clearly on an upward trend. And it must be cannibalizing PHP, right? Because nobody programmed it more than one language. Right? Actually, that's not true though. This is actually the trends for JavaScript. So I find really, really odd. So apparently, JavaScript is also dying. So what about PHP? And this is what I find really, really interesting, is when we compare the two, this is the trend graph for PHP. And if we put them together, they almost mirror. Right? All of the peaks and all of the valleys match up. And it's really, really interesting. So what I think that this means is that PHP and JavaScript are intrinsically tied together, just as they have been forever. So PHP being the most popular server-side language, and JavaScript being, for all practical purposes, the only client-side language, we're still using them in tandem, and we're just changing how things work. So the difference in the workloads that we're using them for has shifted. So traditionally, PHP would be used to render and deliver all of the content to the end user, and then we use JavaScript to enhance that with animations and things like that. Where now what's happening is PHP is being used to create APIs, and they're being used to manage shared state, now whether that's between multiple users or very often the same user on multiple devices. And then JavaScript is being used to do all of the rendering and interaction. So we're just shifting what we're using for what parts of the stack. So if PHP and JavaScript are both trending down, and we know that there are more developers today than there ever have been, where are they going? Right? So obviously, we can start to look at things like new languages. So here we have Mozilla's Rust. It's not very obvious, but it is trending up. Another new one is Google's Golang. Now this one has an obvious upward, like any startup would be proud of this, right? You know, up into the right hockey stick. It's great. And if we put the two together, you see Rust barely registers. So Google's doing really well in this space. But if you add PHP, neither of them really register, right? We are obviously still way more popular than both of these so-called trendy languages. All right, so people are not just moving to new languages. What else are they doing? So maybe they're moving to new paradigms. So things like functional programming. And they're doing that not necessarily on new languages, but maybe older languages, like Haskell or Erlang. So as most people know, PHP started out as a purely procedural language. And then in PHP 4, we sort of bolted on objectorians and stuff. It wasn't that great. But in PHP 5 and all the releases since, we've been improving that experience and really making PHP a good objectorian language. But PHP has never been a functional language. And basically everybody in their elephant is talking about functional programming these days, right? So as you can see here, as we would expect, objectorian programming is definitely trending downwards. And functional programming is slightly trending up. And I think at some point in the future, they're going to converge out there on that side of the graph. And we're going to have one single objectorian functional paradigm of some sort. That's obviously what's going to happen. So maybe that's not the reason why PHP is trending down. Maybe it's skill sets. Maybe it's the jobs that are out there, right? So here we can see full stack developers trending up. We also have 10X developers. They sort of peaked in 2014. I think they got burned out at that point. But you know, it's happening. But if we compare that to traditional developers, we can see that we're still very much in demand as PHP developers. And there's also some interesting mirroring that happens here. And I think what's going on is because full stack comprises both back end and front end, PHP still being the most popular back end language. We're just seeing a change in like job ad descriptions. They're not looking for full stack developers, not PHP developers, right? So I don't think this is a problem either. Okay. So maybe I exaggerated. And PHP is not really dead. But we are definitely seeing a downward trend. And I think that we as a community are in control and can control the narrative around that. And I think we're responsible for doing that. For the success of PHP as a community, as a language. So I want to talk about what progress looks like. So PHP still powers 82% of the web. And that's more than five times its closest competitor, which is ASP.net. And the rest barely even register, right? Additionally, since February 2012, we've had at least two releases every single month. That's like 63, 64 months in a row. And I think that's pretty impressive. And any project that can claim that is obviously thriving. Or they have a lot of security bugs. So of course, last year, we released PHP 7, which has been the biggest and best PHP release in a long time ever, maybe. And certainly the first major release we've had in about a decade. So what versions of people are actually using, right? We can look at this to gauge the health of the community and how fast we're moving forward. So unfortunately, uptake here is not great. It doesn't look great. So PHP 7 is barely passing PHP 4 at this point. And that only happened like two weeks ago. When I first wrote this slide, it was a 1.1 for both. So just hit 1.2. And this alone, I think is, if you look at it just like this, is an indicator that PHP is dying. And yet, if we put some context around it, and we remember that PHP 7 hasn't even been out a year yet, you take a look at the six months prior to 5.0, for example, we can see here that we have a slow upward trend a little bit bumpy leading up to the release, we have a ginormous spike. And then we have this sort of down and then upward trend, right? It's the first 12 months of PHP 5. And if we do the same for PHP 7, that actually looks quite similar. And this one actually is a continuous upward trend. I think this is even better. And if you combine those together, we can see that we're pretty close. For the first year of adoption for PHP 7, we're looking at similar numbers to PHP 5. It's just going to take time. PHP 5 has been out a long time. So we take all of that stuff and we added that to the third party ecosystem that we have. So if you take a look at packages, for example, which is the main repository behind Composer, which is our standard now, right? We can see in this graph that there are now over 100,000 individual packages. And while that doesn't look huge and it's certainly not sort of an astronomical growth, what this really means is that we have stability. We have excellent packages like those provided by the PHP League. And they solve all of our common problems already. We are not continuously reinventing the wheel. We have matured. More telling is that we have now almost 600,000 releases of those 100,000 packages. So there's definitely enough for trend there. And I think that this is indicating that package development is happening at a very rapid pace. Lastly, we can look at the number of package installs per month, which is now at almost 170 million, which I think is pretty incredible. My notes literally say breathe. So give me a second. Okay. So back in 2012, a blog post was published. But basically everyone, whenever they say, is PHP dead? Is it dying? Should I be using it? Should I be using something else for my new project? PHP, a fractal of bad design, is always brought up. It's like the definitive resource for PHP being terrible in every single way. And it spawned this double-clawed hammer, sort of a representation of PHP and its terribleness. And in that blog post, the author gives several key traits that a good language must have. So the first two, I think of the same thing, which is predictability and consistency. And this is something that PHP has tackled since the addition of late static binding in 5.3, uniform variable syntax in 7.0, and also a language specification that was added somewhere between 55 and 56 thanks to Facebook. The next one is it has to be concise. And so in 53, we added closures. Callables and traits were added in 54, generators in 55, and anonymous classes in 7.0. And all of these help us write more concise and flexible code. It must be reliable. And in my opinion, with a shared nothing architecture, PHP has always been more reliable. Starting every request with a blank slate and no shared state means that you get repeatable results every time. And additionally, we now have PHP FPM. So it's easier than ever to scale reliably and with good stability. And then the last one is that it should be debuggable. And XDBug has been available for years. And it's stable. And it's supported by many, many IDEs and editors. I use PHP Storm, and it has amazing support to where it'll show like expression results in the editor in line as you step through. So it's not even a bad debugger. It's a phenomenal debugger. And then in addition, we added PHPDBD and PHP 5.6, which is a command line step-by-step debugger similar to GDB for C or C++. So if PHP is alive and well, is it really evolving? So I've been speaking now about PHP since 5.4, which coincidentally, it was like two months before that blog post came out. And I think that I can definitively say that, yes, not only are we evolving, we're doing so at a great pace. So just some of the features that have been added include short echo tags, binary number support, short array syntax, array dereferencing, dollar disk binding enclosures, the callable type in, traits for horizontal reuse, the built-in CLI server, list support and fore-eat, arbitrary expression supports for empty, string and array dereferencing finally blocks the password extension, generators and co-routines, the language specification, the exponent operator, constant scalar expressions, PHPDBG, the importing of namespace functions in constants, variatics, argument unpacking, otherwise known as splat. We removed the alternative PHP tags like the script tags and ASP tags. We removed the positive regular expressions and the original MySQL extension. And even with all of those changes in new features, PHP is now 2.4 times faster and uses way less memory. We have an abstract syntax tree, uniform variable syntax, engine exceptions for better error handling, Unicode escape syntax which is probably the most important feature because now we can do emoji. We have the null coalesc operator and binding enclosures on call, group use declarations, generator delegation and return values, anonymous classes, scalar type hints, return hints, strict types and most importantly the spaceship operator, otherwise known as the combined comparison operator. So that's just up till PHP 7. So let's talk about the future, which brings us to PHP 7.1. So with PHP 7.1, when you call the userland function without enough arguments, it will now throw an exception instead of a warning. So here we have a function called hello, which takes a single argument dollar whom and it simply calls echo hello dollar whom, nothing complicated here. And then if we call it with no arguments in PHP 7, this will give us a warning, missing argument one for hello and shows the call site and the definition site. And then because of this warning, because it is a warning, it will continue to run the code and it will give us a notice for the undefined dollar whom and it will echo out just hello and a space. Now in 7.1, we get a fatal error because there's now an uncaught exception. And of course this is a BC break and I'm really not happy about it. So you'll notice here also that it is an error exception. It's not a very good exception, it's the top level of that exception tree. So I put a patch in last night, which I'm hoping is correct and that will be accepted to make it a two, what is it, argument count error exception, so at least it's a little more specific. We'll see how that goes. Unfortunately it also adds exceptions for warnings when you're passing in arguments to some of the array functions. Now the way that this works is it only affects userland functions unless you're in strict mode, in which case it will give you an error actually for passing in the wrong type if you don't pass in an argument. So to solve this, we must now add a tri-cache block, right? And you may ask, why would we put a tri-cache block around a function call? Why would we even have code like this? And the answer to that is actually argument unpacking, or splat, right? So here we have the hello function now takes two arguments and we define an array of arguments here. Unfortunately we only have one value in the array, so when we try to unpack it, we don't fulfill the requirements of that function. And so tri-cache, we get our exception. All right, so next feature, negative string offsets. This is actually kind of cool. So basically what they have done is they've added consistency for supporting negative string offsets throughout the language. So it's similar to the substring function where you could provide negative offsets, but it's also in string character accessors and a whole bunch of other internal functions. So this is something I'm sure most of us have written. To check if there's a slash on the end of a path, we do substring minus one, right? Well in PHP 7.1, we can now just do this, or you can use the curly brackets version if that's what you like. Both of those are the same. You can also set characters. Now you can only set characters that already exist, but if they do, I'm setting here B to Z, sorry. You can also check lengths because you can do is set. So you can call strlen or you can do an is set on either a positive or negative offset. That's terrible, but you can do it. As I mentioned, there's a whole bunch of functions now that have added support for negative offsets, so it brings consistency with the substring function. Another great new feature we have is closure from callables. Essentially what this does is it adds a new static method to the closure class called from callable, and you pass in any callable and it will give you a closure back that when you call it will call the callable. We can use this for closing over scope. Here we have a validator class and inside of it we have a get validator callback function. It takes one argument which defines the type of validation that we're going to have. So if it's email, then we're going to pass back this email validation. So we're going to call the email validation method on this, right? Simple callback. Otherwise you do generic validation. Unfortunately, because we don't want to expose these, we've made these private. This makes sense though. This is the API that we want to provide. We don't want people calling these directly, so we want them to be private or protected. So dollar validator equals new validator. Get the validator callback and try to call it. And when we do that, we get a fatal error of call to private method validator email validation. So with private functions, we can simply make them public, right? But that's now polluting our API and it's something we're going to have to support when we release packages into the wild. So instead what we can do is instead of these calls where we're returning the callbacks directly, we can now use this closure from callable and just pass it back there. And they'll get a closure back with dollar this bound to the instance of the validator class and therefore we're no longer outside of scope. So these stay the same and everything's beautiful. Now we also get better error handling with this. So take this closure from callable here. If I had made a type up and missed the i in validation, normally you wouldn't get an error until you try to call it and it would be method does not exist. But instead, a definition time we now get failed to create the closure and we can see exactly where it's defined and we're not doing it at run time. It's still run time but not the call time. And this works with any callback. So here we have a function that does not exist. It works great. Another simple but great addition, class constant visibility. So simple class with a number of constants. We can now set the visibility. So we can do public, protected and private and also if you're finding multiples of the time, you can say all of these are private. Pretty simple. It also works for interfaces. That's in there. There's some enhancements to reflection to support this. So reflection class now has these get reflection constant and get reflection constants. And they will return either a single instance or an array of instances of the reflection class constant object. And that's really cool because it has things like is public, private and protected. But it also has get.comment. So if you're doing some things that are parsing out.comments and previously you had to like parse the file by hand because of constants, you can now use this which is great. Great addition to reflection. We now have the ability to catch multiple exceptions. Now you may have done something like this in the past which this is totally valid. It has been since exceptions were added. So we have a try block and then here we have catch PDO exception and we'll throw 500 error. Catch some other exception. Throw another 500 error because you have to catch them separately. And then this one which will catch 405. Alternative being catching something that's like slash exception and then figuring out which is kind of terrible. But obviously we're duplicating some code here and it's not great. With 7.1 we can now take this duplicate of stuff and we can simply add a pipe. And we can specify multiple exceptions that we can catch in a single block. We have a bunch of improvements to the list construct. So the first one is specifying keys in list. So if we have for example an array here with coordinates in it, so latitude and longitude. And we go ahead and list that out with list lat long equals chords. What we get is two notices, undefined offset 0 and 1 because it's expecting integer keys that start from 0. And if we dump that obviously we get two nulls. This is obviously not the result that we want. So what we can do in 7.1 is we can just simply specify keys. So now we can use list with associative arrays. So obviously if we far dump that we get our coordinates. It works exactly like we would expect. You can also use it for skipping numeric keys. So I actually didn't know this but if you want to skip numeric keys you can by using empty commas. This is so horrible. But now you can just specify the keys and everything is very clear. This is great. We also added short list syntax. So similar to array syntax. So just like we had arrays going from array parentheses you can now go from list to brackets. This is great. It is important to note that these two syntaxes are mutually exclusive. So while you can't nest them you cannot nest the types. So lists with nested shorter lists not valid. Short lists with nested lists not valid but you can nest short lists and short lists and lists inside of lists for multi-dimensional arrays. We've also added the iterable pseudotype. This one's really cool. So it's similar to the callable type but all the values are something you can either for each or yield. So it accepts any array or an object that implements traversable. So that includes all of the SPL iterators. That also includes generators. And it can also be used for the return value. So here we have a function enumerate that has an iterable argument. And we know because it's iterable that we can for each it. We don't need to check. We can just do it. So as a return type, so here we have iterable return type. Now because actually I'll go back. Because I used a variadic there, all of the arguments are going to come in as an array. So I can literally just return that. That's valid for iterable. But we could also make it a generator and yield inside of for each as well. That's really cool. It also adds the iterable function which we'll just tell you. Would it be valid as an iterable? So basically arrays, traversables, and generators will pass. Other things won't. We have the void return type. So this says that a PHP function must not return anything. So in PHP, all functions implicitly return null. But there's a semantic difference between returning null and not returning anything. PHP technically is not a difference, but for humans, there's an actual semantic difference. And what void does is it enforces this behavior. It can only be used as a return type. It doesn't make sense otherwise in PHP. And it cannot be changed in subclasses. So here we have a function return nothing with a void return. And you'll notice here that I have return void. And if I try to run this, this is actually a compile time error that will give me a fatal error. A void function must not return a value. Did you mean return? Instead of return null. Very useful error. So if I switch my function to return nothing, for example, I get the same kind of thing. So the valid return types are return with no value or no return. So we're just enforcing this. We've also added nullable types, which is one of my favorite features. Something I loved from hack. So glad we had it. And what it allows you to do is to say I want something of this type or null. But you have to be explicit about that null. It's not a default value of null. And so the way that this works is you add a prefix of a question mark to the type and it's valid in both arguments and return types. So function hello. Now it takes a string dollar whom. Echo hello. And we have the nice coalesce operator there. If it's not set, set it to world. If we add the null coalesce, sorry, the nullable type question mark and we try to call it with no value, we get a fatal error because we have a type mismatch to a few arguments. That same error again that I'm changing. So we have to explicitly pass in null. This means that we are explicitly deciding this is the behavior that we want. It's not something we're going to accidentally do. If you want it to be optional null, just add equals null, just like you did before. And there's no functional difference actually in that function with or without the nullable type. Nullable return types. So this is sort of functionally the opposite of void, which means you must return something of the type you specify or an explicit null. So here we have hello, question string, return to string. If whom is not null, return the string. If we call it with world and it will hit that if and that's fine and it will return as a string, that passes the test. But if we call it with null because we don't want anything back, we get a type error because the return value is not a string or none. Null. So what we have to do is make it a nullable string. But now because we're still not returning anything explicitly, we still get the same error. We add a return, same error. This is the opposite of the other error. Did you mean return null instead of return? So we explicitly have to have return null. So this is again about making our code more expressive and more stable. And of course, we get null returned. So currently, last week, from the future because I was in Australia, I released 7.10 beta 3. Please go test. So all being well next week, we should push out release candidate one. Which is pretty cool. I'm excited about that. So let's talk a little bit about the future. Let's go beyond PHP 7.1. So after 7.1, obviously we have 7.2. I say obviously there are still things happening about 8.0. So who knows? We currently have 26 RFCs. There's also one for PHP 8. And there's one that passed for PHP 8 already, which was the constructors being removed. They've deprecated in 7, removed in 8. So 26 open RFCs, two of which are being voted on right now. One of which already passed for 7.1 and is being pulled over because it wasn't completed in time. So over the next six or eight months, you have an opportunity to step up and contribute to the next version of the language that you use each and every day. And even if you don't know C very well, like me, or you don't know it at all, like me six months ago, you can be part of the discussion. You can help write RFCs. You can help write documentation or the language spec. Or you can just grab the source code and compile it. Run your tests because everybody has tests. Run the tests that come with the language or better yet, run your application on it and actually observe behavior. Is it behaving in a backwards compatible manner? Furthermore, we widen our view just a little bit. HTTP 2 is not just coming, it's here. With over 60 percent market share is currently available to the majority of users today and it has the potential for massive performance wins with the introduction of multiplexing and server push, which if you saw my talk last night, I'm super excited about. To take advantage of it though, we're going to have to come up with some new architectures and techniques with more and more asynchronous and parallel architectures for multiplexing. And we need to do this as a community. So in summary, PHP 7.1 should be released in mid-November of year this year, so that's just three months away. And I think the future is going to be pretty awesome for the web, which means it's going to be pretty awesome for PHP because we are the web and you can be part of that. So soon we're going to need to figure out who the release manager is for PHP 7.2 and maybe it could be you. Thank you. All right, thank you, Davey. Hi, everybody.