Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
PHP Programming Social Networks Apache

Facebook's HipHop Also a PHP Webserver 304

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.'"
This discussion has been archived. No new comments can be posted.

Facebook's HipHop Also a PHP Webserver

Comments Filter:
  • GUI applications (Score:5, Interesting)

    by sopssa ( 1498795 ) * <sopssa@email.com> on Tuesday February 02, 2010 @07:09PM (#31003174) Journal

    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.

    • Re: (Score:3, Interesting)

      by FooAtWFU ( 699187 )
      Fast to write, sure, but "nice"? The language is a mess, its metaprogramming is weak, and its packaging system is almost as bad as C. If you want a "nice" language go for Ruby or even Python something. (I do Perl myself, which has its share of cruft and hacks, but at least I have a decent package/namespace system.)
      • by dgatwood ( 11270 ) on Tuesday February 02, 2010 @07:42PM (#31003562) Homepage Journal

        What makes PHP nice is that it is so close to C. For people who are comfortable working in C, PHP is just a few dollar signs away.

        • by MightyMartian ( 840721 ) on Tuesday February 02, 2010 @07:47PM (#31003632) Journal

          What makes PHP nice is that it is so close to C. For people who are comfortable working in C, PHP is just a few dollar signs away.

          Which is like saying an anus is almost like a vagina...

          Feel free to take that analogy the distance.

          • by linumax ( 910946 )

            Which is like saying an anus is almost like a vagina...

            Feel free to take that analogy the distance

            Distance or depth? You decide.

          • Analogy of the year (Score:3, Interesting)

            by oldhack ( 1037484 )

            "Which is like saying an anus is almost like a vagina..."

            I bow down in respect. Somebody mark this post for posterity. It's only Feb 2, but this has to be the Analogy of the Year.

        • Re: (Score:3, Insightful)

          What makes PHP nice is that it is so close to C. For people who are comfortable working in C, PHP is just a few dollar signs away.

          Well, JavaScript is even closer, then - not even dollar signs needed.

          In truth, however, it may be a curse rather than a blessing. The syntax looks deceptingly familiar, but semantics are anything but. C is a language where things are generally unambiguous and straightforward, even when syntax is cryptic. PHP is the opposite - seemingly simple syntax can have a lot of subtle ambiguities. See my other comment [slashdot.org] to this story for an example.

          • by dgatwood ( 11270 )

            A significant percentage of JavaScript stuff is done with dot notation and classes. So I'd say its closer to a subset of C++, really. It's also a pretty awful language, mainly because of the debugging environment. (Don't get me wrong, the new debuggers make it a heck of a lot better than it used to be, but that's like saying death by a million paper cuts is better than death by a million razor blades.)

            Regarding the issue of array indices in PHP, it is a little ugly, but you can generally cast such a stri

            • A significant percentage of JavaScript stuff is done with dot notation and classes. So I'd say its closer to a subset of C++, really.

              Most well-written PHP code (at least, code that proponents of the language tout as well-written) is also done using dot (er, arrow) notation and classes. This doesn't make it a subset of C++ in any way, since classes are neither invented by C++, nor exemplified by it.

              If anything, PHP is actually closer to C++ than JavaScript is, because both PHP and C++ have class-based OOP, while JavaScript offers prototype-based OOP.

              It's also a pretty awful language, mainly because of the debugging environment. (Don't get me wrong, the new debuggers make it a heck of a lot better than it used to be, but that's like saying death by a million paper cuts is better than death by a million razor blades.)

              Are we talking about JS-in-a-browser here, or JS as a free-standing general-purpose langua

            • Re: (Score:3, Informative)

              by Yold ( 473518 )

              No, its closer to Lisp/Scheme; it has been called "Lisp in in C's clothing". The keywords and syntax is somewhat C-like, but once you get beyond the basics you'll understand what I'm talking about... but here is a simple example (styled for brevity):

              function func(){
              var foo = "bar";
              return (function(){alert(foo);}); }

              function bazz(arg){
              alert(foo); //error
              arg();} //alerts foo

              bazz(func());

              Javascript doesn't allow you to access Objects (aka Associative Arrays) via numeric indexes

        • by Korin43 ( 881732 )
          Why don't you just use Java? It's more like C++, and has the advantage of having a standard library that isn't a huge mess (it's also much faster).
          • Re: (Score:3, Insightful)

            by dgatwood ( 11270 )

            Mainly because I have a fundamental difference of opinion when it comes to return values versus exceptions. The Java folks seem to prefer the latter quite frequently. I tend to think that exceptions are for things that are truly exceptional---the equivalent to a kernel panic---something that should almost always cause the program to crash or at most, clean up and die. Thus, exceptions should never be thrown by any standard library because no library can reasonably determine what is or is not fatal to the

            • by Korin43 ( 881732 )
              You don't really have to use exceptions though. They seem like they could be useful, but if you don't want them you can just ignore them. Any Java classes that use them will warn you and you can just surround them with a try/catch.
    • by shutdown -p now ( 807394 ) on Tuesday February 02, 2010 @07:30PM (#31003418) Journal

      PHP is really nice and fast to write. *ducks from the c/c++ coders*

      You should duck from Python and Ruby coders. The C++ guys are too busy beating up Java schmucks. ~

      • Sorry, get ready for a beatin!

        I tried to post a reply but I segfaulted, bad string handling. I had to wade through fields of ampersands and asterisks to get here.

        -C guy.

        • by ls671 ( 1122017 ) *

          This happens sometimes when I screw up doing pointer arithmetics or when I do not check array bounds.

          To cure this, I started designing a system were I will abstract pointers with my own custom library. It will also automatically free the memory from unused objects. I will call it "memory recollection".

          I am also designing my own custom third party library to automatically check array bounds ;-))

          • Re: (Score:3, Informative)

            by jfim ( 1167051 )

            This happens sometimes when I screw up doing pointer arithmetics or when I do not check array bounds.

            To cure this, I started designing a system were I will abstract pointers with my own custom library. It will also automatically free the memory from unused objects. I will call it "memory recollection".

            I am also designing my own custom third party library to automatically check array bounds ;-))

            You mean like boost::shared_ptr [boost.org] and std::vector::at() [cplusplus.com]?

        • by geniusj ( 140174 )

          I know you said C, but you were responding to a post regarding C++. I'll just clarify that the issues you're alluding to, while they exist in C++, are exceedingly rare (when using references, STL, Boost) compared to C.

    • Re: (Score:3, Insightful)

      by EvilIdler ( 21087 )

      I write in PHP, among lots of other languages. I'm not a hater. I'm also interested in this project for renting out space to PHP-based projects. Higher density per server = less costs :)

      But where's the code? My calendar says "Wednesday", and I was sure this was a Tuesday announcement. Github search turns up nothing. How long does it take to upload 300k lines of code? Getting impatient here ;)

  • by __aaclcg7560 ( 824291 ) on Tuesday February 02, 2010 @07:16PM (#31003276)
    For all the trouble you're going through to convert PHP into C++ (300,000 lines and 5,000 unit tests), wouldn't programming in C++ in the first place be easier?
    • Re: (Score:3, Insightful)

      by Lennie ( 16154 )
      Because it's really easy to create memory leaks and similair bugs in C++.
      • by Cyberax ( 705495 ) on Tuesday February 02, 2010 @07:47PM (#31003616)

        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.

        • "The main problem is compilation speed. C++ compilers are just plain slow."

          You do go to the bathroom or have some coffee or tea once in a while don't you?

        • by ls671 ( 1122017 ) *

          > The main problem is compilation speed. C++ compilers are just plain slow.

          Are you saying C++ doesn't have development platforms that compile your code in real time as you modify it ?

          I haven't been coding in C++ for a while but I assumed something similar to eclipse was available for C++ developers. Heck, C++ must be supported by eclipse so doesn't it compile the code in real time as you modify it.

          I am just curious, maybe it is harder to acheive this with C++,

          Thanks for answers everybody. ;-)

      • by shutdown -p now ( 807394 ) on Tuesday February 02, 2010 @07:57PM (#31003720) Journal

        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...

        • Re: (Score:3, Insightful)

          by Unequivocal ( 155957 )

          I've run across quite a few ignorant Ruby libraries that leak memory like sieves. Most Ruby on Rails applications have to reboot once a day if they are well written and way more often than that if they aren't. High level languages can leak like crazy, same like low level languages - this whole topic is wack.

          Low level languages like C and ASM are vulnerable to executing data instead of code -- cf. Microsoft windows from day 1.

          I can't figure out why people are comparing memory leaks from one language to anoth

      • duration of leak (Score:5, Interesting)

        by pikine ( 771084 ) on Tuesday February 02, 2010 @08:18PM (#31003854) Journal
        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.
    • by sopssa ( 1498795 ) *

      PHP is a lot better environment to develop new features quickly and doesn't get you into so many security pitfalls. And they're already using C++ for some parts of the site:

      HipHop allows us to write the logic that does the final page assembly in PHP and iterate it quickly while relying on custom back-end services in C++, Erlang, Java, or Python to service the News Feed, search, Chat, and other core parts of the site.

      The common suggestion is to just rewrite Facebook in another language, but given the complexity and speed of development of the site this would take some time to accomplish.

      As a programming language, PHP is simple. Simple to learn, simple to write, simple to read, and simple to debug. We are able to get new engineers ramped up at Facebook a lot faster with PHP than with other languages, which allows us to innovate faster.

      And I agree with them on those aspects.

      • by shutdown -p now ( 807394 ) on Tuesday February 02, 2010 @07:43PM (#31003582) Journal

        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 [php.net], 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 [php.net]. 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.

        • by abulafia ( 7826 )

          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 [php.net]. Good programming practices FTW!

          Oh, good lord. I didn't know about that one. Every time I think I know just how awful PHP is, I learn something like that.

          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.

          I think it is a bit like penis envy. Not all of them, but a lot of PHP monkeys like to think imagine they're much more hard-core than they are, so they compare what they do to what they perceive as a "real" language.

          If they took the time to actually understand what makes Perl, Python or Ruby so superior, well, it is unlikely that they'd still be happy with PHP.

          • by dgatwood ( 11270 ) on Tuesday February 02, 2010 @08:44PM (#31004094) Homepage Journal

            The @ syntax is not a try/catch. PHP doesn't stop execution when it encounters errors opening files and stuff. It merely blasts a warning message to the output stream (web client). The @ operator suppresses that output. It's equivalent to sending the perror() after a failed fopen() call to /dev/null. Whether the command succeeds or fails, control still returns to your code after the statement. The @ operator merely suppresses the error message generated by PHP so that you can display a more appropriately formatted and/or more useful error message (or not display a message at all if the failure is expected). In a production environment, most people disable the warning output from PHP anyway, making it basically a no-op except during debugging.

            If you folks want an argument against PHP, you're all going about it wrong. Probably the best argument against PHP is that it makes it easy to design yourself into a corner---putting code into the middle of HTML templates that suddenly needs to be able to set a header field and "whoops, that has already been sent", putting code into the middle of templates that needs to change the content up a level, and "whoops, have to add a hack over here to fix that", etc. The result is that for really simple sites, PHP is awesome, but it has real problems scaling to more complicated designs without dropping the templates (or at best, including them on the back end after you do a lot of compute processing up front to set things up, choose a template programmatically, etc.).

            Or you could simply attack it for being a lot slower than C and leading to design patterns that waste lots of memory. For example, associative arrays are simple and easy to use, but 90% of the time, there are much simpler data structures that can do just as well. If your data structures are small, no problem. If you deal with something big, the difference in memory pressure between a clean, lightweight binary tree (even without balancing) and an associative array can result in an order of magnitude impact in performance (or two or three).

            • The @ syntax is not a try/catch. PHP doesn't stop execution when it encounters errors opening files and stuff. It merely blasts a warning message to the output stream (web client). The @ operator suppresses that output. It's equivalent to sending the perror() after a failed fopen() call to /dev/null. Whether the command succeeds or fails, control still returns to your code after the statement. The @ operator merely suppresses the error message generated by PHP so that you can display a more appropriately formatted and/or more useful error message (or not display a message at all if the failure is expected). In a production environment, most people disable the warning output from PHP anyway, making it basically a no-op except during debugging.

              If @ is something that is effectively a no-op in a sane environment, then why is it still in the language after 5 major revisions?

              Perhaps a better question to ask, then, is why opening a file which doesn't exist won't just noisily terminate the application (since all code that follows might assume that file was opened successfully, and is essentially incorrect from that point on), rather than just printing a message to output? How about approaching this problem like, I dunno, it was done 25 years ago, when

            • by abulafia ( 7826 ) on Tuesday February 02, 2010 @09:47PM (#31004692)

              No, I think I'll stick with attacking it for being a truly crappy language. I don't care that it is slow or wastes memory. If you're paying$20/month for your dance-school-business-calendar installed and customized by a local teenager, the idea of writing a web app in C is silly for efficiency is silly. Likewise, whatever the intent of @ is for, I most certainly expect people have and will abuse it in exactly the way described to "fix" problems. People endlessly bash, for instance, Perl as being write only, and there's truth to that. But there is truth to that because the language tends to encourage hard to read code. You can say that's not the intent, and you'd be right, but that doesn't matter. (Though I do still love Perl.)

              I do agree that PHP is fine for toy web sites, and that people get themselves in trouble using the executable web page model because the don't know what they're doing. These things are true for the same reason: PHP is full of poorly thought out magic that allows people to get in over their head, and doesn't provide the tools to easily dig back out. I'm all for making programming more accessible, but encouraging people to foot-bullet themselves in predictable ways doesn't strike me as a good approach.

              I dislike it for other reasons, but for instance Ruby on Rails is a much more solid approach, in my opinion - the path of least resistance is generally the right thing to do, once a newbie internalizes the MVC idea and a couple conceptual points the learning curve is pretty gentle, and Ruby is a pretty well constructed language that lets people grow into using more conceptually useful techniques over time without the up-front demands of learning, say, Lisp.

              (While I'm chasing people off my lawn, the whole RoR mindset seems to lead people down a rabbit hole of writing dumb little DSLs -- who on earth thinks a toy language for generating CSS is a good idea? You just push yourself one more indirection layer away from what's going on and end up dinking around with yet another silly new syntax for your effort. Muppet coding at its worst.)

        • 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?

          It should be clearly obvious that if you want to use a string as an integer, you use intval to convert it first. Programmers who know the difference between strings and integers know that. Don't take that personally, that comment isn't aimed at you, there are many, many PHP "programmers" who really don't know anything about data types (as a question answerer on the w3schools forum, I can readily attest to this; the level of inexperience people have when trying to tackle major projects is staggering).

          It's

          • It should be clearly obvious that if you want to use a string as an integer, you use intval to convert it first.

            That wasn't my point. Indeed, if I want to use a string as an integer, I will explicitly convert it myself. So why does it insist on automatically converting "8" to 8 behind my back?!

            It's difficult to fault a language just because it's easy to learn though. PHP is easy to learn, because it does a lot of stuff automatically (casting, error suppression, etc, like you said).

            At some point, doing too much stuff behind programmer's back is outright dangerous. This includes too much implicit casting. And I've never heard anyone complaining about how, say, Python is hard, just because it requires you to convert string to int whenever you need to use a string in int context.

            "Automatic" (not really, sinc

        • @ predates PHP exception handling, and was used for the old method of error handling.

          That said, PHP's error handling in general is annoying, as the built-in functions generally raise errors instead of throwing exceptions. That's an artifact of the way the language changed over time, rather than that it was poorly designed.
          • That's an artifact of the way the language changed over time, rather than that it was poorly designed.

            PHP5 was already a breaking revision of the language; they could have just as well taken care of that bit.

            In any case, historical reasons or not, today it's a bad design when compared to virtually all modern alternatives, and that's what matters in the end.

            Note, I'm not saying that every single line of PHP code should be rewritten tomorrow. I'm a pragmatist, and if there's an existing, working code base written in PHP - by all means, use it, maintain it, and extend it. But, for God's sake, let's use modern,

        • by gnud ( 934243 )

          The weak typing is your main concern with PHP? You can make arguments that strong/explicit typing is better, but weak typing is NOT php's problem. The behaviour of array keys is completely consistent with the type system everywhere else in the language, any scalar value can be an array key. By the way, later in your own post you point at dynamic typing as an advantage. Please make up your mind?

          • The weak typing is your main concern with PHP? You can make arguments that strong/explicit typing is better, but weak typing is NOT php's problem. The behaviour of array keys is completely consistent with the type system everywhere else in the language, any scalar value can be an array key. By the way, later in your own post you point at dynamic typing as an advantage. Please make up your mind?

            "Weak typing" and "dynamic typing" are two distinct concepts. For example, Python is dynamically typed, but it is also strongly typed.

            Dynamic typing means that variables don't have types, only values do. The opposite - when variables have types, and can only be bound to values of matching types - is static typing.

            Strong typing means that but you (generally) cannot randomly treat a value of one type as another type - with the exception of subtyping, and a few well-established conversions (such as int/float).

        • by tukang ( 1209392 )

          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 [php.net]. Good programming practices FTW!

          What you linked to is nothing more than short circuit evaluation, which nearly every programming language in existence supports. http://en.wikipedia.org/wiki/Short-circuit_evaluation [wikipedia.org]

          • What you linked to is nothing more than short circuit evaluation

            I linked to the description of PHP operator @, which has nothing to do with short-circuit evaluation. I assume you've seen the example in linked documentation article, which uses the common "... or die()" idiom, but the article itself isn't about that, and it was not what I was referring to.

      • by MightyMartian ( 840721 ) on Tuesday February 02, 2010 @07:45PM (#31003594) Journal

        PHP is a lot better environment to develop new features quickly and doesn't get you into so many security pitfalls. And they're already using C++ for some parts of the site:

        Except for the problem that, historically, PHP is been one big vast security pitfall.

    • Re: (Score:3, Informative)

      For all the trouble you're going through to convert PHP into C++ (300,000 lines and 5,000 unit tests), wouldn't programming in C++ in the first place be easier?

      They address this specifically in one of the articles. They want their whole team (many of whom are not C++ developers) to contribute.

  • by RobotRunAmok ( 595286 ) on Tuesday February 02, 2010 @07:19PM (#31003304)

    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?!

    • Re: (Score:2, Funny)

      by Anonymous Coward
      I made the mistake of installing HipHop. I should have known something was wrong when the server started wearing pants hanging down so low that its anus was sticking out. Then eventually the thing ran away and now spends its time at the local Popeye's and makes money stealing people's hubcaps.
      • Re: (Score:2, Funny)

        by Anonymous Coward

        My friend, if someone's anus is sticking out, they have far more problems than oversized pants!

    • by NevDull ( 170554 ) on Tuesday February 02, 2010 @07:40PM (#31003548) Homepage Journal
      My guess is that it was probably a progression from "Haiping's PHP" to HPHP to HipHop.
      Two syllables vs four or more... looks like they're not just computing more efficiently, but also speaking more efficiently!
    • Re: (Score:3, Funny)

      by Nerdfest ( 867930 )
      It sucks. To compile, it makes you hold you mouse sideways ... gangsta style.
  • Ah ha! (Score:4, Funny)

    by bernywork ( 57298 ) <bstapletonNO@SPAMgmail.com> on Tuesday February 02, 2010 @07:27PM (#31003384) Journal

    This explains a lot, a couple - few months ago, I started getting complaints about "potentially virus infected" / "unscanable" zip files when being served content from facebook.com and fbcdn.net etc.

    They probably changed at this point how they were sending data out of the web server with zip compression and it all started falling over at this point....

    I was wondering what the change was....

  • by ztransform ( 929641 ) on Tuesday February 02, 2010 @07:28PM (#31003398)

    Chat routinely freezes up the browser, and people appear offline when they are online.

    I frequently get error messages from pages that won't dynamically load (there is something wrong with the server, or such message).

    Facebook doesn't need a half percent increase in performance, they need a lot more!

  • From TFA... (Score:3, Funny)

    by BitHive ( 578094 ) on Tuesday February 02, 2010 @07:33PM (#31003462) Homepage

    As a programming language, PHP is simple. Simple to learn, simple to write, simple to read, and simple to debug. We are able to get new engineers ramped up at Facebook a lot faster with PHP than with other languages, which allows us to innovate faster.

    hahahahahhahahahhahahahahhahahahahhahahah

  • I heard that PHP is good for Flooz.

  • There's a difference between beta and production code when it comes to the code that runs Facebook?
  • here we go... (Score:3, Interesting)

    by Tumbleweed ( 3706 ) * on Tuesday February 02, 2010 @09:16PM (#31004362)

    It's arguments like these that make me wish for a LLVM/JIT version of D that I could use instead of PHP. And then just compile the thing if I needed soopa-doopa performance.

    OR that REBOL had developed into a big open source platform.

    *sigh*

    The fights between C++/C#/Java/JavaScript fanatics are fights about the different implementations/targets of the same obsolete programming syntax structures, and don't do anyone any good.

  • php-eaccelerator (Score:3, Informative)

    by hey ( 83763 ) on Wednesday February 03, 2010 @10:18AM (#31010076) Journal

    Since php lives in Apache which is always running it makes sense to cache the compiled byte codes.

    I like the approach of this:

    https://admin.fedoraproject.org/pkgdb/packages/name/php-eaccelerator?_csrf_token=7bb450c274970e7f6d6ece15a4194c5feb114809 [fedoraproject.org]

Adding features does not necessarily increase functionality -- it just makes the manuals thicker.

Working...