I think the most likely outcome is that PHP will adopt some of HHVM's additional features, but remain a separate project. IMO that's a great outcome, since we'll both likely drive the other to be better.
Do you think Hack is a good language to start a new project in, compared to non-PHP languages? Are you using Hack for things besides the main web page?
Yeah, I think Hack is a good language to start a new project in. For as much flak as PHP gets, there are actually a lot of good things about the language. The fast development cycle -- edit php script, refresh -- is something amazing that you don't get in a lot of statically typed languages, which usually have a compilation step. The crazy dynamic things you can do also occasionally have their place, though it's certainly easy to shoot yourself in the foot.
On the other hand, a lot of the time you want the safety that strong static typing can give you. Even just the null propagation checking can immediately find tons and tons of silly little bugs without even running the code, and ensure that the code stays consistent as a "mini unit test" if you will.
Hack hits the sweet spot of both. Wiring the Hack typechecker into vim was really revolutionary for me -- having both the immediate feedback of the type system for all the silly bugs that I was writing, along with the fast reload/test cycle from PHP, is great.
How extensively is Facebook using Hack at this point? Is it in production?
What has been the biggest learning/unlearning you've needed to do going from PHP to Hack?
The biggest learning step for our engineering teams was to treat type errors from Hack as actual logic errors. We have a collection of "linters" that provide advice on code style and other nice-to-have factors. Some people (quite reasonably) initially thought of Hack errors as lint-like stuff that it was safe to ignore, when in fact they indicate real logical inconsistencies in code.
A question about the type inference mechanism: in PHP, while it is possible to define object interfaces which classes may be defined against, by the dynamic nature of the language, functions don't necessarily need that interface specification to accept an object conforming to it, explicitely or implicitely. OCaml provides something "similar" with its object system, but much more powerful with static inference of an object (super)type from its usage. will Hack be able to infer an object interface as well from its usage in a function?
It would be pretty much impossible to implement total type-inference without loosing separate compilation in Hack. PHP projects are not organized around a module system, which means that you have "spaghetti" dependencies, and even better, cyclic dependencies all over the place.
So trying to implement total type-inference would be a bad idea, you would not be able to separate the code in independent entities and the checker would not scale.
2) Does Hack support structural sub-typing? Answer: No, but not for obvious reasons.
Fun fact, the first version of the type-checker was implementing structural sub-typing. And it was not scaling, for subtle reasons.
Hack allows covariant return types, so if we implemented structural sub-typing we would have to "dive" into the return types of each method to see if they are compatible. But in turn, these objects could have covariant return types etc ... The process of checking that was too inefficient. Caching is a bad idea (or at least a non trivial idea to implement), because of constraints and type-variables.
Since disallowing covariant return types was not an option (it was crucial to make a lot of code work), we had to kill structural sub-typing.
I hope this answers your question. As a big OCaml fan myself, I like the features you just mentioned (Well, Hack is written in OCaml), but they really didn't seem to be a good fit due to the nature of the language and the kind of checking speed we were shooting for.
We don't do any type inference across function boundaries, so we largely dodge the issue that I think you are getting at. (Please elaborate if I misunderstand!) We rely on interface and class definitions in order to know what methods are available, and even though the runtime resolves everything at runtime so you can call any method that happens to exist at that time ("duck typing"), we enforce statically that methods do exist where we can. So for example, the following code will work at runtime since the method `g` does exist, our static typechecker will reject it since it does not exist on type `I`.
<?hh // strict
interface I { public function f(): void; }
class C implements I {
public function f(): void {}
public function g(): void {}
}
function f(I $i): void {
$i->g();
}
f(new C());What's your motivation, aside from modernizing Facebook's code base? What language niche does Hack serve which is not served by other languages? Why Facebook at all (aside from the rarity of finding a company to pay you to write a compiler :))?
This lets you choose the pace and extent to which you want to adopt the safety of static typing, while preserving your dynamically typed code -- and without sacrificing the rapid turnaround of PHP.
That's a unique combination, in my experience.
Would you consider adding even more expressive features like algebraic types or hygienic macros to the language?
Also how likely do you think it is that typical PHP will eventually be overtaken by HHVM? I'm hoping it will!
public string $x = '';
instead of
public $x:string = '';
It seems inconsistent to me, probably because I've used AS3/Haxe.
function foobar() : int { .. }
function int foobar() { .. }Property types are declared before the property name, while function return types are declared after (and with a colon).
Very strange.
Do you expect Hack to be stable without large breaking changes going forward?
The documentation doesn't say much about the scheduling for asynchronous tasks. Can async functions be used to batch requests to e.g. caches and databases? Can Awaitable be used to interface with code that expects chainable Future or Promise-style interfaces?
Can HHVM/Hack use standard PHP extensions, or how much work is it to port an extension?
Is there a Hack plugin for IntelliJ?
Does the Hack project have a mailing list or forum?
Our internal plumbing is different, so the extension APIs aren't the same, thus PHP extensions can't normally be used with HHVM. Paul has a source-compatability transformer which works for simple extensions (no fancy stuff allowed), but we recommend anyone with an extension consider porting the code.
If your extension is one of those "This was written in PHP but we wanted it to be faster so we turned it into C" types, you should consider going back to PHP for it. In practice, we find that HHVM can JIT PHP code into running about as fast as (sometimes faster than) C/C++ extension code.
If you do need to dip into C/C++ (because you're calling an external library), the API we've designed is a LOT easier to work with than PHP's. And I say that with the authority of having written THE book on writing PHP extensions: http://amazon.com/dp/067232704X .
I'm working on proper documentation for extensions as we speak, but for now you can find some very basic info at https://github.com/facebook/hhvm/wiki/Extension-API .
(I'm not a php developer so excuse my ignorance)
It seems you only have 1 method 'await', to check if the async function has completed its job (it self, if I'm understanding is a blocking operation in which ever thread/worker its called).
So is there a way to run something more similar to
$i = 1;
while(doingSomeThing)
{
$b = "";
if(completed gen_foo())
{
$b += await gen_foo();
do_critical_task($b);
}
else
{
do_something(do_item[i]);
}
$i++;
}
gen_foo(get_user_data); //async
$x = do_something_for_a_while(); //do something while gen foo processes
do_new_thing($x, await gen_foo()); //do something with rendezvous result
Again if I'm completely off the mark please let me know.
The way it works is quite different from your example:
async function gen_foo(): Awaitable<string> {
echo "until we get to an await, eager execution\n";
// ...
await gen_bar();
// this code is only executed after await
return 'result';
}
$x = gen_foo(); // x is a handle, suspended at the point of its first 'await'
await $x; // ... and now it's resumed
list($x, $y, $z) = await genva(
gen_foo(),
gen_bar(),
gen_baz();
); // genva creates a wait handle for awaiting its args
// ... and when we get here $x, $y, and $z are all assignedCan I embed it? Or extend it via compiled binaries written in C/C++?
As the author of pretty much THE book on writing PHP Extensions ( http://amazon.com/dp/067232704X ), I can say with a fair bit of authority that writing HHVM extensions is SO SO SO much easier.
Are you planning a Windows build ?
do you think Hack could replace all PHP stacks (PHP cloud stacks , not talking about shared host wordpress toys) in a 5 years time frame ?
What do you think about the current state of PHP?
what would you tell PHP core devs about that?
Does an async frameworks like React runs with Hack?
What can you answer to people that are concerned that it is Facebook who is developping this?
Yes. auroraeosrose is working on it (the same person who did the port for php) https://github.com/auroraeosrose/hhvm/tree/win32_start
[1] - http://hacklang.org/manual/en/hack.annotations.summary.php
It's complicated.
If you use partial mode, which doesn't enforce that every function is fully typed, then it's trivial to break the type system by just using an untyped function. In order to ease conversion, we just assume the programmer knows what they are doing with untyped functions and let anything pass.
If all of your code is in strict mode, then we believe the type system to be sound. We haven't done any formal proof of this of course, and there have been plenty of bugs in the past. But that's the goal.
Some types are enforced at runtime -- just like PHP5 enforces class type annotations on parameters. However, at least for now, the runtime doesn't do a lot of the clever things with the type system that the static typechecker does. It's much more conservative with using the type information, and doesn't do things like check generics at all. (At least right now! We probably will change this in the future.) This means that we can play a little more fast and loose with the type system in the static parts; we want it to be sound, but it doesn't have to be right now; it's not going to cause a JIT crash or anything.
There are more details on the modes here: http://hacklang.org/manual/en/hack.modes.php
How do you protect from type errors when a value crosses from the untyped to typed fragment? Do you use contracts?
We don't (statically) protect against type errors when you cross from untyped into typed code. If you call an untyped function, we assume the programmer knows what they are doing -- just like PHP does. You might get a runtime exception if you are calling a method on null, for example.
This is actually a pretty important part of the conversion process. You don't have to convert all your code all at once. Typed code can be verified statically; untyped code is assumed to work just as before.
Parameter and return type annotations are enforced at runtime by HHVM (just like you can add a class type annotations to a parameter in PHP). This will protect against some inconsistencies -- again, just as if you weren't using Hack.
https://raw.github.com/strangeloop/StrangeLoop2013/master/sl...
The idea of bolting a static checker onto a dynamic language and using an unresolved top type to make it work is cool. The presentation refers to your system as SoA gradual typing. Are there any papers or presentations which explain that approach and how it works in more detail? Particularly in how it might differ from gradual typing?
Adding lambdas makes PHP more Ruby-like and generics and type checking are straight out of Java. I'm still unconvinced in how this makes programming websites more efficient or bug-free than existing languages. Can you please elaborate on that?
In the mean time, the open source release of Hack includes integration with both Emacs and Vim.
I program in php every day and miss static typing (as opt-in mechanism). Sadly i'm on windows and use oracle, so hhvm is not applicable.
I have wondered why FB didn't use a proper language with proper typing to begin with. I mean, I "understand" logistically: they already had a giant codebase in PHP, migrating a codebase is expensive, and it's difficult to hire and train 1000s of hackers in e.g., OCaml. (They do have some OCaml people, but they are outliers. OCaml was my favorite thing to write there, though it didn't afford some of the same niceties and interactivity as the PHP code they had, only because the support was down by several orders of magnitude.)
But at the same time, layering FP with a home rolled static type checking server (??) is bug prone and is certainly yak shaving (which they have time and money to do). Now they've written (1) a compiler to C++, (2) a compiler to VM byte code, (3) a corresponding runtime for each, (4) extensions to PHP, (5) a type checker, and (6) an inference engine. That's a lot of stuff. And in the end, it's still PHP, which is duly disliked. (Though Facebookers don't seem to care. The prevalent attitude toward it is that "PHP, as it's coded here, is mostly like C++, and that's OK.")
Writing correct type checkers and inference engines is kind of difficult. They seemed to take the approach of just building onto it incrementally until it just seems to work. That approach led to many bugs in many cases that just simply aren't thought of when one is trying to build inference engines by hand, as opposed according to theory. Type checking and inference is an area ripe with theory and attached formal, mathematical semantics. Standard ML's standard is perhaps the most infamous; it's a collection of mathematical statements about the language. That way, the compiler is now almost an engine to prove your code is correct. I don't see how the same guarantee can be made with something that is just cobbled together.
Because perfect is not the enemy of the good? Because "build atop a crumbling foundation" has demonstrated time and again to be, by far, the most successful way to accomplish anything in computing? Unless you have some example of perfect, now dominant, technologies that have been created ex nihilo that I'm missing? I mean we (facebook) are still using PHP and MySql, improving both. And when we need to break things out, we head into C++, the queen mother of castles on broken foundations.
> But at the same time, layering FP with a home rolled static type checking server (??) is bug prone and is certainly yak shaving (which they have time and money to do). Now they've written (1) a compiler to C++, (2) a compiler to VM byte code, (3) a corresponding runtime for each, (4) extensions to PHP, (5) a type checker, and (6) an inference engine. That's a lot of stuff.
All languages, runtimes, and standard libraries (and databases, and source control, and on and on) are "broken" at sufficient scale. You're going to be spending time rebuilding things other people take for granted no matter who you are and what language and technology you are working in. The underlying assumption that a "proper language" gives you these things for free is completely false.
> Writing correct type checkers and inference engines is kind of difficult.
Just so we are clear, you ask why Facebook didn't rewrite 10,000 human-years of code into a mythical unnamed "proper" language, but you consider writing a type checker to be "difficult". I think you might have vastly inaccurate pictures of what is and isn't "difficult".
> That way, the compiler is now almost an engine to prove your code is correct. I don't see how the same guarantee can be made with something that is just cobbled together.
Computing history is littered with dead projects from people who believed that anything less than perfect is unworkable or non-valuable.
I can't imagine where that sort of conclusion comes from. Building on a crumbling foundation seems to be just about the most proven, reliable way to ensure your software project won't survive more than a short time without needing serious effort just to maintain it and/or a big rewrite.
Much of the world still runs on C, a language that was created long before many of us here were born. Other languages have risen, peaked, and fallen into relative obscurity since then, yet C endures, because for all its faults, it is simple and predictable, the epitome of a sound foundation.
Large amounts of COBOL is still driving back office systems in large organisations. The cost of hiring people with the skills to maintain them is probably horrific, but those systems are still there, doing their jobs decades later.
You can still run applications from nearly 20 years ago on Windows today, in no small part because of Microsoft's persistent focus on compatibility and keeping the basics reliable over that time. Similar stories can be told in *nix world.
What major accomplishments in computing that have been built atop crumbling foundations can claim anything even close to the scale of success of these examples? You surely can't be talking about the move fast and break stuff philosophy that seems to drive everything at trendy software shops like Facebook and Google, or the kind of MVP/lean start-up hype we hear about ad nauseam on HN and the lasts-just-long-enough-to-exit web apps that result.
The opposite opinion is basically indefensible. Sure, you can still dig a trench with a spoon (and if you have enough money to wield a bunch of workers with a spoon), even if a shovel would do a better job.
Let's begin.
1) PHP autocraptastically converts strings that look like numbers, into numbers, resulting in all sorts of weirdness like this: https://eval.in/111886
2) PHP 5.4's OWN TEST SUITE has 91 failures and only 70% coverage. There is NOTHING more "WTF" than that! Why even bother having a test suite?? http://gcov.php.net/viewer.php?version=PHP_5_4
3) Why the fuck are all of these different things equal, and how does this NOT result in problems? http://i.imgur.com/pyDTn2i.png
4) String increment is dumb to begin with, but why does it not even match the behavior of string decrement? https://eval.in/60631
5) Why the hell can you jump back into a try block from a catch block? Recipe for disaster: http://phpmanualmasterpieces.tumblr.com/post/33091353115/the...
6) PHP comparison operators. I'm sorry, but this level of complexity might make you feel smart once you master all its idiotsyncrasies [sic], but it's actually dumb: http://stackoverflow.com/questions/15813490/php-type-jugglin...
That's a small fraction of not-thought-out PHP language features that result in REAL bugs and security holes. Which consume large swathes of programmer time. Which, apparently, Facebook can afford to swallow.
I'm sorry, but your position, as valiant as you are defending it, is literally indefensible. And I don't give a fuck how big Facebook is, they would STILL be better-served by switching SOME of their code to a different language. ANY modern programming language wouldn't suffer from this imbecilic, immature language design.
You don't need to rewrite anything (at least, not all at once.) Personally, I'd have expected you to make something akin to CoffeeScript or ClojureScript that targets PHP, and can "link with" your existing PHP modules (or rather, with their HHVM bytecode representations.) Then treat the PHP code as a constantly-dwindling Big Ball of Mud (http://laputan.org/mud/).
That's only because the currency for building things on top of crumbing foundations has been sweat and man-power. We aren't that far off from the Egyptians that were using hundreds of thousands of slaves per pyramid. It's a good thing that we've transcended the necessity for hundreds of thousands of slaves when raising buildings, don't you think?
And yet, here you are, claiming that building stuff with broken tools is the most successful way to accomplish anything in computing. Actually I view it as nothing short of a miracle, showing human determination in action ;-)
> All languages, runtimes, and standard libraries (and databases, and source control, and on and on) are "broken" at sufficient scale.
That's a fallacy. Just because both X and Y are broken, that doesn't mean they are equal, as some things are more broken than others and PHP is more broken than anything else mainstream (C++ at least has reasons). Also, I don't see how "at scale" changes things in PHP's favor, I really don't.
If you're trying to argue that "at scale" the level of brokenness converges to the same levels, then that's a stupid thing to say. After all, Twitter didn't had to build its own JVM and the stuff they run on top of the JVM is probably more power efficient than you'll ever be with HHVM. Probably saner too.
Facebook can keep PHP for the thin web layer that renders the page, but they could have migrate the meat of their code to a safer and more robust language.
a) try your new code by saving in your editor, and hitting reload in your web browser.
b) it's very approachable. People who only know HTML and CSS can be expected to do a little bit of PHP work to integrate their changes. If you setup the right network mounts, they just need to edit files and reload (see a)
c) it's not super high overhead at runtime. If you're not using a framework, and you don't build up a crazy object hierarchy, it's not too hard to get your page out with about 10 ms of overhead beyond data fetching. For very simple webservices (fetch data, possibly from multiple sources, and do a little formatting for the consumer), I was able to get the overhead down to 2ms. You can certainly do better with other languages, but you can usually get better throughput improvement by working on getting data quickly. Btw, all the frameworks are terrible; many of them add 100 ms to the page just for the privilege of loading the includes; PHP is a framework for web programming thank you very much.
d) cleanup; you don't have to worry about it. If you don't do anything weird (c extensions, with non-preferred malloc), at the end of the request, everything is thrown away.
That said, there are plenty of things PHP isn't good at: I wouldn't run a long running process in PHP; and multithreaded PHP sounds like a bad idea.
As for a), many (most?) frameworks are able to monitor the source files and reload the application when they change, in order to enable that workflow. For example: http://cherrypy.readthedocs.org/en/latest/refman/process/plu...
The only language for which that works is client-side Javascript. For PHP, you forgot the part in which you have to install and run a web server, then point your browser to localhost. Plus, to get anything useful done, you'll also need some sort of database to go along with it. I remember the first time I did that and it was pretty intimidating.
> c) it's not super high overhead at runtime ... it's not too hard to get your page out with about 10 ms of overhead beyond data fetching
To me much more interesting is the total time it took for the client to receive the response, possibly when multiple concurrent requests are happening. The comparison here should be versus a static page served by Nginx of course.
The best throughput possible that I got for an otherwise complex business logic happened on the JVM. I basically rewrote a web-service built on top of Django/Python, with a redesign with emphasis towards in-memory caching, parallelism and async I/O and the result was a server that was able to process more than 10,000 requests per second with an average of about 5ms per request (actually in production the instances ended up processing about 2000 reqs/sec of real traffic, since c1.medium EC2 instances don't have enough CPU power).
Of course, people that just need to slap something together, don't need this level of throughput. If a request takes 400ms for a dumb web form on a low traffic website, that's of no consequence to most people. The problem happens of course when such a piece of software evolves to something much bigger, like Wordpress. I'm always amazed at the gimmicks that people do just to keep their Wordpress powered blog alive.
It is a job scheduler which takes jobs from a Redis queue and executes it.
It does fork a new process for 1 type of task (image resizing in this case) to make sure it doesn't leak memory.
It also reuses these forked processes so it doesn't need to fork for every task.
It was last started on Jan. 2013 (because of maintenance) and still running fine.
The reason ? I didn't want to introduce an extra language for project for which all the server code was already written in PHP.
So if it fits the task, you can do it.
P.S. The vast majority of arguments against PHP here leads me to conclusion that most of (not all) debaters don't understand how PHP works well enough.
Is there anything about PHP, the language, that lends itself to this style of development, or could you get these same benefits with, say, Ruby or Python?
b) Theorem: Leting your web designers program is a way worse than letting your programmers do web design.
c) Every simple project can become complex at some point. Facebook certainly is.
> I have wondered why FB didn't use a proper language with proper typing to begin with.
I would suggest watching Keith Adams's talk, "Taking PHP Seriously": http://www.infoq.com/presentations/php-history
He goes through why Facebook uses PHP and decided to build upon it to create Hack. I highly recommend watching the whole thing, but the main three things he points to are:
1. Frictionless programmer workflow with a short feedback cycle
2. All PHP requests start out with the same consistent state by default
3. Rigid style of concurrency
1. I have never seen a framework that didn't go to great lengths to update to new changes quickly in development
2. Which means you lose resources between requests, unless you stuff them into the interpreter/httpd itself. And anyway this is only a problem for PHP, where by default everything runs in the top-level namespace, versus in separate functions.
3. That's a funny way to spin "no concurrency", but you can get that in any language by just not deploying it threaded.
The language definition and semantic checker are difficult, but are stereotypically tasks that cannot be distributed to many engineers; instead, a few senior engineers took that task to the benefit of all others.
Congratulations for admitting your ignorance, and lending open ears to experts as to why they made certain engineering decisions.
Oh wait, you weren't doing that, you were just warming up to go on a diatribe about how stupid Facebook engineers must be.
Yes, they made certain engineering decisions now because the decisions they made back then were stupid, and they have to dig themselves out.
Neither Ruby or Python provide that for instance.
Though Ruby is in my opinion well designed,and with duck typing,you might not need all that Java like OOP, I dont know,I feel like having interfaces makes me understand code faster and better,
Want to understand what an object does? just read the interface,no magics,no bullshit,it's self documenting and that's important,that's why you can have these huge codebases like Zend,Symfony or Doctrine and still understand how complex elements work together. And even figure out how to use them without a doc,just like Java.
I feel I cant go to Django's source code or Rails source code and understand everything easily just by reading function signatures.
And the write/refresh cycle makes iteration pretty fast during development. But yeah,PHP basic syntax sucks for sure.
HHVM replaced the execution environment for their code with a more robust code generation/ runtime system.
Hack allows them to bootstrap their code base into higher degrees of reliability without a mass rewrite.
Also Brian O'Sullivan is one of the best people on the face of the earth to be trying to find practical ways on integrating PL research into practical engineering.
Because there are factors like an existing codebase that works that trump BS idealism.
Do you also argue that C++ is built on top of a crumbling foundation, because it's based on C, a ancient language with almost no type-safety?
It admittedly doesn't have a very advanced type system, that's true.
I do not think C is a "crumbling foundation". I would not suggest that C be used for large scale engineering efforts, but it's a relatively well-defined language with semantics dictated by a formal standard. A lot of research has gone into C compilers, which are state-of-the-art.
With that said, one of the biggest complaints I hear about C++ is that it still has the legacy of C embedded in it.
Actually, building on a foundation of solid statistics and probability will often result in an algorithm that essentially counts views and applies weighting rules.
As another example, Pagerank has a nice theoretical basis, but power iteration reduces to perhaps 5-10 lines of C.
I think you're using a wrong metaphor. Facebook foundations can't be crumbling just because they're made in PHP. There wouldn't be Facebook as we know it today otherwise. You might say they used a "low quality" material to build them. I see Hack more as a better material, that can also bind with the previous one and make it stronger.
That's not really true, HPHP and HHVM share the runtime (mostly).
Disclaimer: I have no zero experience with PHP.
Clearly the home rolled stuff is working out for facebook. Twitter was/is on RoR and continues(!!) to have major downtime issues.
They blamed RoR a lot because they needed an explanation for their problems, but "many to many" messaging even at their scale is a "solved" problem and has been for decades and is fairly easy to scale.
(Think of Twitter as a bunch of mailing lists and mailboxes; you scale it by decomposing it: map accounts to virtual "buckets" that becomes the domain part, and map tweets to messages; break apart large follower lists into smaller ones and introduce a forwarding reflector; break apart large following lists by splitting "mailboxes" and doing zipper merges on reading it; add a caching layer -- this is not rocket science, and you could do it properly in any language)
Note: I think RoR was a horrible choice for them, though I love Ruby, but I also don't for a second believe RoR was their real problem.
Edit: Your overall point stands, though. Especially given that Facebook is a far more complicated application.
And when Facebook uses this stupid technique to build the world's largest social network for more than one billion users, those elegant and perfect solutions are serving ... how many?
You might dislike it, but that doesn't mean it's disliked. PHP has a giant base of programmers, scales, is easy to learn, is extremely versatile and powerful, and as you point out, the code was already in PHP. Only an idiot would rewrite a giant working codebase simply to have it in a language that's "difficult to hire and train" in. Or any language for that matter. Perhaps they could have pulled a netscape but instead decided to serve billions.
> • [ X ] The name of your language makes it impossible to find on Google”
appending "-lang" certainly gives you better results but still does not find you a lot of un-tagged good blog posts
You can imagine what came up!
> Thus, Hack was born. We believe that it offers the best of both dynamically typed and statically typed languages, and that it will be valuable to projects of all sizes.
In which way does it offer the benefits of dynamic typing? The entire point seems to be to abandon dynamic typing, which is fine, but not what that sentence says.
I'm guessing, for example, you can't really do meta-programming with Hack in the way you can with dynamic languages, is that correct?
You cant be more meta than that.
I dont know if you can do that with Hack, but that's definetly a big PHP pattern.
I don't see HHVM that much as a 'different runtime' like Rubinius/JRuby/Topaz or Jython/Unladen Swallow/Pypy - it's more a fork in my book, and Hack adds a lot to that by also greatly changing the language.
This is not a criticism or even positive/negative - this is my point of view.
Is this a layer that is superimposed on PHP that falls back to the default interpreter for unimplemented features or is this a fresh implementation. I suppose my question is, how reliable is this. Are the core PHP bugs going to manifest here? If a bug gets fixed on core PHP, will hack be lagging behind?
Hack runs on the HHVM engine. HHVM is fairly stable and is used by Facebook to serve over a billion web requests per today. In the past year or so developers outside of Facebook have started using HHVM to run other PHP codebases, and at present 20 of the top PHP frameworks are able to run correctly on HHVM (hhvm.com/frameworks), with 9 of the framework's test suites fully passing.
If you encounter behavioral differences or bugs when running HHVM, you can report it at our github site (hhvm.com/repo) and we will help get it resolved.
Well where is PHP core then? to my knowledge while PHP 5 was a huge step forward, PHP core did little to fix PHP stupid design flaws,for the sake of backward compatibility.
We are in a new era, libraries are more and more decoupled,so they are easy to write or rewrite,backward compatibily shouldnt be an issue when libraries are well versioned and tested across different versions.
And Wordpress folks dont care about PHP.next.Why bother with them?
Someone has to do it, and the PHP developers have proven time and again that they aren't going to. At some point the only options are to leave PHP altogether, or make your own PHP that sucks less.
Search: "Hack Anonymous Function" Search: "Hack Background Process"
Expect "Why I migrated from Go to Hack" articles soon enough.
Either way, the name is very fitting. I have no use for this, but good for Facebook that they've managed to (at least to some extent) evade some of the many PHP pitfalls.
Why would you expect that? Obviously the bulk of people migrating to hack will be coming from PHP.
instead of this: <?hh class MyClass { const MyConst: int = 0; private $x: string = ''; public function increment(int $x): int { $y = $x + 1; return $y; } }
The first seems inconsistent to me. Especially coming from AS3/Haxe where the function return value is indicated in the same manner.
function f(int $x): float { ... }
A nice effect of this decision is that this allows us to change:
class C {
private int $x = 20;
public function __construct(int $x,) {
$this->x = $x;
}
}
class C {
public function __construct(
private int $x = 20,
) {}
}If these type of innovations introduce hobby programmers into more professional practices and concepts, I'm all for it.
Yes, I'm slightly bitter :/
What does this mean?
Obviously switching to a syntactically incompatible programming language would be at odds with that goal.
Seriously, though, they wanted to move a large PHP codebase over to a better language, at the scale of a multi-billion-dollar tech company, in a reasonable amount of time. They accomplished this. What's the criticism here?
It's entirely appropriate and reasonable to say "I don't understand why Facebook would do this; please explain it to me." But it reflects a supreme lack of humility to say "I don't understand why Facebook would do this; they must be idiots, and when they, armed with inside information I don't even know I don't have, come to defend themselves, I will angrily try to convince them of the error of their ways."
If you think what Facebook has done here is stupid, why is that something to get upset over? In fact, why is it even something worth arguing about? You're not going to convince anyone who matters, and anyway you have nothing to gain by doing so: Instead, just short Facebook stock and be smug in the knowledge that, when Facebook announces next year that they're abandoning PHP in favor of a ménage à trois of OCaml, F#, and Clojure, you'll be able to say "I told you so".
Congrats to Facebook on taking PHP forward. It powers a vast amount of the web and it's great to see that it's getting some engineering love!
Remind me the words from Steve Jobs:
"By the way, what have you done that’s so great? Do you create anything, or just criticize others work and belittle their motivations?"
As you say, Thrift connects this all. You can look into our C++ core library, Folly, and other C++, C, Python, and Java applications and libraries like Rocksdb, Presto, watchman, Buck, flint, scribe, and so forth on github.
bos said in another thread: "Yep, we're happy to be inspired by good ideas when they're obviously the right path to walk."
You can actually write you example a bit more concisely in Hack: "$y ==> $y + 1".
[1] - https://github.com/strangeloop/StrangeLoop2013/blob/master/s...
I am reminded of http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule.
Facebook is now at sufficient scale where they are reimplementing Common Lisp on top of PHP.
Good to keep in mind the next time you read a topic on how awesome language X/framework Y/method Z is.
It's depressing to see how much of our profession is informed by the desire to being cool and fashionable, like kids in schoolyard.
E.g. the only way how I could find useful resources on how to run celery with fig was to exclude -gorgonzola.
Edit : i just forgot that i still haven't found any server side language i'm satisfied with. I'm still waiting for a type-annotated variant of python to catch on.... So maybe hack would be a good choice after all. It's such a pity they started this work based on php rather than any other cleaner language.
It's cool to see the same idea implemented in Hack. I don't know if anyone at FB has even heard of Obvious, but it's cool that they had the same idea in their language.
One note though - the success of this depends on the success of HHVM. Hopefully FB guys understand that and will push even more to make HHVM the best platform to have for running PHP on.
Nevertheless, let's remember that web applications are not a one-shop monolithic anymore.
But as the documentation says primarily "HHVM can run both your PHP and Hack code, either separately or when both are part of one project." -- does that means we can imagine a framework or something like that - where parts of it is in Hacklang and parts are in old PHP?
or such project is somewhere there already?
2 things are not obvious from the article:
1. Why a new language, and not just a gradual typing tool for PHP (like Typed Racket and Typed Clojure)?
2. Is type information somehow passed to runtime to assist JIT compilation?
¹ YMMV ² sometimes
See also:
KPHP (subset of PHP to C++ translator, released by Vkontankte).
:(
This was their opportunity to to get multi-byte strings right...
PHP cannot, so I wonder how deep the relationship goes.