Which won't happen, I can tell you. PHP's release dates always slip by at least a month, and that's without a very unstable master branch like PHP 7 has.
If it does happen, it'll take a few micro (7.0.x) releases until it reaches stability.
However, Zend not mentioning this is to be expected. The company's founders (Zeev Suraski, Andi Gutmans) and employees (Dmitry Stogov and some others) are some of the biggest opponents of strict typing in PHP.
-- disclaimer: I am a former PHP internals developer
He did vote in favour of the RFC. However, this was reluctantly, at the last minute, and under pressure. He is very much opposed to strict types, but he felt this was the only way scalar types would get into 7.
... and available on general cheap webhosting sometime around 2020. If we're lucky.
Thank god our company slowly moved away from building small PHP websites that have to run on the most fucked up PHP installations from the before-time. Now it's PHP 5.6+ everywhere :-)
Okay, sure, instead your new job is to play security and sysadmin for the DigitalOcean containers for all the small local business Wordpress sites for say $10 an hour.
Shared Hosting has many downsides, but it still fills an incredibly important niche for businesses for whom a web presence beyond a Facebook page is needed but real managed hosting is completely out of their price range.
Lol, I'm in the middle of doing this - moving from shared hosting to a DO droplet. It is painful. Setting up the server isn't so bad but email is a nightmare. Unfortunately the large email providers are moving to block a lot of smaller servers it seems which might make it harder in the future at present using an SPF seems to get mails through.
DO of course have a Wordpress appliance which makes it pretty easy to set up, if you can manage Wordpress you can do it, so long as you're not concerned with getting in to the details of security of your droplet. It's probably no less secure than a lot of virtual hosting arrangements with 777 access on content folders and such.
[If anyone wants a free $10 credit for DO then feel free to message me.]
FWIW I've been seeing an increase of spam from DigitalOcean networks recently -- over the last couple of months or so -- and that's probably going to bleed over into the RBLs and other countermeasure systems that larger mail services use.
I've been having all my clients sign up for a Mandrill account for sending email since it's so unbelievably cheap (usually free) and it completely fixes the email problem.
Ah, free for up to 12k emails, or something close - looking at this now. Thanks for the tip. One thing I have noticed is their terms preclude the sending of material under Fair Use terms of copyright law ... but I'm assuming that is a mistake.
>"You represent and warrant that you either own or have permission to use all of the material in your Emails." //
Fair use isn't permission, nor ownership, it is statutory right of use though.
They bring in Spamhaus' definition of spam too, which on first reading appears to be self-contradictory - requiring each message sent to be explicitly requested. Taken by the letter this would mean I couldn't, for example, send out a message to a group of customers with whom I had a standing relationship to let them know of a change to terms & conditions, for example, without explicit consent. That means anticipating every email. Catchall phrases like "agree to receive all email" wouldn't work as the customer "has not verifiably granted deliberate, explicit, and still-revocable permission for it to be sent".
Indeed "still-revocable" permission means that as soon as a mass email is sent it becomes spam regardless, it's no longer revocable. There are other problems too - verifiable opt in means an alternate system needs to be used for the verification emails.
In turn that means that any email I send to multiple recipients puts me in breech of Mandrill's T&Cs.
Mandrill have a circular reference from the Terms "You retain ownership of the materials you upload to the Service. We may use or disclose your materials only as we describe in these Terms and our Privacy Policy." and in the Privacy Policy:
>"Information You Provide to Us: When you register to use the Services, communicate with our customer service team, send us an email, or post on our blog, you’re giving us information that we collect. That information may include your IP address, name, physical address, email address, phone number, credit card information, and other details like gender, occupation, and other demographic information. By giving us this information, you consent to your information being collected, used, disclosed, and stored by us, only as described in our Terms of Use and Privacy Policy."
In short the policies allow them to harvest data from emails sent with the service and to use it as they wish. They go as far as to intimate that because they do use the message data internally that the service is not for personal email. There's also a clause Terms 5.f that allows doxing and combining the info with your account data.
The "protections" for selling of your info with the business don't work as there are standard "we can alter this agreement unilaterally" conditions.
tl;dr law - it's complicated. This service is absolutely not for "personal" emails however.
A million times this. Also some regularly missed advantages of shared hosting are that its usually available in the same country as you, is portable unlike PaaS solutions, doesn't require lots of legwork and tends to come with a shit ton of bandwidth up front meaning no per-Gb costs which can ramp pretty quickly.
Shared hosting does mean that your provider is likely keeping their platform patched and up to date, which is possibly painful for you but likely nice for everyone else.
The alternatives seem to be giving customers a VM or a dedicated server which tends to mean it's _never_ going to get any security updates since the day it was first set up.
Shared hosting is a pain, but the alternatives have the potential for even more pain.
As a former herder of dedicated servers purchased for this sort of thing, you'd be surprised how difficult it is telling people they need to pay to upgrade it. We had a client with an old supermicro P3 running red hat 7 (not RHEL) until last year. Genuinely surprised it lasted as long as it did.
Edit: it was RH7, not RH5. Just checked. Still bad.
I used to work as a DCO in a relatively large DC. It was always slightly terrifying when you'd be asked to investigate a customers unresponsive dedic only to find out it's attempting to boot ubuntu 6 LTS. "Well I don't see why it's broken -it was working absolutely fine and we've not touched it in years!"
No it doesn't. If you're a small company paying for shared hosting at < $20 per month is a far better alternative than hiring an admin to run DO instances or whatever. If you have a full time developer who happens to know how to administer servers well it's fine, but many companies barely even even have a full time developer. For them shared hosting makes perfect sense.
I'd argue it just needs to evolve and improve. For example Azure's Web Sites and to a lesser extent Amazon's S3 do a great job for what they both are, and they're both "shared hosting."
What? You are suggesting that everyone should run their own server? And you are suggesting that nobody even ran a real production site on shared hosting?
You could say the exact same thing about VPS servers compared to dedicated hosting and be equally wrong. Please accept that there are different use cases that come with different solutions, of which shared hosting is one.
It depends on the hoster and how much you're willing to pay. If you're paying $2.99 a month then yes, you're probably going to have a less than predictable experience.
I work for a shared/dedicated hoster, we're geared price-wise at the higher end of the market and we provide shared hosting for our business customers.
Our shared environments are closely monitored and never oversubscribed. We're constantly looking out for customer sites that misbehave and shut down those that are resource hogs or service affecting.
We have loads of customers running the internet facing parts of their businesses on shared.
Shared hosting, like all other things, is a case of "you get what you paid for".
Why are you not running javascript? Is it a environment restriction, out of security concern or personal preference? Since tone can be tricky on the internet I'll just add that I am genuinely curious about this.
Last time it came up on Hacker News, it's because a large amount of people apparently believe that all sites should run without Javascript. I was told that as a web developer that I should "stop trying".
It tends to be a classic case of blaming the tools for the actions of the people using them.
Sometimes it's not intentional JS blocking. I run adblock and ghostery and by blocking 3rd party scripts some crucial part of a site just break also.
For example, people track link clicks in a web app and they do it with Google analytics. If not handled correctly, it will break all the navigation on a page.
I was only doing so momentarily as a part of debugging the mobile issue. I'm fully aware that most people (intend to) run javascript most of the time, but I also think it's preferable that content doesn't introduce an unnecessary dependency on javascript. I haven't investigated this case in enough depth to determine if it's necessary or not, but the end result leads me to believe it shouldn't be.
Well, the biggest issue with PHP in my opinion was the interpreter. Let's cut the cost of function calls by 90%, and PHP would be back in the game of performant languages.
There are tons of new features, this list is pretty pathetic. I'm not sure why the spaceship operator got top billing when there has been so many other great changes.
> I feel like I want to test what happens if you put values like "", false, " ", 0, an empty array, etc etc etc in front of ??.
All of those would result in the variable being assigned those values: the null check uses the same semantics as is_null(), and the truth table for those values is:
...Abstract syntax tree? I didn't know it was implemented without using AST. It surprises me, as I've been always told that ASTs are necessary to implement a compiler. Maybe there seem to be some alternatives?
This is not meant to be an endorsement of this method, but PHP <7.0 uses a single-pass compilation where the parser itself does the opcode compilation. A lot of the buggy and quirky behavior PHP exhibits (at least when that behavior is unintentional) is the result of this process.
Like a lot of extant PHP, there's no real reason it was done this way: it's just the method Rasmus et al happened to program the original engine, and it's grown organically since then. With the AST, phpng, and the uniform variable syntax, I'd argue PHP7's main feature is finally getting around to correcting the sins of the past.
> A lot? Please stop spreading wrong info. In the words of an internal developer,
You may disagree with me saying "a lot", and that's fair, but I don't think it's fair to say it's "wrong info" and NikiC's characterization that it has "no direct effect on userland devs" is disingenuous, given the RFC lists several changes to syntax and behavior: https://wiki.php.net/rfc/abstract_syntax_tree#changes_to_syn...
Good to see PHP slowly improving, although I haven't used it for years now.
On a side note, does anyone know why Drupal 8 is apparently so absurdly slow? I know it's not entirely fair to compare against D7 as it's still technically "under development" but it just seems insane to take that much of a performance hit for nicer OOP semantics...
Drupal 8 is being developed in the Symfony framework. You may have been exposed to a deployment running in development mode (app_dev.php in the URL is a good sign even if not a necessity).
Once the debug flag is turned off, Symfony won't check the freshness of the dependency container as well as templates, bootstrap caches, etc. (you clear the cache manually in production.)
As to what the Drupal devs may have added on top of the framework, I have no idea. Being a generic CMS, I presume their abstractions are a little bit overengineered.
AFAIK Drupal doesn't use symfony "framework edition" , but symfony/http kernel library at its core to abstract the default PHP http api. So it is a Symfony app as much as Laravel is ... it's not Symfony full stack.
D8's a work in progress, and if there's one thing I wouldn't be too critical of a wip for, it's performance.
Frankly I don't really see drupal's place in the world anymore. It's so absurdly config-heavy, which may have made sense a decade ago but not now. Everyone will just install composer, put laravel/symfony on there, and be off to the races. The era of giant pages of drupal-managed plugins is over, and replaced by package managers + slimmer CMSes like joomla or concrete5.
Drupal 8 actually using a lot of Symfony2 components internally now, and you should be able to manage your modules with composer if you so choose.
I'm really excited for D8, no other CMS to date has been as easy to administer in my eyes, and now that they're dramatically revamping the module and theming stories I may even enjoy writing modules and themes once more.
I know, and I think they're making the right decisions to make it the best drupal it can be. I was really excited about it 2.5 years ago.
My point is I think the fundamental idea of drupal is obsolete. If it can eke out a few more years of relevance and take market share away from WordPress, all the more power to them,
I'm a WordPress guy, so I am not a Drupal expert. But Laravel/Symfony and Drupal are targeting mostly different audiences (application developers vs website developers/website owners).
Laravel/symfony are just one component. It's the approach of organizing your site as packages, and properly namespacing and exposing well-documented class libraries of your own that's becoming the dominant approach even for websites. Even the concept of a 'website' as simply rendering pages is something fewer people need a custom install for - squarespace et al have the basic sites covered, and for anyone who needs a pretty specific feature there's plenty of other platforms: shopify (commerce), nationbuilder (nonprofits), etc.
Having worked with many PHP CMSes, the config for managing various drupal plugins is often far more complex to setup, maintain, and migrate than simply writing that feature in my own little class in concrete5, joomla, or even without a CMS. I get the appeal behind wordpress (even if I think it's implementation is complete garbage), because non-technical people can still setup and manage their plugins. Most of my clients who are/were on drupal, became my clients after they were inevitably crushed under a pile of drupal config.
Drupal's place hasn't really changed much. It's for people who want more flexibility than Wordpress while having more out-of-the-box features than the frameworks you mention.
I'm sure D8 is a lot slower--isn't performance usually the last thing worked before release?--but I don't think D7 has really been distinguished by its speed either. In my experience, D7 speed tuning consists almost entirely of inserting and tuning cache layers at every level. In other words, working around the slowness of the application.
Drupal seems great for a content-heavy site that caches well. Personally, I would not build an account-based, heavily personalized web app in Drupal unless I knew the audience was pretty small.
Even in the dinky D7 sites I've run, we got significant performance improvements just by handing off search and commenting to services other than Drupal (SOLR and Disqus).
and tell me what you think about it. When stuff like this exist, does it matter if it gets all the shiny new features and speed improvements? Not to mention that by php's development culture, these new features probably end up half baked and with it's own set of weird behaviors...
I'd say it's to do with having been rebuilt with Symfony components. That's not to say symfony is, by necessity, slow, but I going to guess that completeness and stability was first for such a big change before performance. But... that's just a guess.
I think it is exactly the fact that they are using Symfony components. Symfony and a lot of other PHP frameworks went head first into the non-sensical enterprise Java abstraction and IoC hell from 10-15 years ago that current Java developers are running as fast as they can from. That overhead comes at a cost.
Hrm... I got a few down votes for my guess (well, I started with "I'd say that..." but it was later qualified as a supposition. I also wasn't making a judgement call that it was bad - just observing that they made a big architectural change, and performance probably wasn't the primary consideration for rev 1. Weird...
Being a PHP dev since the early 00's it's great to see the language moving forward with features and performance and seemingly less hate towards it from the developer community at large. For a while there seemed to be a "PHP-shaming" thing going around. If you did PHP you were sort of in an untouchable uncool class.
Hack is also a substantially better language than PHP.
It, directly or indirectly, fixes a lot of horrible behaviour. PHP's absurd comparison operators, for instance, are safely usable once you drop them into a statically typed environment.
I don't believe it's just that. One of the coolest features which if it is used properly actually speeds up the response times of a normal blocking php script /app flow is the as async feature: http://docs.hhvm.com/manual/en/hack.async.php.
The spaceship <=> is actually a lot cooler than many PHP devs realize. Rails devs find it extremely handy. Now that my PHP apps are moving away from being big apps that render full web-pages, and towards being a thin application layer that just renders JSON, I'm finding a higher % of my code is just sorting operations. Closure has helped a lot with this, and nearly all my <=>s are almost certainly going to be in the form of `function($a, $b) { return $a->getThingy() <=> $b->getThingy(); }`
Scalar type hints are a bit of a no-brainer. Type-hinting classes is nice, but there's a lot of sloppiness out there because if you can't type hint as a scalar, not only do you need a separate check to see if it's int or string, you also specifically cannot say it's non-object/array in your function declaration. One of the biggest inconsistencies I see, especially on old CMSes, is where you'd have a method in one class like `function doThing(Page $page) {`, and elsewhere as `function differentThing($page) {`, and sometimes differentThing's $page is a Page, other times it's an int with that page's ID or name. Yes there are all kinds of ways to check for that today, but it benefits everyone if the easiest way to do something is also the right way.
Return type declaration has been in Hack for a while, and it's really handy there. Any C or Java programmers know how useful they are. My big hope here is that they encourage others to stop returning mixed-types, which is a pattern that inevitably just puts more control logic around every call to that function. I don't care too much about nullable type-hints on parameters (you can still set a default `= null` to allow nullable), but I'm _really_ hoping the nullable return-types passes. Having worked with this for a while in Hack, return types are far more useful if they're nullable. e.g. you say `function isUserActive(): bool`, that's totally fine since you're clearly expecting it to be true or false, but if you had `function getActiveUser(): User`, you'd want the option to return null if there is no active user, which could be done nicely as `function getActiveUser(): ?User` if this passes: https://wiki.php.net/rfc/nullable_types#return_types
Now that we're finally actually making a proper PHP spec, I'm not as excited about 4 and 5 as they'd like us to be. It's definitely faster, but if the Zend engine isn't the only game in town, it doesn't matter as much. All the HHVM benchmarks I've seen still put it way above PHP7.
> Now that we're finally actually making a proper PHP spec, I'm not as excited about 4 and 5 as they'd like us to be.
I was the only person who seemed to care much about the spec, and I quit. The spec has several broken tests, numerous omissions and inaccuracies, and doesn't mention any of the really important PHP 7 features.
All true, but practically speaking I don't know how complete the spec needs to be. Looking at the HHVM project, they fail a lot of the basic PHP unit tests, yet also have 100% parity with nearly every major CMS/framework there is. PHP is just old, and as gone without a spec so long that there's a whole pile of code that nobody ever touches anymore. Simply implementing a subset of the spec, like HHVM has, is really all I need.
Heck, I'm kinda felling bad as a Pythonista. We're lagging badly speed wise.
Sure, there's PyPy but it's not compatible with the mainstream C-Extensions so pretty much a no-go for most of my projects. Hopefully Piston will come to rescue in the future.
The ones I miss most frequently are a faster json parser (I use ujson), a faster msgpack parser and a faster database driver. The pure python versions (even on PyPy) don't make the cut :(
Are you not able to use C extensions for some reason? Both the stdlib json module and the msgpack-python implementation have C acceleration modules (with pure Python as a fallback).
json parser on pypy is competitive, try it (or give us examples where it's not). msgpack needs a better impl, but can be done, database drivers seem to work over cffi at reasonable speed.
I just checked out and seems like pypy has made some good progress database driver wise!
So I went ahead and installed pypy 2.5.1 to compare the json performance. It got better but ujson is just crazy fast. CPython (w/ ujson) is 70% faster to loads and 50% faster to dumps a sample json from my project (50~156kb json). I expect msgpack to be the same.
Unfortunately seems like Pypy still doesn't pay off in this app, but it might in many others that don't spend as much time (de)serializing.
ujson breaks the spec btw ;-) We tried doing the same thing but cffi callbacks are slow. We should maybe revisit that (and make callbacks faster, we did get better on that)
To be fair, if json being 50% slower means your whole program is slower, even if other parts are faster, generally means that your bottlenecks are in serializing/unserializing and not in the VM, so we have really nothing to work with here :-)
The idea is that the old php syntax "function foo ()" remains unchanged [1] so developers can keep searching for "function foo". Removing "function" as keyword is a different topic and is discussed in a separate php thread [2].
The thing you mention ("float function add(){}") keeps the option to search for "function add", but I am unsure why this is not taken into account in this proposal.
Anyhow, I am pretty happy this finally made it to the php language.
Having 'function foo' be grep-able is _wonderful_. My last language, Ruby, isn't very grep-able, but my current one, Rust, uses 'fn foo', and being able to just use 'git grep' to find things is _wonderful_.
Which if you read it out, it sounds entirely natural "This is a function called foo, which takes some params, and returns a float". Most of the other variants don't read as naturally.
> Since that's how it's done in other languages and people would feel at home with it.
PHP doesn't need to copy the mistakes of other languages. It's got plenty of its own mistakes.
It's fairly common in languages that determine (return) types themselves, e.g. Haskell, Scala and F# all use this syntax. Most languages that use a C-style syntax put (return) types in front.
It makes very little sense for PHP.
A function definition now even has both styles:
`function foo(argtype arg) : rettype` instead of `function rettype foo(argtype arg)` or `function foo(arg : argtype) : rettype`.
AFAICT both Haxe and AS3 consistently put types on the right, including argument declarations. Other languages consistently put it on the left. Most languages make a choice like that; PHP mixes things up a bit.
But then, it wouldn't be PHP if it was too consistent ;).
To be fair, it's not the same as an argument type. The type of `foo()` isn't int, it's function. You're not specifying the type of the thing itself, merely the type of what it returns. Though this seems to have been lost on the creators of C. ;)
Putting the type first for parameters and last for return values seems like exactly the same kind of inconsistency that has already earned PHP plenty of criticism. Personally I kind of like the Pascal style, I use the C style all day every day, but mixed style seems like the worst option available.
Disclaimer: I use the word "type" in the following to refer to types, tags and classes, because I'm feeling lazy ;)
> Return Type Declarations & Scalar Type Hints
This seems a shame.
We can only add type hints to arguments and return types if we're writing arguments and return values, which is unnecessarily verbose. We should really add these types to the functions themselves. For example:
We've given types to the inputs and outputs, but the functions themselves still just have the type 'Closure'; there's no indication about what they accept or return. Functions are meant to abstract, but this implementation of type hinting forces us to go and read the implementation!
For example, if we've written the following and we want to add types (where I've put "???"), we need to look at the implementations of $dbl and $neg:
Now if we want to add types to $dblneg, the implementations of $dbl and $neg don't help; we have to dig even further and read the implementation of $mult.
All of this would go away if we could hint the function instead, eg.
Here I've used the ": ???" syntax to hint the whole function rather than just its return value, and I've written "Closure(x, y)" to mean a function type from argument type "x" to return type "y". This means if we have a function, like $dbl, we can query its type in the usual way (`typeof $dbl`) and get the argument and return types without having to read any source.
Note that this doesn't require generics/parametric-polymorphism, since all of the types I've used are concrete. However, adding that would be the next logical step ;)
Note that we can trivially extend this scheme to functions with multiple arguments, in all of the various, incompatible ways PHP lets us define them:
Between PHP 7 and HHVM, and what appears to me to be an increasingly fragmented community, I decided to jump ship to Ruby on Rails as my development platform of choice for web apps.
This is not to say that PHP won't work fine for many people; I just don't care for the (several) directions PHP is going in.
The introduction of a language specification by Facebook is great.
The fact that it took over a decade for a language specification to appear is less so.
PHP-NG/PHP 7's troubled birth, and its contention with HHVM, does not bode well for PHP's future. I feel like it's going the route of Perl 5/6;Python 2/3.
People do already choose languages other than PHP because they find PHP crappy. But in evolutionary terms, clearly PHP (and by extension Hack) are evolving, and are successful in their niche. If you don't want to use PHP you don't have to, alternatives already exist in abundance - including, of course, the fork of PHP itself. So use Java, or Python, or Ruby or C# or whatever floats your boat.
But if you're arguing that PHP should not be allowed to exist despite there still being a community that uses it and despite there still being improvements made to the language and despite its success, that's not an evolutionary argument, it's an elitist one.
If you stop development on PHP then lots of your favourite websites will need to waste an awful lot of time and money switching to a new language and retraining developers.
1. Scheduled to come out in Q4 2015
2. <=> operator, see https://wiki.php.net/rfc/combined-comparison-operator
3. Return Type Declarations & Scalar Type Hints
4. Speed improvements (25-70%)
5. Yep, speed improvements are for real.
You're welcome.