Given HHVM is already being dropped from PHP packages because of its lagging compatibility, announcing that they're not targeting PHP compatibility any more might be the nail in the coffin for HHVM (and thus Hack) as a viable “upgrade” from PHP for existing codebases.
I mean, it's great that Hack will work for new Hack code and existing Hack codebases, but there aren't a lot of those. It makes sense for Facebook — why waste your efforts on maintaining part of your runtime that you don't need? — but I wonder if this will consign HHVM to irrelevance in the long term. Maybe Hack is a compelling platform for new code, but then, why use this obscure proprietary Facebook thing that's a bit better than PHP when you could use any of the numerous other languages out there that are also better than PHP but have much better ecosystems?
Personally this makes me sad because I wanted to see a standardised, multiple-implementation PHP language. Facebook did, even. They paid someone to write a spec: https://github.com/php/php-langspec
Maybe someone will write a new PHP implementation to take that idea forward. Or maybe we'll be stuck with Zend forever.
It may be just my lack of familiarity with the PHP / Zend, but it seems like one of the most significant things that HHVM achieved was a wake-up call to Zend. It seemed like they suddenly started putting some serious effort in to PHP7's runtime, and publicising what they were doing. A bit of a wake-up call to a language that was languishing for performance.
Just wondering:
"numerous other languages out there that are also better than PHP but have much better ecosystems"
What languages are you thinking of?
I've used a lot of different languages, but I still think PHP is awesome for web developmemt. Being normally limited to "one request, one execution" might be an annoying limitation in some situations, but other than that I think PHP does the job quite well. So that's why I'm wondering what you think is a better existing alternative.
Out of curiousity when someone says "awesome for web development" I would generally expect Python or Ruby to be in the following sentence. Maybe even js/node (if that's your cup of tea).
I can understand the plus points are an enviably simple deployment story and ease of recruiting developers. Is there anything else that you would argue makes PHP especially suited to the web over other competing languages?
Not the OP, but my experience: C# would be my first choice, but in my current job I've had to work on Ruby on Rails and a Symfony app with PHP 7 and I would choose the latter any day of the week.
I really dislike working with Ruby because, you know, who knows what the hell the code does until you try running it, and the IDE support is terrible.
On the other hand, working in "modern" OO PHP feels a little like working in a weird, older version of Java. PHPStorm can give a great IDE experience, I can add type declarations everywhere, the code is generally predictable once you learn some PHP quirks, etc. Also, in my opinion, Symfony is way better designed than Rails, and definitely closer than ASP.NET MVC than Rails is.
I feel like it'd be a pretty different story if I were working on Wordpress or some ancient legacy PHP code or whatever, but I'm not, so that's not really my concern.
Symfony is really great fun to work with, the attention to structural design and implementation is divine. As projects grow they almost get easier to work on, as Symfony forces and supports you in modularising and reduction.
The strength of PHP is the fact that you can get php hosting for almost no money, that takes no effort to setup, is shared but isolated, and is almost always portable
A programmers response is “I can throw Django in a container” or “I can just buy a digital ocean droplet”, and that’s true for a Developer, but it’s like putting Linux on your grandma’s laptop - you can maintain it, but the target audience can’t
The reason people build sites in PHP is that the people for whom they’re building the sites can trivially support it. Forever.
Most web interactions are: your client sends a request to a server, the server sends back a response. That's kinda the model of php: single execution, no need to manage memory or resources because the world is destroyed once you've send your response. So php is a good fit for webdev.
Until you start playing with sockets or things like kafka then you really want languages which are made for long lived processes. But if you're just making a REST API, blog or anything which is not an app with sockets php is a good choice. Especially since 7.0, composer and the current leading frameworks Laravel and Symfony changed the landscape.
I really like the that you don't need a templating language on top of it, just use shorthand php syntax instead.
I also find that developmemt time is quite fast, even without using frameworks.
You probably don't need templating languages or frameworks, php makes it easy without it, it's built for it.
The performance is quite good, way better that most people think. It's also easy to write functionality in C if you really need to go all out.
For other stuff than web development PHP has it's downsides. It's made for building websites and in my opinion it's doing that job very well, but most other languages are general languages that works better for most other things.
I think most people would enjoy PHP way more without a heavy and insanely slow framework.
It makes me sad that, as a Mac-based developer, installing & updating HHVM takes half an hour (via Homebrew). I imagine that has taken the wind out of many people's sails, when contemplating migrating/updating codebases to HHVM's (superior) syntax.
Sorry, I know this is a pain; I'm hoping to fix it by the end of the year (along with bringing back nightly debs, and supporting more recent versions of debian/ubuntu). For homebrew build times, there's https://github.com/hhvm/homebrew-hhvm/issues/5
If they are not going to specifically target the language compatibility, then the compatibility doesn't exist. My interpretation of this post basically speaks the death of HHVM support PHP, and start exclusively as runtime for Hack.
> Given HHVM is already being dropped from PHP packages because of its lagging compatibility, announcing that they're not targeting PHP compatibility any more might be the nail in the coffin for HHVM (and thus Hack) as a viable “upgrade” from PHP for existing codebases.
They're dropping PHP5 support, but it sounds like they're not actively trying to be incompatible with PHP5, so I doubt that gets worse right away. There's no existing codebase that's PHP7 already that would consider Hack, is there?
I mean what problem does it really solve when PHP7 has much more robust typing? At this point I think it's only instance variables and inline variable declarations that can't be typed.
HHVM & Hack solved two big problems that made PHP difficult for Facebook and other large companies with large existing PHP codebases: Speed, and the lack of type checking
Now the PHP ecosystem is more mature – PHP 7 eliminated the speed differences between HHVM and PHP, and a bunch of static analysis tools find 95% of the bugs that HHVM's typechecker finds.
It makes sense that this would be an inflection point for the future of HHVM.
I hope that more features from HHVM make it into PHP core – especially property types and generics – because, whatever FB decides to do with HHVM, PHP is here for the long-haul.
It catches so much stuff, I've been using PHP since 2009 and it there was still stuff I was doing day to day it flagged me for, it's not only that it makes you write better code but it catches so much stuff that you no longer have to hold in your head (things like "Method throws an unhandled exception" etc).
In terms of "wow" (impact vs amount of effort required) it's second only to TypeScript in the last year or so for me.
Not a co-incidence that both tools add better type checking (amongst a lot of other useful stuff) to the languages I was stuck using.
Thanks for the recommendation – I've used PHPStorm when doing large refactors, and it's incredible.
Unfortunately, you can't force everyone to use it (especially given its price). That's why a bunch of people have written separate PHP static analysis tools:
> HHVM & Hack solved two big problems that made PHP difficult for Facebook and other large companies with large existing PHP codebases: Speed, and the lack of type checking
At what point do you stop using the hammer to put in a screw and just use a screwdriver?
Right, but you're still investing time in doing that switch. No matter which way you cut it, you're still replacing every single nail.
"We'll just update as we go", you say. That's fine, but it means that some parts of the house – normally the oldest and most integral to the entire structure - will use nails for years to come. And your developers will need to be trained in both hammers and screwdrivers to be able to work on the house in totality.
Sure, but if those nails are also causing structural instability, then it might be prudent to do the investment. It seems now, no one will be using your type of nail anymore either, so now you have to have them custom made at expense.
Sometimes those nails are doing just the opposite, they're holding the foundation together, and if you try and pull them all out the whole thing might collapse.
This is why I use Krazy Glue for everything, so I don't have to think about what's the nail, the screw and the hammer in this long-winded analogy about PHP and its shortcomings.
This is fascinating. It's a well-written post and their plan makes sense to me, but I imagine there's a tough choice ahead for framework authors (the Laravels and Drupals of the world) about whether they want to fork their communities, stay with PHP7, or try to target both with the same codebase (in the near term or long term)?
At any rate at least the fact that the HHVM folks are communicating the strategy effectively and transparently should help everyone involved make reasonable decisions.
If I still were a Drupal core developer (and I was the #1 core contributor for 5, 6 and #4 for 7 and still #10 for 8 though I regret that) I would tell you there's no tough choice here, I would target PHP 7.x and forget the rest. Currently, others steers the core and they struggle mightily with just the transition to PHP 7.0 requirement. Check the issue queue. I filed https://www.drupal.org/node/2605226 in 2015 fall but it was voted down, the current open issue is https://www.drupal.org/node/2842431
Exactly like React - means the language will be abandoned by wider community. The Facebook peeps are gradually building themselves into corporate self-invented mono-culture.
I'd like to see any concrete numbers on this. I'm seeing React getting stronger and stronger in my area, and patent worries are mostly accepted as crazy hypotheticals.
Wordpress are just starting what could easily be a multi-year rewrite as a result and Drupal has specifically excluded React from evaluation - both on the basis of the patent issues
True, but PHP development has always been split from the rest of the web-dev community.
React has managed to bring together people in C#, Python, Ruby, and Erlang to name a few languages... who all previously used different frameworks, or just jQuery.
Yes, it is clearly in wordpress' best interests to spend all that time and money to preserve their very important right to sue facebook for violating wordpress' software patents in the future.
So would I. But patents scare people, and rightly so.
This is a multi horse race and even if you are not scared of patents it might be unwise to bet on the horse you think will scare other people. (Case in point, Wordpress.)
I have met very few people personally who are turned off by the patents thing. The only valid concern would be if your company has (or might have) patents which they might sue Facebook over. More interesting companies could conflict with this, but clearly many React users don't have a problem.
Thanks; we don't feel that the framework authors have to make a choice here:
- short-term, those of us working on HHVM - not the frameworks - need to make sure that HHVM can run the frameworks that Hack developers require
- long-term, we expect Hack and HHVM to continue to diverge from PHP; it's unlikely that targeting both HHVM and PHP will be a practical long-term strategy
Laravel dropped HHVM support a year ago, and i'm sure many other CMS's / frameworks have either followed suit (if they ever supported it) or will soon.
How is Hack? Has anyone built anything with it and would like to share their thoughts? How's the HHVM community?
I've always thought that PHP was an underrated language that got a bad rep due to whacky design choices and PHP developers being seen as "less skilled" (a stereotype I know, but it is prominent) than others. Object Oriented PHP and frameworks like Laravel were a nice change of pace in my opinion, and there's plenty of good PHP coders out there if they had the right experience and stuck to a good coding guideline.
Alas, I confess I stepped away from PHP due the stereotypes against it, but HHVM always seemed promising. I haven't heard much about it over the years though.
I'm chief architect at Slack, and we migrated to Hack from PHP 5 throughout 2016.
The toolchain for HHVM is all installed as a single big deliverable, which gives you the language engine and supporting runtime libraries itself, an in-address-space web server (Facebook's Proxygen), a debugger in the form of hhvm -a, and the Hacklang toolchain accessed via hh_client and appropriate editor/IDE integrations.
I share your intuition that there is actually a glittering core of "stuff-that-makes-you-successful" hiding in the incidental complexity of PHP, and we wrote this blog post trying to put some substance behind that intuition: https://slack.engineering/taking-php-seriously-cf7a60065329
I have essentially created a private facebook that has no friends, yet the same person continues to show up as the first person in the pymk, javascript in the HTTPWATCH that I downloaded.. why is that? I already removed them from the suggested friends when it was pulled up - but every single time they have pulled up as the very first after my ID in the code. If I were to send you the code privately could you explain it to me??
Wouldn't it make more sense to take the parts of the PHP runtime environment that enable rapid prototyping and figure out how to implement them in a language that has a working == operator rather than trying to graft type safety on a language that has both strpos() and str_rot13()?
Remember BML, bradfitz' attempt to do this with Perl?
I would love to see someone do something similar for Python.
== has always been working in PHP. I know maybe that optional type coercition trips up some noobs occasionally before they made any effort to learn the language (hint === doesn't coerce types for equality), but how low effort does a complaint have to be?
Type coercition is actually pretty cool when you're not really sure what the browser or client is about to http at you and you just want it to work. It's much better than crashing at runtime because '12' isn't a number. If you're input isn't sane, throw an exception or use a validation library.
Now if we're talking about a good type system that can be enforced at compile time like rust, Scala, etc. Sign me up. But if it's run time, it's run time, we gotta keep going.
I have worked on a somewhat large-ish backend that was built with Hack. In the end, we dropped it in favor of PHP7, due to all the small incompatibilities it had, and all the non-standard things we had to do to use it. With PHP7 the performance difference was negligible (our original reason for choosing it), and the type annotations of PHP7 were good enough for us.
With switching, we were also able to use phan[0] and other tools that helped us write better PHP code that were previously unusable due to Hack.
I'll leave the first part of your question for someone less close to the project.
For the toolchain, when using it: it's currently mostly the PHP toolchain (e.g. composer) with some additions:
- the typechecker: this is a fast (I usually get full results in well under a second) static analysis tool, fully integrated with Nuclide (our IDE), and with excellent support in VSCode via a third-party plugin. This is a massive improvement in developer experience, especially when refactoring. Usually the unit tests pass first try once I've fixed the problems that Hack finds.
- an autoloader that can handle any definition (e.g. functions, typedefs, constants), not just classes
- the built-in webserver isn't just for development - no need for fastcgi + apache etc, though that is supported
As for building/working on HHVM itself, it's basically modern C++ using CMake, and the Hack typechecker is OCaml.
I've worked on HyperPHP / HipHopPHP (HPHPc, known by a million different things in its lifespan) in the past doing a lot of documentation and edge case testing. I absolutely loved the compiler, turning PHP scripts into C++, and running it through its paces using ANN libraries. I have a lot of love for the project and was onboard very early in the lifecycle. I really, really miss it. I thought it was a great learning tool.
Anyway, it's proven that without competitors to Zend Engine, the PHP team simply doesn't care to pay much attention to performance. (Snide comments about performance from maintainers and internal PHP contributors can be found all over the Internet to prove this point.) I am afraid this will continue as HHVM splits from PHP and moves more towards a JVM-type future.
Hack will be the "serious" language while PHP7 will serve a solid niche, and one I'm continually proud to support and use in production.
Nuclide works well enough with Hack and the typechecker is really solid.
I'm excited to see the future of both projects, but again, it is important to note that HPHPc by Facebook pushed PHP's project team into caring about a lot of this stuff over the years. I hope it doesn't take that kind of disruption to continue development, as I think PHP is in a really good spot now and don't want it to stagnate.
Laravel is probably not the best example in terms of improving PHP landscape in terms of code/architecture quality: Symfony is way more prominent in that. It's not a case that Laravel is using many components from Symfony.
it is weird for me why Laravel is so popular now given that as far as I've read documentation, a lot of it is written in static class calls, which is opposite of OOP and all good pratices coming with OOP.. I understand that it's kind of rails and gives short-term productivity, but if you have complex project, it will become an issue if majority of project code is spaghetti code without DI, IoC and so on.
Everyone else answered your questions/misconceptions about Laravel, but Laravel owes a lot of its popularity to Laravel Forge [0] and the tooling around deployment and code management. It is a tremendous tool.
Here's the interesting thing about all this; HHVM will always be developed because it's important to Facebook's bottom line and Open Source because it only benefits them to keep it out there and have other people testing it and improving on it.
Now that they're getting rid of direct PHP support, HHVM is only going to get better. This will unlock a whole host of language improvements that HHVM couldn't otherwise make.
HHVM is faster relative to PHP now, and it will only get faster with these changes. Typing is an important part of making JITed code fast and unless PHP ever decides to fully add it, it will never have the potential to catch up. This is important to PHP-based companies as they grow and want to optimize on cost and development efficiency.
Undoubtedly, this split will be painful initially for those of us who are bought into the symbiosis of the HHVM and PHP ecosystem together. How painful it is to split will just be a question of where members of the PHP community want to go (or both). The nice thing is that converting something from PHP to HHVM isn't terribly hard; not anywhere near like converting from PHP to Golang. For HHVM, it's mostly just adding type annotations.
While this is probably still true[1], it's certainly less of a concern now than it was with 5.x. Would (often negligible) performance boosts be enough for someone with a 5.x PHP codebase to choose Hack over PHP 7.x? I can't see that for most cases.
PHP is IMHO the most productive and easiest platform for web development:
- a request
- a response
- templating
- no shared stated
And that's it! But the language syntax has so many quirks. So it's cool if Hack redesign the language and make it more beautiful and consistent. Many developers switch to Ruby or Python because these languages are better designed. I think Hack could attract a lot of these developers who want more beauty in the tools they use.
Flask is really good (and my preferred web framework, and full disclosure, I have forgotten how to write PHP), but it fails very badly at "no shared state," and depending on what GP meant by "a request" / "a response", it fails at that too. A Flask process handles an indefinite number of requests and responses; the built-in server handles them serially, and doing otherwise brings in either threads (and shared state) or multiple processes.
I have worked with Python/Flask, and I even built my own micro-framework on top of Ruby/Rack. It was nice, but I am far more productive with PHP, the workflow feels more natural than a cgi-like stack.
>>Have a look at Python & Flask! There is nothing easier than that!
What? PHP is significantly easier to roll out for your beginner/intermediate junior developer on a VPS. There isn't any comparison.
This comes from someone who leans on Python hard for ML work / scraping / signal processing (what it was born to do) and PHP for web development (what IT was born to do).
I am way less sad about HHVM now (specially after React license debacle). I think Facebook now has opportunity to think about this fork as a fresh take on PHP and maybe make the language awesome both from syntax/performance perspective. I don't think living with a weird hybrid with current language landscape is an option.
Sad. Facebooks involvement by utilizing PHP and pushing the language by extending it was a good sign for the PHP community. Would have loved to see that they align with PHP7 or even further, push their engineers into improving PHP itself. PHP has such a huge ecosystem. I wouldn't risk to bet on Hacks future.
> Eliminating references. PHP references have unusual semantics, where the function specifies the binding of parameters with no indication at the callsite.
> This is interesting because they’re changing the definition of the language through a sort of back-channel. They’re allowing breaking changes by effectively deciding that other implementation choices are equally valid.
> I’ll give you an example, which I’ll get into more below. There’s a little known bug in the Zend engine around copying arrays that contain references. IBM wrote a paper about this bug in 2009. Basically, this bug was necessary in Zend to make copying arrays fast, and IBM figured out a way to do it in a way that was actually correct, for only a 10% performance penalty.
I get why they want to get rid of references. If I would be designing PHP from scratch, that's probably the first thing I'd do - most hard to fix bugs in the engine and most security woes of features such as unserialize() stem from references. Unfortunately, TONS of code uses them, and there are some data structure things that would not work without it unless alternative solution is provided. So it could not happen in PHP. But it'd be interesting to see how it works for Hack.
we're currently leaning towards out/inout parameters, with copy semantics, not byref (and in most cases, we'll probably be able to optimize away the copy); not certain yet though.
MediaWiki runs on more than 25k websites [1] other than Wikipedia, so I don't see them switching to Hack only.
Also, I run a pretty big MediaWiki site and the last time I tried moving everything to HHVM (~6 months ago, I think) stuff appeared to be working initially but randomly broke from time to time (probably because of Scribunto or some other extension; couldn't manage to pinpoint the exact reason). PHP 7 didn't give me any problem at all; it's fast enough (way faster than PHP 5) and most pages are served by the Redis cache anyway. I suspect that Wikipedia will consider a move back to PHP, they're moving the most expensive logic to Lua modules anyway...
I think HHVM was equivalent to what jQuery was to JavaScript. jQuery forced JavaScript to be better, and the better JavaScript becomes, the less jQuery is needed.
So if we get to a point where HHVM is completely irrelevant, it simply means "Mission Accomplished".
In terms of language, jQuery didn't innovate in anything though. It was a great framework mind you, but there's nothing special about it that influenced the choices in design for the more recent versions of JS.
I think querySelector and querySelectorAll are simply more generic versions of the traditional approach of using getElementById and getElementsByTagName, but it's possible that the greater versatility of $ influenced the later design of querySelector, indeed. Then again, it was not a jab at jQuery, which proved to be a fantastic tool for a decade in the field of web development.
MediaWiki doesn't use Hack. Wikimedia Foundation servers (which run Wikipedias and other sites) do use HHVM, but the code is 100% PHP-compatible and still runs fine on standard PHP.
Well, this is disappointing. I really like Hack and I was hoping it would take off, but judging from this thread it seems unlikely the language is going anywhere worth following. I guess it's lucky that I only have one project written in it...that I now have to convert back to PHP.
I'm really going to miss XHP. Native XML support has ruined me for templating frameworks. I never want to write HTML as concatenated strings ever again.
PHP does have a history of making this more explicit, given its origins as a templating language. If you go down far enough, isn't all HTML rendering string concatenation? There are plenty of libraries that handle this in many languages, including PHP.
I'm just annoyed that PHP doesn't handle HTML tags natively as their own distinct entities. Not having to quote HTML as strings or switch into and out the rendering context with PHP tags makes templates a lot easier to reason about and cleaner. With that, you can natively get features like auto-escaping, HTML tag validation, extending or creating custom tags, template inheretance, all of which you can do in PHP but only if you include the overhead of a framework.
> I'm just annoyed that PHP doesn't handle HTML tags natively as their own distinct entities.
I'm interested in things like this as well. Can you provide an example of what you're thinking of? Something like JSX? Other data structures that are transformed into HTML by a library? The latter seems to be counter to your argument about requiring the use of some framework or library, but I can't think of any alternatives off the top of my head.
XHP templates in Hack do wind up looking a lot like JSX (which is probably not coincidental).. Each tag is a class with a render function that returns an XML node. Here is an example base document template[0] showing what that looks like. Obviously, PHP templates can accomplish the same thing, it just takes more work and more dependencies to magic away the noise.
But with XML as a native data structure you can do things like typehint a tag:
public function setTitle(:document:base $base, string $title): void
{
$base->setAttribute("pagetitle", $title);
}
I've used Twig, which seems pretty comparable to similar products in other ecosystems, but there are several alternatives. So, to answer your question, yes.
No, my only issue is that PHP doesn't let you just echo the HTML directly, because despite being designed for generating HTML, the language doesn't actually know what it is.
Raw PHP is far from its roots as a templating tool and is a full featured programming language. I don't really see any reason why you'd want to use it for templates.
It's not that far. PHP is much better as a language than it used to be, but it's still a hypertext preprocessor (they can retcon the acronym but the language is still designed around taking requests and sending responses), and templating is still almost exclusively what it's used for, because that's what it's best at.
That's... what I just said almost everyone is doing with PHP, that and not much else. Those templates are what the "Hypertext Preprocessor" part of PHP is about.
OK, let me be clearer then. If PHP itself is just being used as a templating language, where does the demand for multiple templating engines implemented in PHP, and intended for use in PHP projects, with their own non-PHP syntax, such as Twig, come from?
Those engines provide features that PHP natively lacks, or doesn't support well. With raw PHP, you have to manually escape every variable with htmlspecialchars, or mix HTML and PHP contexts in a way that can make it difficult to reason about complex templates, (see: Wordpress) or separate concerns (anyone editing templates now has to know how to write PHP, because templates are just PHP.)
A template engine can give you context-sensitive escaping, template caching and inheritance, macros, and other features that increasingly become necessary for modern web development, and many of which you would probably wind up implementing anyway, once a project reaches sufficient scale and complexity. While raw PHP is arguably faster, it's also more difficult to do properly.
Also, culturally, the PHP community isn't as centralized as other web development language communities seem to be. It doesn't have one 'correct' framework or one 'correct' templating language you're expected to use, so there is competition between multiple engines.
But the end result is still the same in either case, basic CRUD - taking an HTTP request, getting some data, pushing it into a template, and sending a response back.
Well, yes, exactly, that's why I recommended them, and then I get the objection that they eventually are generating strings. I don't really get it.
> But the end result is still the same in either case, basic CRUD - taking an HTTP request, getting some data, pushing it into a template, and sending a response back.
Sure, that's what most PHP apps do... but it's also what most Rails, ASP.NET MVC/WebAPI, Spring, etc. apps do too. And it involves a fair bit more than templating -- database access, data validation, security, etc.
It's true that PHP is rarely used off the Web (although it's possible), but I can't see how what you're describing makes PHP different from any other technology commonly used for Web dev.
PHP is designed around handling HTTP requests and responses, so it already comes with a lot of the functionality you would need to import into other languages. Whether or not that's an advantage or a hindrance is in the eye of the beholder.
I don't think I would want to use just plain PHP and it seems like the frameworks that are popular nowadays kind of abstract over all that stuff anyway. In practice I don't think it makes much of a difference.
We're moving towards functions_like_this(), instanceAndStaticMethodsLikeThis(), and async functions like foo_async() and methods like fooAsync(). We're unlikely to change the PHP builtins, but we're fairly likely to build replacements - for example, Hack Arrays are best used with https://github.com/hhvm/hsl instead of the PHP array functions, and this also provides replacements for common string operations that are consistent and fit well with the Hack type system (e.g. nullable or throw an exception instead of falseable).
For return values, I'm not sure exactly what you mean - could you give a full example? If I take your example verbatim, it's a syntax error in both Hack and PHP - if I go for "5"*10, it's a Hack error (https://gist.github.com/fredemmott/90c5f8eca17d1d4e1204f0085...)
If you don't plan to support PHP5 anymore and HHVM is not targeted at PHP7 ... then my ask is to just make a better language and drop ALL of PHP baggage.
When you say:
We're unlikely to change the PHP builtins
That concerns me. Because why even break support from PHP7 if you don't plan to change (fix) the builtins?
As fredemmott said above, we're hoping to build replacements for the various PHP builtins that we want to be a core part of Hack. I think that replacing the functionality provided by PHP builtins will be a less confusing transition experience than retrofitting them with modified behaviors would.
Once we do have a compelling and comprehensive Hack Standard Library, I wouldn't be surprised if we dropped PHP builtins in favor of that.
> my ask is to just make a better language and drop ALL of PHP baggage.
Long-term, we hope to make pure-hack projects more practical, and we're aiming to make Hack the best web development language. This will take time - both to decide what parts of PHP we want to keep (it definitely does have excellent parts), and how we want to change the things we think need improvement.
> Because why even break support from PHP7 if you don't plan to change (fix) the builtins?
Sorry, I was unclear: changing the behavior of the PHP builtins will break BC with PHP, and the result would still not be what we want for hack. We're likely to build Hack-only replacements for the PHP builtins, instead of changing the behavior of them.
Maybe because there will be replacements instead? I guess that changing behavior (and type signatures) of builtins is not backward compatible with projects that want to use Hack. This way they will be able to migrate at their own pace.
I hope the previous post was a joke, because it felt like one.
Edit: "We're moving towards functions_like_this(), instanceAndStaticMethodsLikeThis(), and async functions like foo_async() and methods like fooAsync()." C'mon. That doesn't sound like much improvement compared to the original PHP.
I tried out Hacklang a bit and I really enjoyed it. However I could not get xdebug or any type of debugging to work with it. Also the lack of an editor on the calibre of PHPStorm (atom is not great at all) made me give up. I am just hoping for PHP7 to move in the right direction.
What are the best framework for web dev on top of hack/hhvm? Last time I used PHP I was using yii (yes-it-is). Wondering what framework can someone use today if she has to start from scratch on hack.
If HHVM(Hack) will drop all the inconsistencies and weirdness of PHP in their implementation the better since it's no longer be compatible with PHP anyway.
That's the plan. Break the old nonsense, like the one they mentioned: refs and refcount. Everybody should switch to Hack, it's a much better and safer language.
There are plenty of places where you can view arguments for and against PHP alone and in comparison to Python and Ruby on the internet. This submission is specifically about HHVM. Asking people to justify the use of PHP in such a context is just inviting a language flame war. Please don't.
Faster than Python and Ruby.
PHP7 is actually a better OOP language than Python is.
PHP is much easier to get started in and find "talent" for, tons of PHP developers out there.
A lot of money has been made with PHP, the only reason many companies switched from PHP is that the developers wanted to "feel grown up" and switched to something else.
I wonder why they just don't deprecate HHVM altogether and maybe create a HACK version on top of GraalVM. This would probably be way more performant and probably might be better for integration into other systems.
I think that these changes mean the death knell for PHP in any version, for small companies. There is still a place for Hack or PHP7 in very large operations, but startups, and businesses that run at smaller scale, really should walk away from PHP entirely as soon as possible.
Two reasonable directions to choose are Python Three with a framework like Flask (lighweight) or Django (heavy duty). Or go to the JVM with something like Grails framework (heavy duty) on the Groovy language. Ratpack is a lightweight framework for Groovy and there is also an interesting option to use Vaadin 8 which lets you put your GUI code into the main app rather than writing separate Javascript code.
When making your decision, be sure to consider the huge JVM ecosystem that integrates quite easily with Groovy including development tools like Jenkins and SOAPUI that can be scripted with Groovy. And the Python side also has a fairly extensive ecosystem of libraries as well.
The skill level of Python and Java/Groovy developers tends to be higher than PHP which has always attracted people who would learn just enought to get by.
The software dev community has gone through an explosion of diversity in the past 2 decades and that has enabled a lot of experimentation with new ways of doing this. There is a lot of good in this. But now we are in a period of contraction. Some of this is manifested in the spread of functional capabilities via libraries such as reactive extensions and functional features being added to languages like Java and Javascript. Another manifestation is the fading of PERL from prominence, and this is now happening to PHP as well as Ruby.
This is evolution. Embrace it or face your personal extinction as a software developer.
> This is evolution. Embrace it or face your personal extinction as a software developer.
Woah there Mr Hyperbole.
The reason PHP is still in use, and not dead or dying, is that it's one of the simplest languages to write server-side code in.
That means it's remarkably easy to hack something together quickly, with no compilation step to get in the way.
Unless that changes in a drastic fashion, projects will continue to get started in PHP, and PHP's user base will continue to grow, and (hopefully) the language will continue to improve to accommodate that growth.
If you believe this, then you are very bad at predicting the future. I'm very bad at that too. But I can assure you, "better languages" don't win the war. PHP has a lot of software out there and what's going to have it leading HHVM. You will have the "cutting edge" folks give HHVM a shot, but all the practical folks don't care. The only way HHVM will have a chance will be to be 100% backwards compatible.
> go to the JVM with something like Grails framework
No-one's upgrading from Grails version 2 to version 3, or starting new projects in it any more.
Apache Groovy's good for scripting on the JVM -- just don't build any systems with it. Systems on the JVM should be built in languages that were statically typed from the ground up, like Java, Kotlin and Scala. Static typing was grafted on to Groovy in version 2, and not used very much, hence no-one's sure about its quality. Best use Groovy for glue code and build scripts only, which was its original purpose back in 2003.
> The skill level of Python and Java/Groovy developers tends to be higher than PHP
Now this is starting to look like an advert for Groovy, assuming all Java programmers also use Groovy, and associating it with Python in contrast to PHP.
Bottom line is people will need websites and most people want to develop them in a way that is easy. You are talking all these languages that are overkill for websites and patterns that most web developers wont even use. Functional programming, really in web dev? If you start thinking like that then before you figure out the latest and greatest design pattern you will end up using someone in wordpress has finished the website. Companies are in the product shipping business, not the hipster coding business.
No offense but python is being eaten alive by nodejs, golang, crystal, OCaml, Julia, R, matlab etc. and Java is being eaten alive by kotlin, swift, etc.. I mean you're basically wrong about everything and making totally arbitrary baseless claims.
I mean, it's great that Hack will work for new Hack code and existing Hack codebases, but there aren't a lot of those. It makes sense for Facebook — why waste your efforts on maintaining part of your runtime that you don't need? — but I wonder if this will consign HHVM to irrelevance in the long term. Maybe Hack is a compelling platform for new code, but then, why use this obscure proprietary Facebook thing that's a bit better than PHP when you could use any of the numerous other languages out there that are also better than PHP but have much better ecosystems?
Personally this makes me sad because I wanted to see a standardised, multiple-implementation PHP language. Facebook did, even. They paid someone to write a spec: https://github.com/php/php-langspec
Maybe someone will write a new PHP implementation to take that idea forward. Or maybe we'll be stuck with Zend forever.
The future is strange.