Podcasts about hhvm

My guest today is Evan Cheng, co-founder & CEO of Mysten Labs. Mysten Labs is a team of leading distributed systems, programming languages, and cryptography experts whose founders led Meta's Novi Research and helped develop the Diem blockchain and Move programming language. The mission of Mysten Labs is to create foundational infrastructure for Web3. They partner with crucial ecosystem builders to make step-change improvements to their networks. Before co-founding Mysten Labs, Evan helped lead Novi Financial and was the research and development director. Evan focused on systems & security, programming language & formal verification, and new product experimentation as the Director of R&D at Novi Financial. Novi Financial is Meta's crypto R&D division. Before leading Novi Financial, Evan worked at Facebook as the Director of Programming Languages and Runtime. Evan focused on supporting Facebook's world-class team in programming languages, runtimes, and compilers: Hack, HHVM, Skip, Flow, Python, Reactive programming, C++, LLVM, Android + iOS mobile runtimes and optimization pipelines, mobile JavaScript platform, and runtimes, Glow, and more. Evan worked at Apple for over a decade, where he was a third-level manager overseeing seven engineering teams. He focused on leading efforts in static and runtime compilation for both CPUs and GPUs, Swift performance, static and dynamic linker, shared cache optimizations, debugger, and bitcode tooling. He collaborated on HW transitioning plans, a simulation tool for early GPU architecture exploration, built & integrated tools, App Store tools, and security hardening. Evan Bootstrapped various new "engineering effectiveness" initiatives. In our conversation, we discussed multiple topics, including; Mysten Labs, the future of Web3, the infrastructure of Web3, decentralization, and much more. We began our conversation by discussing what attracted Evan to crypto and what compelled him to make the jump to start Mysten Labs with co-founders. Evan explains why we are at the precipice of the next innovation wave in crypto. Our next conversation topic centered around the infrastructure layer of crypto. Evan discusses the various limitations current blockchains have to meet the rigorous demands of scaling and composability. Evan addresses how Mysten Labs is building tools and infrastructure to solve these bottlenecks. Our conversation pivots to discuss the future of Web3 and NFTs. Evan outlines why we are still in the early days of NFT and Web3. He discusses how the NFT space may evolve as the tools and infrastructure built around NFTs and Web3 becomes. One significant evolution we discussed is how NFTs will be able to send and receive data unlocking a tremendous amount of potential for collaboration and value for both builders and owners of NFTs. We finish our conversation by discussing how we imagine NFTs and Web3 changing how society interacts and communicates. Please enjoy my conversation with Evan Cheng. -- This podcast is powered by Blockworks. For exclusive content and events that provide insights into the crypto and blockchain space, visit them at https://blockworks.co

PHP Internals News: Episode 64: More About Attributes London, UK Thursday, July 30th 2020, 09:27 BST In this episode of "PHP Internals News" I chat with Benjamin Eberlei (Twitter, GitHub, Website) about a few RFCs related to Attributes. The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode's MP3 file, and it's available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news Transcript Derick Rethans 0:17 Hi, I'm Derick, and this is PHP internals news, a weekly podcast dedicated to demystifying the development of the PHP language. This is Episode 64. Today I'm talking with Benjamin Eberlei, about a bunch of RFCs related to Attributes. Hello Benjamin, how are you this morning? Benjamin Eberlei 0:36 I'm fine. I'm very well actually yeah. The weather's great. Derick Rethans 0:39 I can see that behind you. Of course, if you listen to this podcast, you can't see the bright sun behind Benjamin, or behind me, by the way. In any case, we don't want to talk about the weather today, we want to talk about a bunch of RFCs related to attributes. We'll start with one of the RFCs that Benjamin proposed or actually, one of them that he has proposed and one of them that he's put into discussion. The first one is called attribute amendments. Benjamin Eberlei 1:05 Yes. Derick Rethans 1:06 What is attribute amendments about? Benjamin Eberlei 1:08 So the initial attributes RFC, and we talked about this a few months ago was accepted, and there were a few things that we didn't add because it was already a very large RFC, and the feature itself was already quite big. Seems to be that there's more sort of an appetite to go step by step and put additional things, in additional RFCs. So we had for, for I think about three or four different topics that we wanted to talk about, and maybe amend to the original RFC. And this was sort of a grouping of all those four things that I wanted to propose and change and Martin my co author of the RFC and I worked on them and proposed them. Derick Rethans 1:55 What are the four things that your new RFC was proposing? Benjamin Eberlei 1:59 Yes, so the first one was renaming Attribute class. So, the class that is used to mark an attribute from PHP attributes to just attribute. I guess we go into detail in a few seconds but I just list them. The second one is an alternative syntax to group attributes and you're safe a little bit on the characters to type and allowed to group them. And the third was a way to validate which declarations, an attribute is allowed to be set on, and the force was a way to configure if an attribute is allowed to be declared once or multiple times on one declaration. Derick Rethans 2:45 Okay, so let's start with the first one which is renaming the class to Attribute. Benjamin Eberlei 2:51 Yeah, so in the initial RFC, there was already a lot of discussion about how should this attribute class be caught. Around that time that PhpToken RFC was also accepted, and so I sort of chose this out of a compromise to use PhpAttribute, because it is guaranteed to be a unique name that nobody would ever have used before. There's also, there was also a lot of talk about putting an RFC, to vote, about namespacing in PHP, so namespacing internal classes and everything. So I wanted to keep this open at the at the time and not make it a contentious decision. After the Attributes RFC was accepted, then namespace policy RFC, I think it was called something like that, was rejected, so it was clear that the core contributors didn't want a PHP namespace and internal classes to be namespaced, which means that the global namespace is the PHP namespace. And then there was an immediate discussion if we should rename at PhpAttribute to Attribute, because the prefix actually doesn't make any sense to have there. So the question was, should we introduce this BC break potentially, because it's much more likely that somewhere out there has a class Attribute in the global namespace. And I think the discussion, also one, one person mentioned that they have it in their open source project. Suppose sort of the the yeah should we rename it and introduce this potential BC break to, to users that they can't use the class Attribute and the global namespace anymore. Derick Rethans 4:25 So that bit passed? Benjamin Eberlei 4:26 That bit passed with a large margin so everybody agreed that we should rename it to Attribute. I guess consistent with the decision that the PHP namespace is the global namespace. It's sort of documented in a way. Everybody knows that we have the namespace feature for over 10 years now in PHP or oma, yeah exactly 10 years I guess. So by now, userland code is mostly namespaced I guess, and we can be a bit more aggressive about claiming symbols in the global namespace. Derick Rethans 4:54 Second one is grouping, or group statements in attributes, what's that? Benjamin Eberlei 4:59 The original syntax for the RFC, for attributes uses ... the ... we had this before. Remember? I can't spell, I don't know the HTML opening and closing signs. Derick Rethans 5:15 The lesser than and greater than signs. Benjamin Eberlei 5:17 Two lesser than signs and then two greater than signs, for the opening and closing of attributes. And this is quite verbose. So if you have multiple attributes on one declaration, it could be nice to allow to use the opening and closing brackets only once, and then have multiple attributes declared; so that was about the grouping. There was a sentence in there that should there be an RFC that sort of changes the syntax and that would become obsolete. It was also the most contentious vote of all the four because it almost did not pass but it closely passed. Derick Rethans 5:56 32-14 Yeah, yeah. So the group statements also made it in. You can now separate the arguments by comma. The third one is validate attribute target declarations. Benjamin Eberlei 6:07 That one makes a lot of sense to have from the beginning. What is does is, whenever you create a new attribute, you can configure that this attribute can only be used for example on a class declaration, or only on a method and function declaration, only on a property declaration. And so there are different targets, what we call them, where an attribute can be put on. This is something that will be required from the beginning. So, if you start using attributes, they will only work on certain declarations. Let's say we are configuring routes. So, the mapping of URL to controllers using attributes in a controller can only ever be a function, or a method. So it makes sense to require that the route attribute is only allowed on the function and the method. This should be a good improvement. Another example would be if you use attributes for ORM. So database configuration, then you would declare properties of classes to be columns in a database table, but it would never makes sense to declare the column attribute on a method, or on a class, or something like this. So it would be nice if the validation fails, or the usage of the attribute fails on these other declarations. Derick Rethans 7:25 When is this target checked? Benjamin Eberlei 7:27 The target checks are only done, I started referring to this as deferred validation, so that the validation is deferred to the last possible point in the usage of attributes. Which is, you call the method newInstance(), so give me an instance of this attribute on the ReflectionAttribute class. This has been a point of discussion because it's quite late, it will not fail at compile time, for example, even though it potentially could. The idea to do this at this late point is: we cannot always guarantee that an attribute is actually available when the code is compiled. For example if you use attributes of PHP extensions, the extension might be disabled. And also, you might have different attributes of different libraries on the same declaration. If we would validate them early it could potentially lead to problems. Well, sort of one usage of one attribute of one library breaks others. We decided to make this validation as late as possible from the language perspective. I already see that potentially static analysis tools like Psalm, PHP Stan and IDEs will probably put it in your face very early that you're using the attribute on the wrong declaration. And I guess I don't know static analysis tools in PHP have gotten extremely good and more and more people are starting to use them. And I really like the sort of approach that the language at some point can't be too strict. And then the static analysis tools, essentially, introduce an optional build step that people can decide to use where the validation is happening earlier. Derick Rethans 9:06 Where do you define what the targets for an attribute are? Benjamin Eberlei 9:10 This was also a lot of discussion. We picked the most simple approach; the Attribute class gets one new argument: flags, and it is a bit mask, and by default, an attribute is allowed to be declared on all declarations; classes, methods, properties, and so on. You can restrict the flags, the bitmask, to only those targets that you want to allow. So you would, let's say you have the route attribute we talked about before, you specify this as an attribute by putting an attribute at the class declaration. And then you pass it the additional flags and say only allowed using the bitmask for function method. I think it's just one constant, you use a constant to declare it's only allowed on a method or a function declaration. Derick Rethans 9:59 Can you for example set it a target is both valid for a method and a property? Benjamin Eberlei 10:02 You can, because it's a bit mask you can just use the OR operator to combine them, and allow them to be declared on both. Derick Rethans 10:10 It's also passed, so this is also part of PHP eight. And then the last one is the validate attribute repeatability Benjamin Eberlei 10:20 Repeatability essentially means you're allowed to use an attribute once, or multiple times on the same declaration. Coming back to the routing example, if you're having route attribute, then you could say this is allowed multiple times on the same function, because maybe different URLs lead to the same controller. But if you have a column property for example, you could argue, maybe it doesn't make sense that you define a column twice on the same property so it's mapped to two columns or something. So you could restrict that it's only allowed to be used once. This is also validated again deferred, so only when newInstance() called, it would throw an exception if it's sort of the second or third usage of an attribute but it's only allowed to be there once. Derick Rethans 11:06 What's the default? Benjamin Eberlei 11:07 The default is that the attributes are not allowed to be repeatable and you would, again using the flag arguments to the attribute class, put the bit mask in there that it's allowed to be repeatable. Derick Rethans 11:21 Is there anything else in that RFC. Benjamin Eberlei 11:23 No. Derick Rethans 11:25 The second one was actually something that came out of the first one that she did. The original RFC already mentioned that she could for example have attributes called deprecated, or JIT, or no JIT. I suppose this RFC fleshes out the deprecated attribute a little bit more? Benjamin Eberlei 11:40 Idea was to introduce an attribute "deprecated", which you can put on different kinds of declarations, which would essentially, replace the usage of trigger_error(), where you would say, e_user_deprecated and then say for example: this method is deprecated use another one instead. Benefit of having an attribute versus using trigger_error() is that static analysis tools have an easier way of finding them. It's both a way to make it more human readable because attributes are declarative, it's easy to see them and spot them. And also machine readable. Both developer and machine could easily see that this method, or this class is deprecated, and stop using it, or using the alternative instead. The way it was done at the moment, or until now, mostly you're using a PHP doc block @deprecated in there. Please understand that. You can also read it as human, of course, the problem is that it has no really no runtime effect. That means during development for example, you couldn't see that you're accidentally using deprecated methods and collect this information, or even on production for example, because it's only in a doc block. And with an attribute, it would be possible to have this information at runtime to collect it, aggregate this information so that you see, it's been deprecated code is being used, and also make it human readable and for the IDEs and everything. Derick Rethans 13:12 When I looked at this RFC, it was under discussion, are you intending to bring this up for a vote, before 8.0 because you don't have a lot of time now? Benjamin Eberlei 13:19 I'm not. The reason is that first, you say, I'm running out of time, and I'm a bit stressed at the moment. Anyways, and even then, there are two points that I wanted to tackle it first. I mentioned that you can use the deprecated attribute on methods and functions which is something people are using now. One thing that I saw would be a huge benefit which is not possible at the moment is to be deprecating the use of classes, vacating the use of properties and constants. This is something you cannot hook into at runtime at the moment. So you cannot really trigger it. Essentially has led to a lot of hacks specifically from the Symfony community because they are very very good about deprecations. So they are, they have a very very thorough deprecation process, and they have come up with a few workarounds to make it possible to trigger this kind of things that would like to make this a much better supported case from the language. The problem there is that it touches the error handling of PHP and the usage of the error handler for deprecation triggers is a contentious problem, because it triggers global error handlers as by this side effects, sometimes effects on the performance because it logs to a file. There was a lot of questions if we can improve this in some way or another, and I haven't found a good way for this yet and I hope to work on this for a month. Derick Rethans 14:47 Maybe 8.1 then. The third RFC that goes into attributes, is the shorter attribute syntax RFC. What's wrong with the original syntax, where you have lesser than, lesser than, attribute greater than, greater than? Benjamin Eberlei 15:03 The name implies, the verbosity is a problem, I would agree. So writing, writing the symbols lesser than or greater than twice, yeah, takes up at least four symbols. There's one problem with shorter attribute syntax would be nice. Problem I guess is that this syntax is sort of a unicorn. We do refer to HHVM as one language or Hack, in that case one language that uses it. Whatever the Hack has essentially no adoption and is not very widespread in usage, and since they have parted ways with PHP. They also have a pass to removing the syntax and they, I think plan to change the syntax to use the @ symbol instead of the lesser and greater. So one problem would be that we were like, language wise, we would be a unicorn by using a syntax that nobody else is using this also I guess a problem. And then there are some, some problems that focusing on future RFCs. Something that I don't see myself really advocating or wanting, is allowing to nest attributes, so one attribute can reference another attribute, so that you have a sort of an object graph of attributes stuck together. This is necessary if you want to configure, if you want to use attributes to use very detailed configuration. Not sure if it makes sense at some point. There's this trade off where you should go to XML, YAML, or JSON configuration instead off attribute based configuration. To confusion with potential future usages of PHP and existing usages, so: generics. PHP would ever get generics, in some way, it would use the lesser and greater than symbols, but only once. I cleared up with Nikita before that there's no conflict between so that that would not be a problem. However, if we had the symbol used, they would be near each other. So attributes would come first and then there would be the function declaration using generics and types. These symbols would be very near each other so it might introduce some confusion when reading the code. Then there's obviously the existing usage of this shift up operators so if you're doing shift operations with bits, then they are using exactly the same symbol, the lesser than, greater than symbol twice, to initiate this or declare this operation. Derick Rethans 16:18 I realized there's a few issues with the pointy pointy attribute pointy pointy, to give it a funnier name. Benjamin Eberlei 17:34 Pointy pointy is good. Derick Rethans 17:41 I don't think I've come up with a name for a specific spaceship that looks like this yet, but there were a few other proposals. The original RFC already had the @:, which was rejected in that RFC. There was another proposal made that uses the @@ syntax to do attributes. It this something used by all the languages. Benjamin Eberlei 18:01 Syntax was the most discussed thing about attributes, so everybody sort of agreed that we need them or they we benefit. Nobody could agree on the syntax. So there were tons of discussion everywhere about how ugly the pointy pointy syntax is, and because we're using the @ symbol and the doc blocks already you by we couldn't use the @ symbol for attributes themselves, so there are lots of discussions running in circles. Just using the @ symbol once it's just not possible because we have the error suppression operator. Then a lot of people always suggest okay let's get rid of that, because it's anyways it's bad practice to use it Derick Rethans 18:38 It's a bad practice but sometimes it's necessary to use it. Benjamin Eberlei 18:41 So there are some APIs in the core that cannot be used without them. For example, unlink, mkdir, fopen. Because of race conditions you have to use the symbol there in many cases. Even if we would deprecate and remove that sort of syntax we would still somehow need it in a way for these functions. So I'm not seeing that we will ever remove them, and even then it will take two cycles of major versions, so it doesn't make sense. That one is out. The pointy syntax was something that Dmitri proposed many years before and people were sort of in favour of it, so I didn't change it for the initial RFC. We looked a lot at different syntaxes but none of them were nice and didn't break BC. And then when the vote started some core contributors proposed that maybe we can do slight BC breaks in the way we have existing symbols and one proposal was to use @@, which means we are using the @ symbol twice. This is actually allowed in PHP at the moment, we consider breaking this not a big problem because you can just use it once and it has the same effect. Problem would only be going through the code and finding all @@ usages which we assumed are zero anyways. Derick Rethans 19:57 Is there any other language that uses @@? Benjamin Eberlei 19:59 A few other languages use just to @, like many other, like many people propose PHP should also do, which I explained I guess is impossible. It's only proposed because it's looking close enough to @, and so it wouldn't be a huge difference and sort of familiar in that way. Derick Rethans 20:18 There was another alternative syntax proposed which is #[ attribute ]. Where does this come from? Benjamin Eberlei 20:25 So the @@ syntax is different to the pointy the syntax that doesn't have a closing symbol, it only has the starting symbols. Nikita and Sara both said that would be fine as a BC break and Sara is the release master for PHP eight, so she has a lot of pull on these kinds of things. Nikita as well. So, they said it's okay to have small BC breaks, we did look at other syntaxes. I saw that, which I liked before already but couldn't use because would be BC break, was the yeah hash, and then square brackets, opening and there's a closing square bracket close. This is used in Rust. It is a small BC break in PHP because the hash is used as a one line comment. It's not used that much any more, by people to use comments because coding styles discourage the use of it. I use it myself sometimes, like, specifically in one time shell scripts and stuff it's nice to use it, to use the hash as a comment. And the change, would there be that if you have a hash, followed by any other symbol than an opening square bracket, it would still be a comment. If the first symbol is square bracket opening, then it would be parsed as an attribute instead. Derick Rethans 21:42 So this is something you say that rust uses? Benjamin Eberlei 21:43 Yes. Derick Rethans 21:44 Because they're pretty much three alternatives now, we have the original pointy pointy one, which I still think is the best name for it, @@ operator, and then the hash square brackets operator. With three alternatives it's difficult to do our normal voting which is, how would you two thirds majority, but with three variants that is a tricky thing. As a second time ever, I think we use STV to pick our preferred candidate. Well this is STV kind of thing. Benjamin Eberlei 22:11 You need to help me with the abbreviation any ways resolving it. Derick Rethans 22:14 Single transferable vote. Benjamin Eberlei 22:16 STV is a process where you can vote on multiple options, and still make sure that the majority wins, or that the most preferred one wins. Ensure that it has a majority across the voters. The way it works is that everybody puts up that their preferences. There are many different options, in our case three, everybody puts their preference, I want this one first, this one second, is one third. And then the votes are made in a way where we look at the primary votes, who gave whom the primary vote. And then the option that has the least votes gets discarded. All those people that pick the least one, they have a second preference, and we look at the second preference of these voters and transfer, sort of change, the votes, their originally, but discarded option to the options that are still available. Now, somebody has the majority, they win if they don't, we discard another option and it goes on and on. With just three options, it's a transfer of a vote would essentially only happen once, because once one is discarded, one of the two other ones, not must have because it can be a tie, but probably has a majority, yeah. Derick Rethans 23:34 In this case, when we're looking at votes , when were counted them, it actually was obvious that no transferring of votes was actually necessary because the @@ won outright, and had quorum. In the end it up ended up being a pointless exercise, but it's a good way of picking among three different options. Which one won? Benjamin Eberlei 23:53 The @@ syntax won over the Rust Rusty attributes, and the pointy, pointy pointy attributes. One was clearly chosen as a winner, I think, but 54%, 56% in the first vote already. However, one thing that came up in the sort of aftermath of the discussion is that the grammar of this new syntax is actually not completely fine parse any language like PHP or any other programming languages to have defined the grammar and then the grammars inputs to a parser generator, as required some hacks to get around the possibility of using namespaces relative name step basis afterwards. This is something where Nikita satisfaction not allowed. In the way PHP builds its grammar, without any further changes @@ is actually going to be rejected as a syntax. However, Nikita independently worked on sort of change in the tokensets of PHP, that would provide a workaround, or not a workaround. It's actually a fix for the problem. If this new way of declaring tokens for namespaces would be used in PHP eight, then it's also possible to use the @@ syntax for attributes. If we don't change it, then the @@ syntax is actually not going to make it. Derick Rethans 25:18 In my own personal opinion, I think, @@ is a terrible outcome of voters is going to be so does that mean I should vote against Nikita's namespace names as token RFC or not? I mean it's a bit unfair. Benjamin Eberlei 25:30 I will vote for it. The premise of Nikita's RFC, and he worked on it before the @@ problem became apparent, so he did not only work on it to fix this problem. The problem he's trying to fix is that parts of namespace could use potentially keywords that we introduce as keywords in the future. An example is the word enum, and people are talking about adding enums to PHP for years. He had also one use case where one of his own PHP libraries broke by the introduction of the FN keyword for PHP 7.4, the short closure syntax. Essentially, it would help if some part of a namespace would contain a word that becomes a keyword in the future, that it wouldn't break the complete namespace. Because at the moment, the namespace. In this case is burned. You can't even use it anywhere in the namespace. The key word, which I guess it's a problem. But this reason I am actually for this proposal that Nikita has, even though I agree with you. I was actually a proponent of the Rusty attribute syntax, so I would have preferred to have that very much myself. Derick Rethans 26:40 I hope to talk to Nikita about what this namespace token thing is exactly about in a bit more detail in a future episode. Feature freeze is next week, August 4th. Are you excited about what PHP eight is going to be all about? Benjamin Eberlei 26:54 It's been a lot of last minute, things that have been added that to look really, really great. I can't remember PHP seven any more that closely, but I remember that it was the case with PHP seven as well. So anonymous classes was added quite late. Essentially PHP seven initially was just about the performance and then there was a lot of additional nice stuff added, very late, and made it a from a future perspective, very nice release, and it seems, it could be the same for PHP eight. Match syntax, attributes, then potentially the named parameters, which at the time of our speaking is still an open vote but looks very very promising. Derick Rethans 27:36 And then of course we have union types as well, and potentially benefits of the JIT right? Benjamin Eberlei 27:40 Union types this already accepted for so long I forgot about it. Derick Rethans 27:45 Alpha versions of PHP eight zero are already out, so if you want to play with these features you can already, and please do. And if you find bugs, don't assume it's you doing something wrong, instead file a bug report at https://bugs.php.net. Thank you, Benjamin, for talking to me about more attributes, this morning. Benjamin Eberlei 28:03 Thank you very much for having me. Derick Rethans 28:06 Thanks for listening to this instalment of PHP internals news, the weekly podcast dedicated to demystifying the development of the PHP language. I maintain a Patreon account for supporters of this podcast, as well as the Xdebug debugging tool. You can sign up for Patreon at https://drck.me/patreon. If you have comments or suggestions, feel free to email them to derick@phpinternals.news. Thank you for listening, and I'll see you next week. Show Notes RFC: Attribute Amendments RFC: Deprecated attribute RFC: Shorter Attribute Syntax RFC: Treat namespaced names as single token Psalm PHPStan Credits Music: Chipper Doodle v2 — Kevin MacLeod (incompetech.com) — Creative Commons: By Attribution 3.0

PHP Internals News: Episode 52: Floats and Locales London, UK Thursday, May 7th 2020, 09:15 BST In this episode of "PHP Internals News" I talk with George Banyard (Website, Twitter, GitHub, GitLab) about an RFC that he has proposed together with Máté Kocsis (Twitter, GitHub, LinkedIn) to make PHP's float to string logic no longer use locales. The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode's MP3 file, and it's available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news Transcript Derick Rethans 0:16 Hi, I'm Derick. And this is PHP internals news, a weekly podcast dedicated to demystifying the development of the PHP language. This is Episode 52. Today I'm talking with George Banyard about an RFC that he's made together with Mate Kocsis. This RFC is titled locale independent floats to string. Hello, George, would you please introduce yourself? George Banyard 0:39 Hello, I'm George Peter Banyard. I'm a student at Imperial College and I work on PHP in my free time. Derick Rethans 0:47 All right, so we're talking about local independent floats. What is the problem here? George Banyard 0:52 Currently when you do a float to string conversion, so all casting or displaying a float, the conversion will depend on like the current local. So instead of always using like the decimal dot separator. For example, if you have like a German or the French locale enabled, it will use like a comma to separate like the decimals. Derick Rethans 1:14 Okay, I can understand that that could be a bit confusing. What are these locales exactly? George Banyard 1:20 So locales, which are more or less C locales, which PHP exposes to user land is a way how to change a bunch of rules on how string and like stuff gets displayed on the C level. One of the issues with it is that like it's global. For example, if you use like a thread safe API, if you use the thread safe PHP version, then set_locale() is not thread safe, so we'll just like impact other threads where you're using it. Derick Rethans 1:50 So a locale is a set of rules to format specific things with floating point numbers being one of them in which situations does the locale influence the display a floating point numbers in every situation in PHP or only in some? George Banyard 2:06 Yes, it only impacts like certain aspects, which is quite surprising. So a string cast will affect it the strval() function, vardump(), and debug_zval_dump() will all affect the decimal locator and also printf() with the percentage lowercase F, but that's expected because it's locale aware compared to the capital F modifier. Derick Rethans 2:32 But it doesn't, for example, have the same problem in the serialised function or say var_export(). George Banyard 2:37 Yeah, and json_encode() also doesn't do that. PDO has special code which handles also this so that like all the PDO drivers get like a constant treat like float string, because that could like impact on the databases. Derick Rethans 2:53 How is it a problem that with some locales enabled and then uses a comma instead of the decimal point. How can this cause bugs and PHP applications? George Banyard 3:02 One trivial example is if you do, you take a float, you convert it, you cast it to string, and then you cast it back to float. If you're on a locale, which is the dot decimal separator, you will get back the original float. However, if you have like locale which com... which changes the decimal separator, like the German one, you'll get a string; you'll get like three dash, three comma 14, and then when you convert it back to float, you will only get three because PHP doesn't recognise the comma as a decimal separator in its string to float conversion and so it will loses the decimal information. Derick Rethans 3:39 That doesn't seem particularly very useful as a feature. So my question here is we talked about floating point numbers and, and I think floating point numbers have other issues as well. Not sure whether we want to go into the details of how floating point numbers and computers work, but we can if you want to. George Banyard 3:56 The easy way to explain floating points is to use like exponential notation, or to use the scientific exponential notation, which most people will know from engineering or physics, where you usually have like, one significant like the number, like a comma, a couple of numbers, and then you have like an exponent which raises it to usually, so to your power 10 to the something, which then gives you an order of magnitude. Floating points, basically that but in base two. Derick Rethans 4:26 Positions have magnitudes attached to them. They're all powers of two. George Banyard 4:30 Yeah. Derick Rethans 4:31 And of course, when we use numbers an decimal, like pi being a bad example. George Banyard 4:36 Once said. Derick Rethans 4:37 I was going to say if you divide 10 by three, you get 3.33333 that never ends, right. And I reckon if you have a specific number in decimal like three point 14, then you can't necessarily always exactly represent it in binary. George Banyard 4:55 Yeah, one common example would say it's like one 10th which has like a perfect representation in decimal. But like in binary is a never ending repeating sequence. When you try to like display naught point one, like how it's saved in floating point, it's really weird and everything to get like these rounding errors which can propagate. Derick Rethans 5:15 And hence you often hear people recommend to never use float for things like monetary values, but then as you said that you sentence that right? George Banyard 5:23 Yeah, put everything in integers and work with integers and just like format it afterwards. Derick Rethans 5:29 So let's get back to what you and Mate are actually suggesting to change. What are the changes that you want to make through this RFC? George Banyard 5:36 The change's more or less to always make the conversion from float to string the same, so locale independent, so it always uses the dot decimal separator, with the exception of printf() was like the F modifier, because that one is, as previously said, locale aware, and it's explicitly said so. Derick Rethans 5:56 Doesn't printf also have other floating related format specifiers? I believe there's an E and a G as well. And uppercase F. What is the difference between these? George Banyard 6:06 Lowercase F is just floating point printing with locale awareness. Capital F is the same as lowercase, but it's not locale aware. So it always uses the dot decimal separator. Lowercase E is, what I've learned recently also locale aware, and uses the exponential notation, like with a lowercase e. Uppercase E is the same as lowercase E, but instead of having a small like a lowercase e in the printing format, it's a uppercase E, and lowercase G has some complicated rules onto when it decides which format to choose between lowercase F and lowercase E, depending on like how big like the number of significant digits are after the comma, or like the dot. And uppercase G is the same but using uppercase F and uppercase E instead of lowercase E and lowercase F. Derick Rethans 6:58 And all of them can be locale dependent then except for uppercase F. George Banyard 7:02 Yeah. Derick Rethans 7:02 Do you think this is going to impact people's applications, if you change the default of normal casts to be locale independent? George Banyard 7:10 I would have expected it to not be that significant. And only that would affect displaying floating point. So if you're like in Germany, instead of like seeing a comma, you would now see a dot, which can be annoying, but I wouldn't imagine is the most, the biggest problem for you like end users. But apparently, people made tooling to work around the locale awareness of it. And so they could maybe break with passing stuff, which I suppose that happens because it's been, PHP's 25 years old. And that behaviour has been there for like ever. So people worked around it or work with it. Derick Rethans 7:49 Is this going to be purely a displaying change or something else as well? George Banyard 7:54 For example, if you would send like a float to like an API via HTTP, you would usually already need to have like code around to like work around like the locale awareness, or like all by resetting set locale or by using number_format or like sprintf or something like that. Because most other APIs or like you would like contact would expect like the float to use like a decimal point. PHP. If you do the string to float conversion again, which was not a point, then you get only an integer basically. Derick Rethans 8:27 Because PHP's parser, strips it out once it stops recognising digits, which is in this case, the comma. George Banyard 8:33 Yeah, that would make the code nicer. The main reason why me and Mate like decided to propose this RFC is because like most APIs, and also databases and everything, expect strings to be formatted in like a standard way. Currently, like if you for whatever reason, use a locale, then it's not, but yeah, like apparently people worked around that when they were maybe stripping stuff from like HTML whatever displayed and try to work around it because that got raised in the list quite recently. Derick Rethans 9:06 This change does not necessarily remove the ability of using locales for formatting numbers, because PHP still has the lowercase F as format specifier for printf. And sprintf and friends. Does PHP have other ways of rendering numbers according to locales? George Banyard 9:24 According to locales? I don't think so. You can format it something like manually, or the number format a class from the Intl extension. Derick Rethans 9:35 Yeah, from what I understand, number_format, you have to do it all by yourself. And the intl extension doesn't support the posix or C locales from the operating system, right. It uses its own locale rule set from the Unicode project. The RFC lists some alternative approaches. Would you mind touching a little bit on these as well? George Banyard 9:58 One of the alternatives approaches is to deprecate setlocale altogether. Because as a byproduct, this just fixes the issue because you can't define any locale anymore. So, there will always be locale independent. This has been discussed like in back in 2016, mostly because of the non thread safe behaviour. Because it affects global states and everything. But at the time, the conclusion was, because HHVM, like did a patch, making a thread safe, setlocale function was to mimic this patch and like implement it into PHP, which hasn't been done yet. Another one that we thought about was to deprecate kind of the behaviour and like raise a notice, like a deprecation notice, because that would happen like basically on every float to string conversion. The penalty, like the performance penalty, seemed pretty like strong. One other thing we considered was with Mate was to deprecate the current behaviour in some way. However, emitting a deprecation notice on basically every float to string conversion seemed not to be ideal. And just like flood, the log, the log output, and like also bring like a performance penalty because like outputting warnings isn't like most friendly thing to do performance wise. Derick Rethans 11:21 What has the feedback been so far? George Banyard 11:24 Feedback currently has been that like most people, well, one person because there hasn't been that much feedback. Derick Rethans 11:30 There hasn't been that much feedback because you've only just proposed? George Banyard 11:33 some of the feedback we got officiates the change However, they have concerns about like the modification of like, in every case for locales without having any upgrade paths. In some sense. It's just, oh, you have the change, and then you need to execute it and see what breaks. We may be currently considering like ways to figure that out, maybe by adding a temporary ini setting which would kind of be like a debug mode, where when you use that it would like emit notices when like this conversion would happen before and they would notice: Oh, this is not happening anymore. You need to like be aware of this change in behaviour Derick Rethans 12:17 Did we not used to have E_STRICT for this at some point or E_DEPRECATED? George Banyard 12:24 E_DEPRECATED is still a thing. E_STRICT got mostly removed with PHP seven. There've been like a couple of remaining notices which I got rid off or put back to normal E_WARNINGS or E_NOTICES in PHP seven point four. There were like two or three remaining. But yeah, like so that's one way to maybe approach it of like implementing a debug ini setting which would only be used for like dev because then where if you get like warnings and everything, you don't really care about the performance impact. And then in production, you would like disable that and the warnings wouldn't pop up. Derick Rethans 12:56 How would that setting be any different from just putting it behind an E_DEPRECATED warning? George Banyard 13:00 So with an E_DEPRECATED warning, we would need to show this behaviour, and we would need, and we could only change the behaviour in like PHP nine. Currently if we do that with like debug setting, we could change it with PHP 8. Derick Rethans 13:13 That's a bit cheating isn't that? George Banyard 13:15 Could say so. Derick Rethans 13:16 I'm interested to see how this ends up going. Do you have any timeframe of when you want to put it for a vote? George Banyard 13:23 Currently, we've only started this discussion. And I think until we figure it out, if we get like an upgrade pass, or multiple upgrade passes that we could then put into a secondary vote. I wouldn't expect it to go to voting that soon. Maybe end of April would be nice. Derick Rethans 13:41 So around the time when this podcast comes out? George Banyard 13:44 Ah! For once! Derick Rethans 13:46 For once I got my timing right. George Banyard 13:49 Yes. Don't you have like the string contain one which just got out. Derick Rethans 13:53 Yes. George Banyard 13:54 Then that vote close like last week. Derick Rethans 13:57 Yeah, it's really tricky because there's so many, so many small now that I can't keep up. George Banyard 14:02 Yeah, Mark also did like his debug. Derick Rethans 14:04 Yeah. And there's like two or three tiny ones more that I would quite like to talk about. But by the time there's an opening in the schedule, it's pretty much irrelevant. So I'm trying to see whether I can wrap a few of the smaller ones just in one episode because there's the throw expression, the is literal check, and typecasting in array destructuring expressions, and all showed up in the last three days. George Banyard 14:26 I suppose people have like, lots of time now. Now, it's a taint checker, basically, like I know, there's been like this paper by Facebook like six or eight years ago, which talks about how they kind of tried to implement in their static analyzer, but like, a static analyzer doesn't need to be something in the engine. That's what I don't really get. Derick Rethans 14:45 Thank you, George, for taking the time this afternoon to talk to me about a locale independent float to string RFC. George Banyard 14:53 Thanks for having me on the podcast again. Derick. Derick Rethans 14:55 You're most welcome. Thanks for listening to this installment of PHP internals news, the weekly podcast dedicated to demystifying the development of the PHP language. I maintain a Patreon account for supporters of this podcast, as well as the Xdebug debugging tool. You can sign up for Patreon at https://drck.me/patreon. If you have comments or suggestions, feel free to email them to derick@phpinternals.news. Thank you for listening, and I'll see you next week. Show Notes RFC: Locale-independent float to string cast Floating Point Numbers Credits Music: Chipper Doodle v2 — Kevin MacLeod (incompetech.com) — Creative Commons: By Attribution 3.0

PHP Internals News: Episode 48: PHP 8, JIT, and complexity London, UK Thursday, April 9th 2020, 09:11 BST In this episode of "PHP Internals News" I discuss PHP 8's JIT engine with Sara Golemon (GitHub). The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode's MP3 file, and it's available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news Transcript Derick Rethans 0:16 Hi, I'm Derick. And this is PHP internals news, a weekly podcast dedicated to demystifying the development of the PHP language. This is Episode 48. Today I'm talking with Sara Golemon about PHP 8 and JIT. Sara, would you please introduce yourself? Sara Golemon 0:33 Hi there. Hi there, everybody listening to PHP internals podcast. I'm Sara. I've been on this podcast before. But in case you're just getting here to for the first time, welcome to the podcast. You have a nice backlog to go through. I am a lapsed web developer, come database security engineer by day, and an opinionated open source dev slash PHP 7.2 release manager by night and also day. I've been involved with the project for about 20 years now off and on. Somehow I just keep coming back for more punishment. Derick Rethans 1:03 We're leading up to PHP 8, with lots of new features being added. But one of the biggest thing in PHP 8 that I've spoken about on the podcast on before all the way back last year in Episode 7, is that PHP eight is going to get a JIT engine. Would you care to explain what a JIT engine does again? Sara Golemon 1:20 Well, I'm going to give you the short, you can look this up on Wikipedia in two seconds definition of JIT, means just in time compilation. That doesn't really tell you much, unless you listen to it on the sort of other half of that of AOT, or ahead of time compilation. AOT is what you expect from applications like GCC, you know, you just make an application that you've got C or C++ kind of source code to that's ahead of time. JIT is saying, well, let's take the source for application. And let's just run with it. Let's just start executing it as fast as I can. And eventually we're going to get down to some compiled code. That's going to run a little bit quicker than the initial stuff did. PHP already has this nice little virtual machine built into it. We call it the Zend engine. That takes your script and immediately just says: All right, well, what does this say in computer terms? Well, a computer readable term is a series of these op codes, they're also called byte codes in other languages that give you instructions for: run this type of instruction at this time and get something done. The PHP runtime interpreter interprets that one instruction at a time basically pretending to be a CPU. This works quite well, it runs quite efficiently. But there's still this sort of bottleneck in the middle there of a program pretending to be a CPU running on top of a CPU in order to run other code. The idea of JIT is that this thing sitting in the middle is going to gradually figure out what your program really is trying to do and how it's intended to run, and It's going to take those PHP instructions and it's going to turn them all the way down into CPU instructions, so that it can get out of the way and let the CPU run your code natively as if it had been written in a compiled AOT kind of language. What that actually means for execution of PHP code in PHP 8 is still sort of a, you know, a question that's, that's left to be answered here. I listened to your interview with Zeev. Episode 7, is a good episode of getting some good information on that. We do definitely agree on what the status of the JIT within PHP is, right now we can. It's subjective facts like this is how much work has been done largely by Dmitri, where we can kind of expect to see the best gains come from. I personally think I might be a little bit more pessimistic than him in terms of the actual performance impact we get out of it. I think we both recognise we're not going to see the two to one kind of improvements we saw from five to seven. Nobody's realistically expecting that, but if you look at the demo that Zeev ran a few months ago, where he shows the Mandelbrot set being generated in two different PHP requests, and then WebSocket out to a nice pretty display, it's a very visceral reaction because you can see one Mandelbrot set being calculated much, much faster than the other. And he acknowledges though this is not realistic PHP code, nobody's writing the Mandelbrot calculation in PHP. We can see that under certain workloads, it's definitely getting faster. But for PHP core mission, which is web serving, I mean, we both know that it's not going to be massively fast. I think it's going to be almost imperceptibly fast. Derick Rethans 4:41 One question for my site, the Mandelbrot set, the implementation of that is all in a specific function, right? And it's all CPU heavy code, not IO. Sara Golemon 4:51 Yes. Derick Rethans 4:52 And it's all that in the same function. Sara Golemon 4:54 Yes. Derick Rethans 4:55 Now, what I was thinking of the other day is that how does this interact with calling standard library functions, because the JIT engine is going to have to go out of basically running things on the CPU and calling things that are then implemented in C to begin with. Sara Golemon 5:10 So you're asking that question, because you already know some of the pitfalls of JIT, and you're leading me into it. And that's fine. When a JIT emitter is taking the language that it's emitting, so PHP. As long as it remains within the scope of PHP, it can sort of keep track of where it's at. It's like, Okay, I know this variable's init, your because I saw it get set. I know that this is going on here. I know that's going on there. And it can carry those assumptions around as it's admitting code. And emit very efficient code that doesn't need a whole bunch of double check guards of like: Wait, is this still an integer? Wait, is that still a string? All of these sort of like escape hatches for when things go wrong. Anytime you cross over into, I will say C-land, or internals land, or ahead of time compiled land. It's basically calling into what it sees as a black box. And it just says: Okay, here's some data, I know the types going in, have fun with it. And something air quotes happening in the air happens with that code and the black box spits out an answer. Well, by the time the black box has spit out the answer, the JIT that has taken that PHP code, no longer knows if any of its assumptions are true or not. It just has to say: Well, time to start from scratch, time to keep track of where we are from here, build up a new set of assumptions. So we get this speed bump in the road of executing code. And it turns out most PHP applications are using a whole lot of those internal API's because they're quite useful. There is a kitchen sink in PHP, and it does stuff. So you have these repeated hits of this road bump happening, and that's not great. If we want to compare this to other JIT languages that are out there. I might suggest we compare this to HHVM because of course, HHVM, at least in the beginning implemented a fairly close kin cousin to the dialect of PHP. It has since diverge much more and become hacklang. But it was doing the same thing, taking PHP code, running it native on the CPU and occasionally having to make that cross to this its own version of internals, or it was running C++ code. One of the ways to reduce those numbers of jumps is that they took a lot of those internal functions, the ones that actually didn't need to do anything, particularly internals ish, and just rewrote them in PHP code. And if you look at the HHVM source code right now, there is a big directory called systemlib and that's a whole bunch of hacklang code, read it as PHP code, that is implementing a lot of these very common quote unquote internal functions. We just had an RFC for function called str_contains(), that is a function that could have been hundred percent been written just as PHP code. Something could have thrown that into packagist. For the record, I voted against it because of exactly that. I think you should write that in packagist and just put it in your composer.json is okay. It's gonna pass anyway, it got a lot of votes. That aside over, that is a sort of function that if we were putting it into sort of an 8.X version of PHP, where we did have our own type of systemlib, we would have probably just said, let's write that as PHP code. So that the JIT, when it enters that function, can keep all those assumptions intact, and potentially even inline some of those instructions and avoid the function call entirely. That's basically taking all of the instructions that are part of the in this case, str_contains() function, and implementing them within the scope of the function that was calling it. So you skip that entire function call overhead, which a lot of people know is still one of PHPs sort of weaker points in terms of where that fat to trim is, as Zeev said in Episode Seven, we still have some parts of PHP that are a bit slow, irrespective of a JIT. Derick Rethans 8:50 There are actually a few functions that have been inlined now into op codes. strlen() is an example of this where instead of it now being a function call, it's actually directly an opcode. Because it is a function that is used so much and actually gain a bit of performances there. Sara Golemon 9:05 Yeah, I think all of these functions as well are just a single opcode for type check. Yeah. Derick Rethans 9:10 There's a whole bunch of them for sure. I saw that earlier this morning, Dmitri produced, or proposed another branch in which he implemented tracing JITs, instead of the JIT that we already have, and I have no idea what the difference is between a normal JIT engine and the tracing JIT engine, Sara Golemon 9:25 Ultimately, the distinction is not that important to end users, it's going to function the same, but it is a sort of an internal implementation detail. HVVM's by the way, is a tracing JIT. It basically looks at any given unit of work that it needs to translate, let's say a function, and it says, what are the pieces that have these sort of non branching parts attached to them? Let me look at each of the non branching pieces. And let me create a version of that translation based on the types that I expect to be going in there. If the types fail, I'm gonna have to create a new version of that piece. But then that piece can plug into this sort of chain of tracelets to create a full function. Most of the time, especially if you've written code that is well type hinted, you've got, you know, strict types turned on, you've got all of your types on the on the function parameters set. And it's very easy for the JIT to infer the types out of what you've put into your function. You're only ever going to need to create a single tracelet of any given section, and your full trace is going to be a single, unbroken chain of: do this, do this, maybe do a jump to another spot, just keep doing this, doing this, doing this. If you have, let's say, slightly messier code, maybe you're not using any kind of type hinting it becomes very difficult to infer any of the types, because there's lots of different call sites, that are doing lots of different things. We may end up having some functions that have multiple tracelets per body section that get built into the giant bush of interconnected edges, that's less ideal in terms of maximising performance, but it still at least functions. Derick Rethans 11:06 We have spoken a little bit about what a JIT engine is and sort of how it works. It sounds quite complex and complicated. Sara Golemon 11:14 It is definitely complicated. And I'm feeling like that's another lead. And so I'll just run with it. Derick Rethans 11:19 I've also got to say my next leading question... Maybe I should actually ask the question? Sara Golemon 11:24 Well, let's actually take a step back from the JIT for a second. And let's look at where the engine is right now. So the engine is basically two very large pieces. That's the sort of the extension library of all of the runtime functions. Everything you see exposed in user space, and the actual scripting engine. There are some other smaller pieces, but those are two, the two really big pieces. There are a whole lot of people pay a whole lot of attention to the extension piece, because that's the flashy bit. That's the part that gives you some bit of binding that you didn't have before, or some bit of functionality that can be delivered out of the box as part of that kitchen sink. And that definitely needs attention. I'm glad that that continues to evolve. But the scripting engine is that piece that defines syntax and how code is actually going to run. Derick Rethans 12:09 Reading extension's code as a whole lot easier than reading the engine code. Sara Golemon 12:13 And that's where I was going to go with that, yes, if you look at the code that's under ext, you can even come into that code without knowing any C at all. And you can actually make pretty good sense of a lot of it because a) PHP uses a whole lot of macros. So every function is literally defined with a macro that says: PHP_FUNCTION, like right here, PHP function, every class method, PHP_METHOD, here's the class name. Here's the method name. And what these things do are pretty clear sort of API's. They're very small bite sized pieces for the most part. The bits that involves sort of defining a class and how it does its memory management, those get a little bit more complicated, but I think on the whole extension code is far more accessible. If you go and look at the engine, particularly the runtime pieces of the engine, although the compiler is complex as well. You have to do a lot of digging before you even get to a point that you can see how the pieces maybe start to fit together. You and I have spent enough time in the engine code that we know where to look for a particular thing. Like let's say that opcode, you mentioned that implements strlen(). We know that, oh, zend_vm_def.h has got the definition for that. We also know that that file is not real code. It's a pre processed version of code that gets built later on. Somebody coming to that blind is not going to see a lot of those pieces. So there's already this big ramp up just to get into these engine as it exists now in 7.4. Let's add JIT on top of that. You've got code that is doing call forward graphs, and single static analysis, and finding these tracelets, and making sense of the code at a higher level than a single instruction at a time, and then distilling that down into instructions that the CPU is going to recognise. And CPU Instructions are these packed complex things that deal with immediates, and indirects, and indirects of indirects, and registers. And the x86 call ABI is ridiculous thing that nobody should ever have to look at. So you add all this complexity to it, that by the way, sits in ext/opcache. It's all isolated to this one extension that reaches into the engine, and fiddles around with things to make all this JIT magic happen. You're going to take your reduced set of developers who know how to work on Zend engine, and you're going to reduce that further. I think at the moment, it's still only about three or four people who actually understand how PHP's JIT is put together enough that they can do any effective work on it. That worries me for sure. I don't think that's an insurmountable hill to climb, especially if we can start getting some documentation written about it, at least from a high level point of view. Hey, you know, look over here to find this stuff. Look over here to find that stuff. Something to get started. So the people who have at least that basic understanding of how the VM part of the Zend engine works can sort of upgrade their knowledge to get into to the JIT. I only think that's worth it. If we actually get real performance boost out of JIT. If we actually turn the JIT on, and we see that for PHP's core workload, which is web serving, we're only seeing a one to 2% gain. For me, that's not enough. It may be enough for others. But for me, I would call that experiment, not a failure, but a non success at that point. Certainly there are people out there who are still going to want to use it, because they are you doing command line applications, and they're doing complex math. And I'm not saying we can't have it. I'm just saying it takes less than a forward stage that point. Derick Rethans 15:43 Somebody mentioned earlier in the chat room. It's also another set of potential bugs, right? Sara Golemon 15:48 It is definitely another potential bugs. Derick Rethans 15:51 It's pretty much another implementation of the PHP syntax bits of PHP. Sara Golemon 15:57 So if you run an application and you get behaviour you don't expect, where is that behaviour actually coming from? You can spend a lot of time looking in Zend engine because you're thinking like: Oh, well, this is the thing that executes opcodes. And when I run it in a single command line, it's definitely going through this bit of code, but it works on a single command line run. But at the twentiest request on my web server, it's not working. Why is that happening? Well, it turns out, it's happening, because that's when the JIT has finally kicked in, because it has enough information. And it's running through this tracelet that was just a little bit wrong. And well, crap. You mentioned I think, at one point, when we were talking in Miami just a couple months ago, that you're just gonna have to turn the JIT off entirely when Xdebug is running, Derick Rethans 16:41 Just like I'll already turn OPCache optimizations off, because there's just too confusing for people. Sara Golemon 16:46 It's confusing and complex, but it's also it may not even be 100% possible because we are right there down at the bare metal of running CPU instructions. There's not a lot of opportunity to just say like, Oh, hold on Mr. CPU, let me just take a look at your registers right now. Okay, this is okay, let's go ahead and keep going now. The VM that we have now in in Zend lends itself 100% to those kinds of activities, CPU does not. What that means is that what we experience in the development mode with Xdebug running is not going to be the exactly the same thing that we experience in real runtime code. And I don't know if we have a solution for that. Derick Rethans 17:23 As far as I know, there's no solution for it at all. Sara Golemon 17:26 I was trying to cage it in the hope that maybe we could someday have solution for it. Derick Rethans 17:30 It'd be lovely, but I can't see that happening to be honest. I think it's going to be important to find out how much this actually benefits, real live code. How does it benefit your Laravel project or your Symfony project or anything like that? I think it's going to be hard to now make a case for not shipping PHP 8 with a JIT. I think that'd be a bit unfair. But on the other side, if it's, as you say, only really gives you one or 2%, whether this is worth have the additional complexity. The additional maintenance burden as well as another opportunity for having bugs that are a lot harder to reproduce, but it's actually worth having it at all? Sara Golemon 18:11 I definitely don't want to poopoo on the JIT effort. Derick Rethans 18:14 Oh, no, absolutely not. Sara Golemon 18:15 I think this is an important experiment to run. And I think if 8.0 as a whole winds up being a sort of public beta experiment of it, that will definitely give us a lot of good information. And I am super hopeful that we see better percentages, that we see 5-10 maybe even 15% Derick Rethans 18:31 Absolutely. Sara Golemon 18:32 I want to be guarded in what I how I talk about it on a podcast like this because I don't want anybody say: Oh, 8's gonna be great. Our code is gonna run 10 times as fast as it was running before No, that's not gonna happen two x is not gonna happen. We're talking much lower numbers than that. Be guarded, be hopeful, but 8.0 is going to be, as I said, it's going to be that sort of public beta experiment. Derick Rethans 18:55 I think that's great. I think running this experiment again because ta similar experiment was, of course run during the PHP 5.6 days when PHP 7 came out. Originally with PHP 7, was PHP with a JIT engine. And then Dmitri and others found out that it was so much other things that could be done to make PHP run pretty much twice as fast. Sara Golemon 19:16 Yeah, there was a lot of really low hanging fruit. Derick Rethans 19:19 Yep. And that was great to see. I am apprehensive about people thinking that the JIT engine in PHP eight is going to similar performance boost. Sara Golemon 19:29 We'll see. Nothing to say about it, but then: we'll see. Derick Rethans 19:32 But I would suggest is that if you're interested in seeing what this can do for your projects, you should go try it out. Download PHP's master branch, enable it and see how it goes. Sara Golemon 19:41 And of course, make sure you are running on x86 hardware. I doubt very much that he's bothered to put more than one back end on this. Derick Rethans 19:48 I don't actually know. Sara Golemon 19:49 I haven't looked. He might be using some helper library for it. So it's possible that we're hitting multiple backends. But this is probably going to be an x86 only thing and possibly a Linux thing. I should find out the answer to that question. Derick Rethans 20:00 I should do too. Okay, Sara, thanks for taking the time this morning to have a chat with me about PHP 8' JIT efforts. Sara Golemon 20:08 It's fun as always, I always love to speak with you Derick. You bring a bright Corona of sunlight to my day. Derick Rethans 20:16 Thanks for listening to this instalment of PHP internals news, the weekly podcast dedicated to demystifying the development of the PHP language. I maintain a Patreon account for supporters of this podcast, as well as the Xdebug debugging tool. You can sign up for Patreon at https://drck.me/patreon. If you have comments or suggestions, feel free to email them to derick@phpinternals.news. Thank you for listening, and I'll see you next week. Show Notes Episode 7: PHP and JIT Credits Music: Chipper Doodle v2 — Kevin MacLeod (incompetech.com) — Creative Commons: By Attribution 3.0

En este episodio platicamos brevemente de la herramienta de privacidad Jumbo, Purism y sus diferentes dispositivos, y cambiamos de ultimo momento el tema original para discutir a detalle un articulo en Medium sobre porque no usar TypeScript y de paso comentar sobre PHP, HHVM, Hack, Angular, Java, etc.

Josh Wills, a software engineer working on data engineering problems at Slack, discusses the Slack data architecture and how they build and observe their pipelines. Josh, along with color commentary such as the move from IC to manager (and back), discusses recommendations, tips, tools, and lessons Slack engineering teams discovered while building products like Slack Search. The podcast covers machine learning, observability, data engineering, and general practices for building highly resilient software. Why listen to this podcast: - Slack has a philosophy of building only what they need. They have a don’t reinvent the wheel mindset. - Slack was originally a PHP monolith. Today, it is largely Hack-lang, HHVM, and several Java and Go binarys. On the data side, application logs are in Thrift (there is a plan to migrate to protobuf). Events are processed through a Kafka cluster that handles 100,000s of events per second. Everything is kept in S3 with a large Hive metastore. EMR is spun up on demand. Presto, Airflow, Slack, Snowflake (business analytics), Quiver (key value store) are all used. - ML worked best for Slack when it was used to help people answer questions. Things like Learn to Rank (LTR) become the most effective use of ML for Slack. - You can get pretty far with rules. Use machine learning when that’s all that’s left. - When you start applying observability to your data pipeline, a key lesson for Slack was to really focus on structured data, tracing, high cardinality events. This let them really use the tools they were already familiar with (ELK, Prometheus, Grafana) and go deep into understanding what’s happening in the systems. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2PsVA4q You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2PsVA4q

¿Alguna vez te has preguntado cómo funciona PHP internamente? ¿Qué configuración viene de serie? ¿Y hasta que punto es potente? Pues en este episodio analizaremos todos estos aspectos, para así, poder profundizar un poquito más. Pero para empezar ¿Qué es PHP? PHP es el lenguaje de programación más utilizado en el mundo web, la mayoría de páginas web del mundo utilizan PHP. Además, grandes frameworks como wordpress, drupal, joomla también lo utilizan, por lo tanto, se puede decir, que más del 50% de las páginas web del mundo, están utilizando de una u otra manera PHP ahora mismo. De hecho, grandes empresas como Facebook adoptaron y defendieron PHP, creado incluso un lenguaje de programación similar a PHP llamado HHVM, curiosamente, gracias a este proyecto, en la versión 7 de PHP se mejoró muchos aspectos, pudiendo igualar en velocidad a HHVM. PHP no se puede explicar sin entender las tres principales versiones: Versiones anterior a PHP 5 Durante 10 años se ha ido avanzando mucho en PHP, de hecho nació en 1995 y no fue hasta 2005 que apareció la versión PHP 5 que fue todo un cambio. Por decirlo de alguna forma, las versiones anteriores a PHP 5 son incompatibles, además de faltarle tecnologias nativas que hoy en día nos parecen básicas como pueden ser, objetos, JSON, etc. PHP 5 La versión PHP 5 es la que está funcionando ahora, prácticamente en la gran mayoria de los hostins del planeta, es la versión más moderna y estable. Se caracteriza principalmente por una mayor escalabilidad y por traer (por fin) el paradigma objetos a PHP. Además PHP 5 también incorpora mejoras en cuanto seguridad. PHP 7 PHP 7 ha sido toda una revolución, ha sido tan importante el cambio que ni si quiera han pasado por PHP 6 (una estrategia similar a la usada por Microsoft con Windows 10). Sus principales características son la velocidad (duplica la velocidad de procesamiento) y el poder utilizar por fin, tipado fuerte. Características de PHP Veamos las principales características de PHP. Muchas funciones nativas Mientras otros lenguajes tienes que importar módulos o librerías para usar una función, PHP te permite utilizar cientos de funciones sin tener que importar nada. Programas muy rápido Otra ventaja de PHP frente a otros lenguajes, es que es muy rápido programar en PHP. Tipado débil No es necesario declarar un tipo de variable, a diferencia de otros lenguajes, una variable string, la puedes convertir en un número entero, simplemente indicándole dicho número. Modular Puedes añadir módulos externos (cURL, MySQL, etc.) o crear el tuyo propio. PHP y APACHE Debemos de comprender que PHP y Apache son dos cosas totalmente diferente, por una parte, PHP es el lenguaje de programación y Apache es un servidor web. Por lo que quiere decir, que podemos tener instalado PHP sin Apache y utilizarlo desde la terminal. Esto explica, que cuando en Linux accedemos a la carpeta de configuración de PHP nos encontremos con dos carpetas, una llamada “Apache” y otra llamada “Cli”. La primera carpeta llamada Apache, hace referencia a la configuración de PHP cuando se ejecuta en Apache. La segunda carpeta llamada cli, hace referencia a la configuración de PHP cuando se ejecuta desde la terminal. Es decir, podemos hacer que PHP se comporte diferente, dependiendo dónde se esté ejecutando. Fichero de configuración de PHP El fichero de configuración de PHP se llama php.ini y contiene toda la configuración que indicará a PHP como se debe de comportar, consta de cientos de variables. Para entenderlo mejor, veamos algunas de esas variables. engine: Indica si PHP se debe de ejecutar o no. precision: Indica cuantos decimales puede tener un float. short_mode: Habita la opción de abrir php de forma corta, es decir

¿Alguna vez te has preguntado cómo funciona PHP internamente? ¿Qué configuración viene de serie? ¿Y hasta que punto es potente? Pues en este episodio analizaremos todos estos aspectos, para así, poder profundizar un poquito más. Pero para empezar ¿Qué es PHP? PHP es el lenguaje de programación más utilizado en el mundo web, la mayoría de páginas web del mundo utilizan PHP. Además, grandes frameworks como wordpress, drupal, joomla también lo utilizan, por lo tanto, se puede decir, que más del 50% de las páginas web del mundo, están utilizando de una u otra manera PHP ahora mismo. De hecho, grandes empresas como Facebook adoptaron y defendieron PHP, creado incluso un lenguaje de programación similar a PHP llamado HHVM, curiosamente, gracias a este proyecto, en la versión 7 de PHP se mejoró muchos aspectos, pudiendo igualar en velocidad a HHVM. PHP no se puede explicar sin entender las tres principales versiones: Versiones anterior a PHP 5 Durante 10 años se ha ido avanzando mucho en PHP, de hecho nació en 1995 y no fue hasta 2005 que apareció la versión PHP 5 que fue todo un cambio. Por decirlo de alguna forma, las versiones anteriores a PHP 5 son incompatibles, además de faltarle tecnologias nativas que hoy en día nos parecen básicas como pueden ser, objetos, JSON, etc. PHP 5 La versión PHP 5 es la que está funcionando ahora, prácticamente en la gran mayoria de los hostins del planeta, es la versión más moderna y estable. Se caracteriza principalmente por una mayor escalabilidad y por traer (por fin) el paradigma objetos a PHP. Además PHP 5 también incorpora mejoras en cuanto seguridad. PHP 7 PHP 7 ha sido toda una revolución, ha sido tan importante el cambio que ni si quiera han pasado por PHP 6 (una estrategia similar a la usada por Microsoft con Windows 10). Sus principales características son la velocidad (duplica la velocidad de procesamiento) y el poder utilizar por fin, tipado fuerte. Características de PHP Veamos las principales características de PHP. Muchas funciones nativas Mientras otros lenguajes tienes que importar módulos o librerías para usar una función, PHP te permite utilizar cientos de funciones sin tener que importar nada. Programas muy rápido Otra ventaja de PHP frente a otros lenguajes, es que es muy rápido programar en PHP. Tipado débil No es necesario declarar un tipo de variable, a diferencia de otros lenguajes, una variable string, la puedes convertir en un número entero, simplemente indicándole dicho número. Modular Puedes añadir módulos externos (cURL, MySQL, etc.) o crear el tuyo propio. PHP y APACHE Debemos de comprender que PHP y Apache son dos cosas totalmente diferente, por una parte, PHP es el lenguaje de programación y Apache es un servidor web. Por lo que quiere decir, que podemos tener instalado PHP sin Apache y utilizarlo desde la terminal. Esto explica, que cuando en Linux accedemos a la carpeta de configuración de PHP nos encontremos con dos carpetas, una llamada “Apache” y otra llamada “Cli”. La primera carpeta llamada Apache, hace referencia a la configuración de PHP cuando se ejecuta en Apache. La segunda carpeta llamada cli, hace referencia a la configuración de PHP cuando se ejecuta desde la terminal. Es decir, podemos hacer que PHP se comporte diferente, dependiendo dónde se esté ejecutando. Fichero de configuración de PHP El fichero de configuración de PHP se llama php.ini y contiene toda la configuración que indicará a PHP como se debe de comportar, consta de cientos de variables. Para entenderlo mejor, veamos algunas de esas variables. engine: Indica si PHP se debe de ejecutar o no. precision: Indica cuantos decimales puede tener un float. short_mode: Habita la opción de abrir php de forma corta, es decir

We get to work understanding the world of PHP, that scripting language that runs the vast majority of the internet. Is it more than just Wordpress? Join us as we find out! Kevin & Len are joined by Etienne Marais, a senior PHP developer at Superbalist. Before moving to Cape Town, we met Etienne at the Johannesburg Laravel User meetup that he was organizing. Etienne points us to the TIOBE index, Netcraft's survey and Venturebeat's analysis of popular languages on GitHub, consistently showing PHP as one of the most popular languages in use on the internet today. Etienne has been using PHP for nearly a decade and helps our panelists get up to speed with how PHP has evolved and matured. Follow Etienne online: - https://twitter.com/etbal - https://github.com/etiennemarais - https://medium.com/@etbal Here are some resources mentioned during the show: * PHP website - http://php.net * TIOBE Index - http://www.tiobe.com/tiobe_index * Top 10 languages on GitHub according to Venturebeat - http://venturebeat.com/2015/08/19/here-are-the-top-10-programming-languages-used-on-github/ * PHP Usage based on Netcraft survey - http://php.net/usage.php * LAMP Stack - https://en.wikipedia.org/wiki/LAMP_(software_bundle) * PHP 6 or PHP 7 - https://philsturgeon.uk/php/2014/07/23/neverending-muppet-debate-of-php-6-v-php-7/ * HHVM - http://hhvm.com/ * Hack - http://hacklang.org/ * Laravel - https://laravel.com/ * Docker - https://www.docker.com * Vagrant - https://vagrantup.com/ * PEAR (Legacy package management) - http://pear.php.net/ * Composer dependency manager - https://getcomposer.org/ * https://philsturgeon.uk/php/2012/03/06/packages-the-way-forward-for-php/ * Namespaces in PHP - http://php.net/manual/en/language.namespaces.php * Travis & PHP - https://docs.travis-ci.com/user/languages/php * MVC Framework - https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller * TWIG templates - http://twig.sensiolabs.org/ * Blade templates - https://laravel.com/docs/5.1/blade * Smarty Template Engine - http://www.smarty.net/ * Zend Framework - http://framework.zend.com/ * Code Igniter Framework - https://www.codeigniter.com/ * Symfony Framework - https://symfony.com/ * PHP The Right Way - http://www.phptherightway.com/ * Eloquent Models (Laravel) - https://laravel.com/docs/5.1/eloquent * Doctrine Models (Symfony) - http://symfony.com/doc/current/book/doctrine.html * Angular - https://angularjs.org/ * React - https://facebook.github.io/react/ * Phing - https://www.phing.info/ * Packer - https://www.packer.io/intro/ * Ansible - https://www.ansible.com/ * Joburg PHP Meetup - http://www.meetup.com/PHP-Johannesburg-Meetup-Group/ * PHP SA 2016 Conference - http://phpsouthafrica.com/ And finally our picks Etienne: - Build something with Laravel & Composer - Lumen - https://lumen.laravel.com/ - Laracasts - https://laracasts.com/ - Terraform by Hashicorp - https://www.terraform.io/ Kevin: - Kubernetes - http://kubernetes.io/ Len: - Semantic UI - http://semantic-ui.com/ Thanks for listening! Stay in touch: * Socialize - https://twitter.com/zadevchat & http://facebook.com/ZADevChat/ * Suggestions and feedback - https://github.com/zadevchat/ping * Subscribe and rate in iTunes - https://itunes.apple.com/za/podcast/zadevchat-podcast/id1057372777

上杉周作さんをゲストに迎えて、React, Redux, Facebook, ブートキャンプ, SF住宅事情、Airbnb, Uber, レッシグなどについて話しました。 Show Notes React.js Introduction For People Who Know Just Enough jQuery To Get By JS Bin - Collaborative JavaScript Debugging ReactEurope IKEA or Death Dan Abramov - Live React: Hot Reloading with Time Travel at react-europe 2015 Redux Cycle.js A cartoon guide to Flux — Code Cartoons Joe Hewitt Javelin (JS) HHVM Ember.js Programming bootcamps in San Francisco Course Report 2015 Bootcamp Market Size Study General Assembly And Google Team Up To Crank Out An Army Of Android Developers #地獄のサンフランシスコ - 講演のスライドと動画 | Shu Uesugi Google employee lives in a truck in the parking lot Renting in Las Vegas and commuting to San Francisco would save you $1,124 per month Airbnb ad campaign in San Francisco riles locals and librarians Uber to open a new office in Oakland Rebuild: 113: My Dad Is A YouTuber (N) ローレンス・レッシグ「皆で共和国本来の国民の力を取り戻そう」 | TED Talk 貧困大国アメリカ: 堤 未果 The "Lessig Method" of presentation 草泥馬 AirPaper Comcast's customer service nightmare

We chatting with some PHP & HHVM internals folks to learn what's been going on in the world of internals.

nodejs vs io.js – http://www.theregister.co.uk/2015/01/14/io_dot_js_version_1_0/ Fastclick: https://github.com/ftlabs/fastclick HHVM – http://hhvm.com/blog/8405/coming-soon-in-hhvm async mysql support HHVM – XHP v2 https://github.com/facebook/xhp-lib      

Dustin Whittle, Developer Evangelist at AppDynamics, and I sat down at SymfonyLive Berlin 2014 to get to know each other. We touched on PHP's past and potential futures through HHVM or PHP7, how competition and collaboration both improve open source software and how business benefits from that, Drupal 8, and more. This podcast is some extracts from that conversation! Read the full post and see the conversation video at the Acquia Developer Center: https://dev.acquia.com/podcast/170-meet-dustin-whittle-get-more-done-better-faster-together

Show Notes Magento Enterprise Edition 1.14.1 lands, Alan Kent waxes poetic about M2 Service Contracts and HHVM in his blog - [On Magento 2 being "open source"](https://twitter.com/magenticians/status/526653045082320896) - [M2 service contract patterns (Alan Kent)](https://alankent.wordpress.com/2014/10/31/magento-2-service-contract-patterns/) -... No

  Fredrik och Kristoffer snackar om utvecklingen av programmeringskonsten och undrar varför saker inte går snabbare framåt än de gör. Från webben där alla verkar återuppfinna elementarpartiklar om och om igen, via våra likformiga utvecklingsmiljöer till programmeringsspråk där vi återupptäcker Lisp med jämna mellanrum. Famlar vi fortfarande i blindo i väntan på att någon ska upptäcka elden? Vi hinner också med lästips kring Lisp och problemen med de som predikar entydiga och enkla Svar på alla problem.   Avsnittet sponsras av Malmö startup studio. Länkar Steve Yegge Den statiskt typade säkerhetsvakten på flygplatsen Execution in the kingdom of nouns Steve Yegges blogg Äldre texter Steve Yegge skrev på Amazon Joe Armstrong - skaparen av programmeringsspråket Erlang Rob Pike Emacs - familj av utbyggbara textredigerare js2-mode - javascriptläge för Emacs som Steve Yegge ligger bakom React - javascriptbibliotek för användargränssnitt Origami verktyg för att skapa gränssnittsprototyper HHVM - Facebooks virtuella maskin för PHP och Hack I'm done with the web Cappuccino 280 slides Objective-J Playgrounds - interaktivt och visuellt verktyg för att experimentera med kod skriven i Swift ECMAScript 4 - versionen som sköts i sank ECMAScript - det "officiella" namnet på språket vilket Javascript är en implementation av Javascript och moduler är ett invecklat kapitel Arguments-objektet i Javascript är "arraylikt" men faktiskt inte en array Swift - nyligen släppt språk från Apple Första klassens funktioner Allt är redan upptäckt - i sluten på 1800-talet. Tyvärr inte sant Memristorer Paradigm - tydligt koncept eller tankemönster Delat minnesutrymme System 6 Windows 3 Amiga Actormodellen för samtidig beräkning STM - software transactional memory Race conditions Läckande abstraktioner - abstraktioner som inte döljer underliggande detaljer väl nog Licensen för HHVM - PHP- och Zendlicenserna till största delen Fall med mjukvarupatent till allmänhetens fördel Tesla motors släpper patent … eller? Uber - taxi för rika Doug Hoyte Let over lambda - bok om Lisp On Lisp - gratisboken Kristoffer rekommenderar att man läser före Let over lambda Instapaper - läsa-senare-tjänst The little schemer - en ovanlig och underbar liten bok om programmering Presentationer av Friedman Ten great books - Steve Yegge CAR och CDR Guy Steele Common Lisp the language Practical common Lisp Rabbit - a compiler for Scheme Tidernas första paper om Scheme VAX - gammal instruktionsarkitektur Netscape - företaget bakom den en gång stora och populära webbläsaren med samma namn W3C - World wide web consortium, arbetar bland annat med standarder för webben Bret Victor REPL - read-eval-print loop Agile och Scrum - populära sätt att filosofera kring mjukvaruutveckling Creativity, inc - bok om Pixar och hur de försökt arbeta för att fortsätta utvecklas och frodas Pixar Objektorienterad design TDD - testdriven utveckling Richard Feynman Cargo cult science Robert Martin SOLID-principerna Tage Danielsson

For episode 42 we are blessed by the wonderful and talented Laura Thomson, Senior Engineering Manager at Mozilla. Laura drops science on managing engineers, Minimum Viable Bureaucracy, HHVM and Hack, and her mid-Atlantic coast accent. This is a must-listen for folks who manage tech teams. Check out our sponsors, Engine Yard and WonderNetwork Follow us on Twitter here. Rate us on iTunes here Listen Download now (MP3, 34.5MB, 1:17:38) Links and Notes RCS PHP and MySQL Web Development (5th Edition) Minimum Viable Bureaucracy: Video, Slides The Tyranny of Structurelessness Jeri Ellsworth leaving Steam Sara Golemon (is awesome) HHVM blog Hack for HHVM Coffeescript Go CodeIgniter seeking a new home

Naoki Hiroshimaさんをゲストに迎えて、Two Factor Auth、iPhone、Android Wear、Hack/HHVM、将棋電王戦、2048などについて話しました。 Show Notes N: This is a happy ending not only for me. Two Factor Auth List Authy Do not use your Google Voice number for Two-Factor Authentication How I almost lost my $500,000 Twitter user name @jb... and my startup Google buys SlickLogin, a startup out to kill the password with sound Knock - unlock your Mac without a password using your iPhone iOS dominates Podcast audience Android Wear | Android Developers Pebble Smartwatch Moto 360 by Motorola Rio PMP300 This is Healthbook, Apple's major first step into health & fitness tracking Hack: a new programming language for HHVM | Engineering Blog | Facebook Code Hack HHVM Hack Isn't PHP ひらがなせいかつ への いざない 将棋電王戦 The Brilliant Hack That Brought Foursquare Back From the Dead Goodbye, Google | Stopdesign Threes! - Android 2048 Flappy 2048

Grageband 10.0.2 Mejora la estabilidad y aborda una serie de cuestiones de menor importancia • Agrega la opción de exportar las canciones en formato MP3 • Contiene múltiples mejoras a la accesibilidad • Incluye 3 nuevos Drummers y kits de batería de los géneros rock, compositor, y R & B * Facebook Hack Hack ha sido presentado esta mañana y puesto a disposición como código abierto para animar al resto de personas, además de usarlo, a aportar sus contribuciones para mejorarlo. Wired nos indica que podemos ver a Hack “como la nueva PHP”, y de hecho es el lenguaje de programación que usa actualmente Facebook en su servicio. Hack también se ejecuta en HHVM y permite a los desarrolladores utilizar los tipos dinámicos y tipos estáticos en sus desarrollos, llamándolo como tipificación gradual, el cual es el primero en ser llevado a un lenguaje real. iPad 2 Jubilado. Ya nos jubilan el ipad 2 ha pedido la prejubilacion… Reloj Android Wear.

Joe Watkins and Sara Goleman join Phil to make one hell of an episode. These two are not only core contributors to PHP, but are behind a lot of RFCs and decisions that make PHP considerably better. We talk about a whole bunch of awesome stuff, including progress of the named parameters RFC - and the chances of it making in, the new accepted PHP 5.6 feature PHPDBG and what it means for you, HHVM and its relationship to “The PHP”, wether PHP should have a spec for implementations of the language, and a whole bunch of other stuff. Sara knows a thing or two about HHVM because she helped build it. Joe knows a thing or two about PHPDBG because he helped build it. So basically… THEY’RE SMARTER THAN YOU ARE SO LISTEN TO THEM DAMMIT!

So our pace is a little slower due to work crap, but DEV HELL LIVES. Episode 6d6 kicks off with us waxing about what’s exciting in PHP development nowadays. We also talk about upcoming appearances at TrueNorth PHP, NomadPHP and SkiPHP. Then we get into the discussion of alcohol consumption at tech conferences, and malware on the PHP.net site. Check out our sponsors, Engine Yard and WonderNetwork Follow us on Twitter here. Rate us on iTunes here Listen Download now (MP3, 25.7MB, 55:08) Links and Notes TrueNorth PHP NomadPHP SkiPHP HHVM Hack for HHVM presentation slides Composer Dev server in PHP 5.4 Respect/Validation Idiorm Booze, Babes and Buttholes Blog post on malware served from PHP.net