7 ms·

Looks really interesting. PHP may not be the "hip" language to use (although it's getting better), but it's so popular and accessible that disregarding it as a

Looks really interesting. PHP may not be the "hip" language to use (although it's getting better), but it's so popular and accessible that disregarding it as a legitimate option for new projects is myopic.

pyre 11y ago
I've talked to people doing large-scale deployments in PHP that complain about things like memory-leaks, etc in the language, so I'm not entirely convinced that PHP is really an excellent language (and runtime) that just happens to get a bad rap.
- cweagans 11y ago
  I'm a PHP developer that works for a major media company. We do large scale deployments, and I'd like to say that PHP is a terrible language that gets a bad rap. It's getting better, and it's already 1000000x better than the PHP4 days, but it's still not a nice language. It's not a nice runtime. The only thing nice about it is that a zillion people and their dogs all know it and it's relatively easy to deploy.
  - smt88 11y ago
    Any experience with HHVM yet?
    - cweagans 11y ago
      We haven't been/won't be using it. Most of our traffic is anonymous, so we can optimize other parts of our stack. We'd rather not have to debug weird shit that comes up because of HHVM incompatibility.
  - look_lookatme 11y ago
    Do you use an off the shelf framework or CMS?
    - cweagans 11y ago
      We use Drupal.
      - Gigablah 11y ago
        Well, there you go.
        cweagans 11y ago
        Are you suggesting that off-the-shelf frameworks/CMSes are somehow inferior to writing everything from scratch? That seems pretty myopic. We gain a lot from using Drupal.
  - j42 11y ago
    This. It really depends how you use it. In some ways they've introduced some powerful features bringing it on par with other languages, but the reality is that performance varies wildly in the real world because opcaches are finicky dependent on the data/request type/frequency and automated GC/circular-reference optimization is far from perfect. Between HHVM (to effectively make memory growth linear vs logarithmic when approaching higher request concurrency) and sensible opcache tweaks you can make that runtime a bit less stochastic at scale, however if you don't know what you're doing PHP makes it so easy to go in the complete opposite direction without any indications you're running toward a cliff...
- vectorpush 11y ago
  > I've talked to people doing large-scale deployments in PHP that complain about things like memory-leaks, etc in the language What does it mean for a language to have memory leaks? Are you talking about a problem specific to the PHP runtime or common PHP idioms that lead to leaky code? A specific example would be helpful as I've never known PHP to be particularly vulnerable to memory-leak bugs (at least not any more than any of the other popular imperative scripting languages). Also, what's the substance behind the "etc" in your comment? I'm not really sure what naturally follows in the sequence of "memory-leaks and so on...." Your comment seems to simply cast doubt without much substance.
  - pyre 11y ago
    > What does it mean for a language to have memory leaks? I'm not embroiled in the PHP-world, so I don't know how many alternate PHP runtimes exist, but I presume that the default PHP runtime itself was being referenced. Seeing as for a long time there was a single runtime paired with the language (I'm 99% sure that PHP4 didn't have alternate runtimes), I think that equating bugs in the runtime with bugs in the language is something that happens even if technically they are separate things. > Your comment seems to simply cast doubt without much substance. And your comment seems needlessly defensive. I made a comment about general sentiment that I've gotten from people that have actual working knowledge of large-scale PHP deployments. I'm sorry that in the middle of the conversation I didn't start immediately interrogating these people asking why they haven't filed bug reports if there are memory leaks. Also, is it devoid of substance if I'm basically stating that I've talked to people "in the trenches" (and presumably know what they are talking about) who don't have the opinion that PHP is some beautiful, but misunderstood language that gets a bad rap? > Also, what's the substance behind the "etc" in your comment? I'm not really sure what naturally follows in the sequence of "memory-leaks and so on...." Maybe I should have phrased that as "(e.g. memory leaks)" to show that memory leaks weren't the only complaint, but my memory fails me on what the other complaints were.
    - vectorpush 11y ago
      > I'm not embroiled in the PHP-world, so I don't know how many alternate PHP runtimes exist, but I presume that the default PHP runtime itself was being referenced. So are you talking about the default PHP 4 runtime or the default PHP 5.3 runtime or the default PHP 5.4 runtime etc? These versions are very different beasts, so levying a vague "memory leak" criticism at PHP without substantiating it via code or even a version makes the criticism pretty meaningless. > I think that equating bugs in the runtime with bugs in the language is something that happens even if technically they are separate things. I asked for clarification because I was unsure what you were referring to. For example, about a month ago I was tasked with debugging a memory leak in a legacy Ruby application where I eventually discovered that the developer had used a proc in such a way that it prevented the GC from freeing variables that had been referenced in the closure. It was an issue somewhat similar to the examples described in this blog post: http://victorarias.com.br/2013/08/13/leaky-ruby.html http://victorarias.com.br/2013/08/13/leaky-ruby.html I wouldn't attribute this memory leak to the Ruby langauge but more to a Ruby idiom that developers should take care to avoid. That's the type of clarification I'm looking for, but it appears that you don't really have anything to offer the discussion in this regard. > And your comment seems needlessly defensive. I made a comment about general sentiment that I've gotten from people that have actual working knowledge of large-scale PHP deployments. I'm sorry that in the middle of the conversation I didn't start immediately interrogating these people asking why they haven't filed bug reports if there are memory leaks. I have no emotions tied up in this discussion, I'm trying to make a point that your criticism is just anecdotal hearsay without any way for someone to verify if what you're saying is actually true. I didn't suggest that you ask your colleagues to file bug reports, I was simply pressing you for more details since your vague anecdote runs counter to my own experiences with PHP as I relate it to the rest of the imperative scripting landscape. > Also, is it devoid of substance if I'm basically stating that I've talked to people "in the trenches" (and presumably know what they are talking about) who don't have the opinion that PHP is some beautiful, but misunderstood language that gets a bad rap Yes, that is pretty much the definition of "devoid of substance". "In the trenches" is a subjective description that doesn't mean anything. You presume they know what they're talking about, but maybe they actually don't, but we'll never know either way because all you've done is recount nebulous secondhand generalizations. You're not even asking me to take your word for it, you're asking me to take your word for their word. Can't you see why that's a little dubious?
- smt88 11y ago
  I wouldn't be surprised if those memory leaks were due to an older version of PHP (GC was recently improved a lot to clean up circular references) or a poorly-written framework, which most of them are. Some people also don't understand that arrays of large data have to be wrapped in objects or explicitly passed by reference in many situations to avoid duplicating them in memory. I've used PHP a few times in the past for some long-running, complex cron jobs, and I never had memory leaks. I've also never noticed it for short-running HTTP responses, and some of those have been really awful and messy because I'm more of a PHP doctor than someone who starts projects with it. Anyway, everyone is going to benefit from HHVM. If Facebook uses it in production, you can be sure that it won't have any common memory leaks for long.
  - conradfr 11y ago
    > Some people also don't understand that arrays of large data have to be wrapped in objects or explicitly passed by reference in many situations to avoid duplicating them in memory. IIRC arrays are always passed by reference and only duplicated if you modify the data inside the called function (if not passed with '&' of course) ?
    - deweller 11y ago
      Correct. The runtime uses a copy-on-write implementation when you pass an array by value. Duplicating an array in memory every time it is passed to or from a function would be awful.
      - smt88 11y ago
        > Duplicating an array in memory every time it is passed to or from a function would be awful. This might be because I originally learned PHP about 16 years ago, but I could swear this used to be the case. There's definitely a reason PHP has the reputation it has, although many of those glaring issues have since been fixed.
        conradfr 11y ago
- deleted 11y ago
  [deleted]

pyre 11y ago

I've talked to people doing large-scale deployments in PHP that complain about things like memory-leaks, etc in the language, so I'm not entirely convinced that PHP is really an excellent language (and runtime) that just happens to get a bad rap.

cweagans 11y ago
I'm a PHP developer that works for a major media company. We do large scale deployments, and I'd like to say that PHP is a terrible language that gets a bad rap. It's getting better, and it's already 1000000x better than the PHP4 days, but it's still not a nice language. It's not a nice runtime. The only thing nice about it is that a zillion people and their dogs all know it and it's relatively easy to deploy.
- smt88 11y ago
  Any experience with HHVM yet?
  - cweagans 11y ago
    We haven't been/won't be using it. Most of our traffic is anonymous, so we can optimize other parts of our stack. We'd rather not have to debug weird shit that comes up because of HHVM incompatibility.
- look_lookatme 11y ago
  Do you use an off the shelf framework or CMS?
  - cweagans 11y ago
    We use Drupal.
    - Gigablah 11y ago
      Well, there you go.
      - cweagans 11y ago
        Are you suggesting that off-the-shelf frameworks/CMSes are somehow inferior to writing everything from scratch? That seems pretty myopic. We gain a lot from using Drupal.
- j42 11y ago
  This. It really depends how you use it. In some ways they've introduced some powerful features bringing it on par with other languages, but the reality is that performance varies wildly in the real world because opcaches are finicky dependent on the data/request type/frequency and automated GC/circular-reference optimization is far from perfect. Between HHVM (to effectively make memory growth linear vs logarithmic when approaching higher request concurrency) and sensible opcache tweaks you can make that runtime a bit less stochastic at scale, however if you don't know what you're doing PHP makes it so easy to go in the complete opposite direction without any indications you're running toward a cliff...
vectorpush 11y ago
> I've talked to people doing large-scale deployments in PHP that complain about things like memory-leaks, etc in the language What does it mean for a language to have memory leaks? Are you talking about a problem specific to the PHP runtime or common PHP idioms that lead to leaky code? A specific example would be helpful as I've never known PHP to be particularly vulnerable to memory-leak bugs (at least not any more than any of the other popular imperative scripting languages). Also, what's the substance behind the "etc" in your comment? I'm not really sure what naturally follows in the sequence of "memory-leaks and so on...." Your comment seems to simply cast doubt without much substance.
- pyre 11y ago
  > What does it mean for a language to have memory leaks? I'm not embroiled in the PHP-world, so I don't know how many alternate PHP runtimes exist, but I presume that the default PHP runtime itself was being referenced. Seeing as for a long time there was a single runtime paired with the language (I'm 99% sure that PHP4 didn't have alternate runtimes), I think that equating bugs in the runtime with bugs in the language is something that happens even if technically they are separate things. > Your comment seems to simply cast doubt without much substance. And your comment seems needlessly defensive. I made a comment about general sentiment that I've gotten from people that have actual working knowledge of large-scale PHP deployments. I'm sorry that in the middle of the conversation I didn't start immediately interrogating these people asking why they haven't filed bug reports if there are memory leaks. Also, is it devoid of substance if I'm basically stating that I've talked to people "in the trenches" (and presumably know what they are talking about) who don't have the opinion that PHP is some beautiful, but misunderstood language that gets a bad rap? > Also, what's the substance behind the "etc" in your comment? I'm not really sure what naturally follows in the sequence of "memory-leaks and so on...." Maybe I should have phrased that as "(e.g. memory leaks)" to show that memory leaks weren't the only complaint, but my memory fails me on what the other complaints were.
  - vectorpush 11y ago
    > I'm not embroiled in the PHP-world, so I don't know how many alternate PHP runtimes exist, but I presume that the default PHP runtime itself was being referenced. So are you talking about the default PHP 4 runtime or the default PHP 5.3 runtime or the default PHP 5.4 runtime etc? These versions are very different beasts, so levying a vague "memory leak" criticism at PHP without substantiating it via code or even a version makes the criticism pretty meaningless. > I think that equating bugs in the runtime with bugs in the language is something that happens even if technically they are separate things. I asked for clarification because I was unsure what you were referring to. For example, about a month ago I was tasked with debugging a memory leak in a legacy Ruby application where I eventually discovered that the developer had used a proc in such a way that it prevented the GC from freeing variables that had been referenced in the closure. It was an issue somewhat similar to the examples described in this blog post: http://victorarias.com.br/2013/08/13/leaky-ruby.html http://victorarias.com.br/2013/08/13/leaky-ruby.html I wouldn't attribute this memory leak to the Ruby langauge but more to a Ruby idiom that developers should take care to avoid. That's the type of clarification I'm looking for, but it appears that you don't really have anything to offer the discussion in this regard. > And your comment seems needlessly defensive. I made a comment about general sentiment that I've gotten from people that have actual working knowledge of large-scale PHP deployments. I'm sorry that in the middle of the conversation I didn't start immediately interrogating these people asking why they haven't filed bug reports if there are memory leaks. I have no emotions tied up in this discussion, I'm trying to make a point that your criticism is just anecdotal hearsay without any way for someone to verify if what you're saying is actually true. I didn't suggest that you ask your colleagues to file bug reports, I was simply pressing you for more details since your vague anecdote runs counter to my own experiences with PHP as I relate it to the rest of the imperative scripting landscape. > Also, is it devoid of substance if I'm basically stating that I've talked to people "in the trenches" (and presumably know what they are talking about) who don't have the opinion that PHP is some beautiful, but misunderstood language that gets a bad rap Yes, that is pretty much the definition of "devoid of substance". "In the trenches" is a subjective description that doesn't mean anything. You presume they know what they're talking about, but maybe they actually don't, but we'll never know either way because all you've done is recount nebulous secondhand generalizations. You're not even asking me to take your word for it, you're asking me to take your word for their word. Can't you see why that's a little dubious?
smt88 11y ago
I wouldn't be surprised if those memory leaks were due to an older version of PHP (GC was recently improved a lot to clean up circular references) or a poorly-written framework, which most of them are. Some people also don't understand that arrays of large data have to be wrapped in objects or explicitly passed by reference in many situations to avoid duplicating them in memory. I've used PHP a few times in the past for some long-running, complex cron jobs, and I never had memory leaks. I've also never noticed it for short-running HTTP responses, and some of those have been really awful and messy because I'm more of a PHP doctor than someone who starts projects with it. Anyway, everyone is going to benefit from HHVM. If Facebook uses it in production, you can be sure that it won't have any common memory leaks for long.
- conradfr 11y ago
  > Some people also don't understand that arrays of large data have to be wrapped in objects or explicitly passed by reference in many situations to avoid duplicating them in memory. IIRC arrays are always passed by reference and only duplicated if you modify the data inside the called function (if not passed with '&' of course) ?
  - deweller 11y ago
    Correct. The runtime uses a copy-on-write implementation when you pass an array by value. Duplicating an array in memory every time it is passed to or from a function would be awful.
    - smt88 11y ago
      > Duplicating an array in memory every time it is passed to or from a function would be awful. This might be because I originally learned PHP about 16 years ago, but I could swear this used to be the case. There's definitely a reason PHP has the reputation it has, although many of those glaring issues have since been fixed.
      - conradfr 11y ago
deleted 11y ago
[deleted]