Facebook.
Also, I think they are trying to move away from PHP as quickly as possible without rewriting the entire site. The new projects and tools are not in PHP; moreover, I think most of the new people they hire never have to use PHP at all.
Finally, just because they managed to use PHP to run a bit site does not mean it is the best web language, or even a good web language. It just means it's adequate.
The central fallacy here is imagining that one size could or should fit all, whether it's php or rails or anything.
> Yes. And now Facebook is spending a ton of resource and
> man-hours programming around this. They had to write
> their own compiler!
The fact that they're compiling to C++ is a consequence of the slowness of the programming language implementations of those languages that are used traditionally for web development. AFAIK Ruby was and still is the slowest of the bunch.
Now, it's reasonable that I did not get the full picture, but the people I did talk did not use PHP themselves and claimed that new projects didn't either. Perhaps this varies per team. My impression was that existing code bases using PHP were still under active development (that is, getting new features) but new projects and new developers did not use PHP.
Since most benchmarks are unscientific, this one is as good as any. So here goes:
http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...
Since benchmarks are completely worthless, let's just stop this pissing match right now.
Citation needed again. Ruby 1.9 is slower than Python 3, and Python 3 is slower or as fast as Python 2 on Python official benchmarks.
http://docs.python.org/release/3.0.1/whatsnew/3.0.html#perfo...
> Since benchmarks are completely worthless, let's just stop this pissing match right now.
Benchmarks are far from worthless. And pissing match? Asking for citations amounts to pissing match? The parent claimed something that isn't true(ruby 1.9 significantly faster than CPython - that has never been the case). And you are adding python 2.x was slower than 1.9, when 2.x is generally faster than 3.
I love ruby as much as the next guy. But when it comes to execution speed, ruby has always been the slowest among ruby, python, and perl.
Python 2.7.2
def fib(n):
if n == 0 or n == 1:
return n
else:
return fib(n-1) + fib(n-2)
for i in range(36):
print "n=%d => %d" % (i, fib(i))'
Ruby 1.9.3 def fib(n) if n == 0 || n == 1 n else fib(n-1) + fib(n-2) end end
36.times do |i|
puts "n=#{i} => #{fib(i)}"
endI guess since benchmarks are not completely worthless, we should conclude that ubuntu doesn't keep up on ruby and uses 2-3 year old versions.
I wasn't accusing you of starting the pissing match.
The original keeps getting re-iterated: http://programmingzen.com/2007/11/28/holy-shmoly-ruby-19-smo...
The original author, on a basis of a fib benchmark, concludes ruby 1.9 is faster - that is as flawed as it gets.
Did you try running with Python 3? You will get around the same time as you get with Python 2.7. Pick anything from here http://shootout.alioth.debian.org/u64q/benchmark.php?test=al... and run it with Python 2.7 and ruby 1.9. The programs which are faster with Python 3 will be mostly faster with Python 2.7. 2.7 isn't slower than ruby 1.9; it is faster in most of the cases.
Regarding the fib example, when the original was doing the rounds, I didn't find any explanations from python or ruby implementors. I can't say why, but most likely python has a higher overhead with growing call stacks, and ruby does some optimizations.
Huh? Since 21 Apr 2012, the benchmarks game has shown - ruby 1.9.3p194 (2012-04-20 revision 35410).
When the comparison would be better without that complication, look at single core measurements -- http://shootout.alioth.debian.org/u64/benchmark.php?test=all...
1) You seem to be using "unscientific" as a nothing more than an insult.
2) Your conclusion "this one is as good as any" doesn't follow from your premise that "most benchmarks are unscientific" -- "this one" might well be different from "most benchmarks".
3) If your conclusion was correct then that wouldn't mean that the benchmark was good, just that it was also bad.
>1) You seem to be using "unscientific" as a nothing more than an insult.
More like preemptively declaring I don't want to deal with HN crowd replying with "but benchmarks are worthless".
> 2) Your conclusion "this one is as good as any" doesn't follow from your premise that "most benchmarks are unscientific" -- "this one" might well be different from "most benchmarks".
IMO shootout benchmarks are better than random benchmarks on the web as they detail the testing environment, provide the source code and can be re-created
It's a dirty job but it still has to be done ;-)
Let them reply and then answer them.
Facebook isn't trying to move away from PHP as quickly as possible. For years, there have been PHP components (primarily web front-end rendering, aggregation/ranking of data from various sources) and C++ components (primarily high-performance back-end services) and other languages like Python (primarily non-production-path/operations back-end services) and Java (primarily Hadoop-related technologies like Hive and HBase, and services that are heavy users of such), and nothing groundbreaking has changed in this.
New hires use PHP or C++ or whatever language (and often multiple languages) necessary to work on the team and projects they choose to work on. New projects use the languages that make the most sense.
Almost all web front-end work involves PHP - the frameworks and libraries and runtime environment are well-developed, well-tested, well-documented, and well-known.
In terms of HipHop for PHP, the question to ask is: What language could have allowed quick low-barrier-to-entry web-app-centric development in the early days while still delivering the sort of runtime efficiency demanded by the environment? Languages like Python and Ruby may arguably allow the first (but remember we're talking about early 2004 here, so Ruby on Rails was not out, and neither were Django, Flask, and so forth and WSGI had just come out), but would have required a "HipHop for PHP"-style solution as well. Languages like C, C++, and Java may have the runtime efficiency, but it would be a hard argument to say they're as developer-time-efficient as PHP (especially back then).
That's a slightly different question to what one should do today if starting a new venture. And _that_ is also a different question to what Facebook should do today - HipHop for PHP exists, and is delivering performance/runtime efficiency that most languages people mention as an alternative do not. And, the PHP frameworks and libraries and runtime environment exist and allow rapid development of production code. It's actually reasonably pleasant to develop for with those in place.
The HipHop for PHP team is small, but have huge leverage - this small team of reasonably hardcore low-level C++ programmers are making a whole bunch (hundreds?) of PHP developers way more productive (since they don't have to use a relatively slower-to-develop-in language/runtime like C++), and also makes the cost of operating the site go down by making that code more efficient and reducing the number of servers needed.
So, since most people here are suggesting Python or Ruby, what real world example can we provide that compares to Facebook in order to make sure that these languages would perform better than PHP?
Neither Twitter, nor Reddit or Disqus are exactly the most stable and performant sites out there. So?
I would say that quick and dirty comparisons like this are meaningless.
Talking about what languages programmers find enjoyable and productive is perhaps more meaningful. This is where Python and Ruby shine, and PHP falters.
Here is a list of template languages people on 'real' platforms use:
Python.
Airspeed, Castalian, Chameleon, Cheetah, CubicTemp, Django template system, Elements, EmPy, Evoque, HRL Powerful macro preprocessor for HTML, Genshi, Jinja 2, Mako, moody-templates, Myghty, Qpy, PML, pyratemp, Spyce, SUIT, Tempita, Tenjin, Template Toolkit, Templite+, thrases, ClearSilver, HTMLTemplate, JonsPythonModules, meld3, PyMeld, Pyxer, pso, Sprite, teng, webstring, XSLTools, PyPa, Genshi, kajiki, htmltmpl, Kid, SimpleTAL, CherryTemplate, AsciiDoc, Markdown, PyTextile, ReStructuredText, txt2tags, PottyMouth, Creole,
Ruby.
Radius. HAML. cs/Template. ERB, eRuby, Erubis, Galena, Tenjin, Liquid Markup. Ruty, PageTemplate, Amrita, Amrita2, Kwartz, Markaby. Maline. Builder::XmlMarkup, RedCloth, BlueCloth, RSmarty, Tempura, TAL, Curtis / Punk, Erby, RBML, RTALS, Tie, RVelocity, RailTags,
Java.
FreeMarker, SiteMesh, StringTemplate, Tea, Better Templates for Everybody, jxp, LSP, JCopist, Dynamator, RTFTemplate, Velocity, JByte, Jamon, JDynamiTe, WebMacro, Viento, IKAT, Bluprints, Transformica, Hapax, MiniTemplator, Xtempore,
_Not a complete list._
PHP is a pretty good template language, with pretty amazing documentation.
To deploy, you just upload a file.
You could walk outside now, and start yelling "I NEED A PHP PROGRAMMER!" and you'd probably find someone pretty quickly.
There are millions of hosts to choose from at tiny prices, who can provide support because they know the platform.
I'd be interested to know if there's any commentary from people high up in Facebook on whether they'd use PHP again if they were starting now?
None use PHP.
I can't find a citation, but there was a thread where a fb engineer claimed fb's internal PHP wiki starts with "There are two kind of people. People who hate PHP, and people who don't use PHP."
Or they got tired of being bullied by people like you.
> Or they got tired of being bullied by people like you.
Or they really aren't a fan of PHP?
http://www.quora.com/Quora-Infrastructure/Why-did-Quora-choo...
Be comfortable with the language you prefer and quit whining about the rest!!!
The analogy was only meant to demonstrate an objection to arguments along the lines of "it's used by something popular therefore it's good" or "lots of people use it therefore it's good" which seem to be common points put forward in favour of PHP.
Popularity/ use by someone popular may be an indicator of quality but it very often isn't, the analogy isn't intended to go any further than that!
Since the problem seems to be that you need someone to choose for you: use Django on Python, use Rails on Ruby, and for each one use the templating that comes with it. If you switch to another framework, use its templating language. If you are advanced enough to use a microframework then you are advanced enough to plug in Jinja2 or whatever it is you really want.
Django, Rails, and Jinja2 have excellent documentation. I can't understand why you would think that PHP's documentation is significantly better.
You get what you pay for on super-cheap hosts who are somehow incompetent to understand Python or Ruby.
And choice is not a bug.
"The template language you pick has a good chance of becoming an abandoned project" hardly seems a great selling point.
This is something that I point out as a negative. Yes, you can get a PHP programmer just about anywhere. But being that there are so many, it's harder to find those few truly talented programmers.
My own complaint about this is that if you bring in cheap PHP programmers, you end up with cheaply-written PHP. And the result is inevitably an unmaintainable mess. If you want well-written, maintainable code, you have to be willing to hire talented and experienced programmers. And in doing so, you give up that so vaunted "advantage" of PHP's mindshare.
Moreover, it seems to me that the truly talented programmers that would produce good software have a tendency to distance themselves from PHP.
So it seems to me: Choose PHP for cheap, quick projects on a budget for which quality is irrelevant; or choose a "harder" language for solid applications that will stand the test of customer interaction.
I also, still, don't get your point. There are other templating languages for PHP too.
Again, your deployment argument is just as silly as your availability argument. It's trivial to deploy to Azure (sites) or Heroku, or Ironio or gondor, or any Go project, or etc, etc.
>There are millions of hosts to choose from at tiny prices, who can provide support because they know the platform.
Are you even reading what I write? Please show me a real webapp with actual users hosted on el cheapo shared hosting.