Slashdot Mirror
Facebook's HipHop Also a PHP Webserver
darthcamaro writes "As expected, Facebook today announced a new runtime for PHP, called HipHop. What wasn't expected were a few key revelations disclosed today by Facebook developer David Recordan. As it turns out, Facebook has been running HipHop for months and it now powers 90 percent of their servers — it's not a skunkworks project; it's a Live production technology. It's also not just a runtime, it's also a new webserver. 'In general, Apache is a great Web server, but when we were looking at how we get the next half percent or percent of performance, we didn't need all the features that Apache offers," Recordon said. He added, however, that he hopes an open source project will one day emerge around making HipHop work with Apache Web servers.'"
While theres already several libraries intended for creating windows and interfaces with PHP, and to put them together into an executable file, this might greatly improve that area in PHP too. While being faster as well, being machine code it protects your code too.
Along with making it work with Apache Web servers I hope someone works on this aspect too. PHP is really nice and fast to write. *ducks from the c/c++ coders*
Definitely interesting project.
And here I never thought that anything could ever take the award for "Most Stupidly Named Software" away from the Ubuntu distros.
Congrats again, HipHop! Can I get a Fist-Bump?!
the php haters: "look how awful php is, you need to convert everything into c++ before you can use it in really large scale deployments!"
"Look how awful C++ is, you have write bits in assembly to get it to really run."
"Look how awful assembly is, you really optimize when you can write machine opcodes."
And the microcode guys just glare out from their caves with their glowy little eyes in incredulity.
Elsewhere is heard, "You guys still use CPU's? It's the GPU decade, dude."
And somebody down the hall builds an ASIC to solve a specific problem and thinks he's so smart.
But, the analog EE understands his elegant circuit doesn't enable a team of 200 developers to build the top social networking site.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
As a programming language, PHP is simple. Simple to learn, simple to write, simple to read, and simple to debug.
PHP is not a simple language. A keymark of a simple language is consistency, and PHP is anything but - I won't even touch on the mess that is the standard function library, but just the language itself. For example, this gem, taken directly from the language spec, regarding array indices/keys:
A key may be either an integer or a string. If a key is the standard representation of an integer, it will be interpreted as such (i.e. "8" will be interpreted as 8, while "08" will be interpreted as "08"). Floats in key are truncated to integer. The indexed and associative array types are the same type in PHP, which can both contain integer and string indices.
This is awesome on many levels. The obvious fubar is the treatment of "8" vs "08" (and note that, while it is clearly obvious when a string literal is used in the source code, how about a string variable, or other expression computed at runtime?). But the bit about silent float->int truncation is also interesting, especially the "silent" part. Combined with rounding errors and the overall non-obviousness of binary floating-point arithmetic (especially to a typical PHP coder), this design decision is just hilarious.
I've long held the opinion that C/C++ rules on mixed signed/unsigned arithmetic and comparisons are a good example of awful language design, but PHP beats that by a margin so large it's not even funny.
Oh, I also don't know of any other language that has what effectively amounts to synactic sugar for try/catch with an empty catch block. Good programming practices FTW!
I find it curious, by the way, that PHP coders like to compare the language to C++ or Java - where it actually has some subjective advantages, such as dynamic typing - but very rarely to Perl, Python or Ruby, where all such advantages disappear, but design flaws immediately stand out.
An experienced C++ programmer rarely creates memory leaks, and they are easily detected by a variety of tools.
Also, for PHP-style programs it might be easier to just restart a child server process each N requests. So memory leaks are of even less concern.
The main problem is compilation speed. C++ compilers are just plain slow.
I'm both sides.
I love PHP when I need to throw something together fast (like today) but don't expect a lot of heavy use. I love PHP when I want to get some handy tools that I can easily hack into doing what I really want. Still, when I have a significant project, and server load starts to matter, I loathe trying to use PHP and would usually rather write it as Perl, sometimes even compiling (gasp) Perl into something about as efficient and a whole lot more reliable than if I tried to write it in C. If I were really serious, I'd write it in C, but a day's work in C is 30 minutes in Perl or 10 in PHP.
Choice of language for me is about return on investment. I'm not a grand programmer, I don't have the luxury of getting comfortable programming, if I'm programming it means that I'm not spending time on the dozens of other issues confronting our IT department. Most of the time if we're doing any sort of serious project, we're buying service from somebody who does it better than I have time to, probably better than I could.
If this HH thing (no, can't stand to type the real name) gets momentum then it could be really good for shops like ours. We could turn the tools we don't have time to do well into things that don't suck so much and the tools that we wouldn't think were worth the hardware into things we can afford to run.
B) Eliminate all the stupid users. This is frowned upon by society.
Because it's really easy to create memory leaks and similair bugs in C++.
It's very easy to get rid of memory leaks in C++, as well. A very simple rule: never, ever write a type declarator with a * in it. In other words, no raw pointers - use Boost/TR1 shared_ptr, or roll out your own, it doesn't matter - just use it consistently. At that point, you can still get reference cycles (which are also leaks), but you can do that in PHP 5.3 - which also uses reference counting with no GC for cyclical references - just as well. And the usage of 5.3 so far is minuscule.
Alternatively, just use any of third-party tracing GCs, such as Boehm.
By the way, from personal experience, I find that languages with built-in reference counting and no cycle detection (those I know of are VB6 and PHP) are actually more prone to memory leaks when coding that languages with explicit memory management. The reason is that, in, say, C++, coders are actually aware of issues such as memory allocation, and view smart pointers as convenient helpers, not as some kind of magic fairy dust. Because of that, the question of "what happens if two smart pointers reference each other" is a rather obvious one, and the issue is noticed and rectified early on. In contrast, in VB6 and PHP, you don't have to deallocate explicitly, so refcounting is magic - many people don't even understand how the algorithm works! - that is, until you run into a cyclic reference that leaks...
We're talking about C++ as a CGI script. Who cares about memory leaks that only last for the duration of an HTTP request, which is a fraction of a second? The real problem with memory leaks is when you have a long-running process like single-process web browsers.
I once had a signature.