4 ms·

I'm in the group described halfway down: was on the Internet during PHP 5, lost interest in it, and moved on [to Go]. I haven't written anything in PHP newer t

by mholt 3y ago

I'm in the group described halfway down: was on the Internet during PHP 5, lost interest in it, and moved on [to Go]. I haven't written anything in PHP newer than version 5. Even transitioning from 4 to 5 was quite a big deal, I definitely noticed improvements. But it wasn't enough. I couldn't fit the data set in memory with PHP. But I could do it with Go. I couldn't do parallel computations in PHP in order to respond to an HTTP request quickly enough. But I could do it with Go. I couldn't reliably and easily deploy to different systems with PHP. But I could do it with Go. Eventually, I couldn't write a web server with PHP. But I could do it with Go. A lot of my early websites were written in PHP and I was able to build them quickly and routinely. I didn't really have a problem with PHP as a paradigm, or even its security and consistency posture. I'm glad they've since made an actual language spec and fixed a lot of issues with it. And I don't judge or look down on PHP programmers. I just don't think it was the right tool for my jobs.

deleted 3y ago
[deleted]
heywhatupboys 3y ago
When are these ever issues? In a real life scenario
- konart 3y ago
  In almost any scenario? >I couldn't fit the data set in memory with PHP. But I could do it with Go. I guess this on is self-explanatory. >I couldn't do parallel computations in PHP in order to respond to an HTTP request quickly enough. But I could do it with Go. Consider the following (covers both statements above): you need to get some data from a few sources (databases etc) do some computation on each set and then do some sort of mapping to get the resulting set. You may want those computations to run in parallel and idealy you'd like to start mapping as soon as each computation function starts producing results. >I couldn't reliably and easily deploy to different systems with PHP. But I could do it with Go. I haven't been using PHP since 5 but I assume it's still much easier to just push you Go binary to a destination. Though with Docker and company deploying PHP code is not a big issue these days I assume.
  - heywhatupboys 3y ago
    > >I couldn't fit the data set in memory with PHP. But I could do it with Go. when would you ever have a website serve a request, and have to use gigabytes of memory to do so? > Consider the following (covers both statements above): you need to get some data from a few sources (databases etc) do some computation on each set and then do some sort of mapping to get the resulting set. You may want those computations to run in parallel and idealy you'd like to start mapping as soon as each computation function starts producing results. Again, why would you ever have an HTTP server do so much work in order to serve a request?
    - konart 3y ago
      >when would you ever have a website serve a request, and have to use gigabytes of memory to do so? I'm pretty sure that PHP is not only used for web sites otherwise comparing to Go is simply meaningless. There is little to no point in using Go to build something with a relatevely low load. >Again, why would you ever have an HTTP server do so much work in order to serve a request? http server != website. You can have two services somewhere down infrastructer that communicate via http(s).
      - heywhatupboys 3y ago
        > I'm pretty sure that PHP is not only used for web sites PHP is explicitly designed to serve web content. It's usage may vary, but it is unfair to expect it to optimize towards anything but as a web backend.
  - creamyhorror 3y ago
    > you need to get some data from a few sources (databases etc) do some computation on each set and then do some sort of mapping to get the resulting set. You may want those computations to run in parallel and idealy you'd like to start mapping as soon as each computation function starts producing results. This definitely sounds like a typical situation for handling the job in a queue (plus with an async library like spatie/async to retrieve data in parallel), though I see the advantages and convenience of using a natively-async language here.
kgeist 3y ago
I agree, the main problem with PHP in my experience so far has been that it's very memory-hungry and slow (even PHP7/8), especially when coupled with frameworks/ORM magic. I remember after spending some time with Go, I got used to being able to process tens of thousands objects in memory in milliseconds. When I proposed to do the same in PHP, during architecture review, PHP devs thought I'm out of my mind because that would take like a gig of RAM (which would compete with other PHP processes on the server) and considerable amount of time. You have to use a lot of hacks to make it all fit in memory and be fast. Our Symfony framework also initializes in like 300 ms on each request, while in Go it's below 10 ms. As every PHP process dies after serving a request, you have to reinitialize the whole dependency container on each request from scratch, and in large enterprise applications, that's a lot of dependencies.
- jensensbutton 3y ago
  PHPs language peers are things like Python and Ruby, both of which are slower.
  - giaour 3y ago
    The way developers are encouraged to structure PHP projects (mainly due to autoloader semantics) always felt more like Java or .NET to me than it did like python. The resource consumption comparison between a Symfony web app vs the same thing written in ASP.NET or Spring Boot has a pretty clear winner, and it's not PHP.
  - winrid 3y ago
    Well that depends. There are like a dozen python interpreters and JIT compilers. PyPy is fast, albiet memory hungry.
- naiv 3y ago
  What you are describing only happens in dev environment The Symfony container does not rebuild in production and requests should easily be served within 5-10ms as well so you might want to check your deployment pipeline and that you correctly composer dump-env prod
- 3y ago
_the_inflator 3y ago
I agree with every checkmark except for Go. PHP was the right tool at the time especially when everything on the web was somewhat Wordpress first. PHP felt like a blast with WAMP/LAMP. Since then I have moved on and honestly it never occurred to me, that PHP still could be an option in my tech stacks, neither one of my devs recommended it. No one hates or disliked PHP, there are simply other options. Looking back, recommending PHP today feels like "You can do this with jQuery, too" in the Frontend domain. Yes, you can, but maybe you shouldn't or only if you have the right people. And PHP is a rare skill now.
asdfman123 3y ago
I’m not defending PHP necessarily, but yes, obviously a language that’s more performance oriented will be better at performance-oriented tasks.
codersfocus 3y ago
In terms of parallelization and reinterpreting every request, there is Swoole (implemented in Laravel as Optane) that fixes both of those issues. Most Laravel projects can handle 2x as many requests with a simple modification.
zmxz 3y ago
[flagged]
- xu_ituairo 3y ago
  Your response here feels unkind and combative
- crazygringo 3y ago
  If you had stuck to facts rather than being insulting and inflammatory, I don't think your comment would be downvoted. You make some interesting counterpoints but people aren't going to see them because of the counterproductive language surrounding them. You should take a look at the HN guidelines.
- dang 3y ago
  Yikes, you can't attack others like this on HN. We ban accounts that do that, regardless of how wrong someone else is or you feel they are. If you'd please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.
Cthulhu_ 3y ago
I'd say PHP is great to get started, Go is for when you need more control, more mechanical sympathy. I did write a REST/JSON API in PHP 5.2 (two years ago, I'm aware there's newer versions out there but they aren't easily available in RHEL 6/7 used at our customers at the time - it was a slow moving industry); it's doable, and using best practices learned from other languages makes it look maintainable at least. Did run into some issue with large datasets though, but that was an implementation problem; the original author would read a CSV, convert it to XML using concatenation, then parse the XML to convert it into JSON because at some point a decade ago he found out that the X in XHR was no longer (and never was) the norm, all in memory. That broke when there were more than a few thousand rows in the CSV.
deleted 3y ago
[deleted]

by mholt 3y ago

deleted 3y ago

[deleted]

heywhatupboys 3y ago

When are these ever issues? In a real life scenario

konart 3y ago
In almost any scenario? >I couldn't fit the data set in memory with PHP. But I could do it with Go. I guess this on is self-explanatory. >I couldn't do parallel computations in PHP in order to respond to an HTTP request quickly enough. But I could do it with Go. Consider the following (covers both statements above): you need to get some data from a few sources (databases etc) do some computation on each set and then do some sort of mapping to get the resulting set. You may want those computations to run in parallel and idealy you'd like to start mapping as soon as each computation function starts producing results. >I couldn't reliably and easily deploy to different systems with PHP. But I could do it with Go. I haven't been using PHP since 5 but I assume it's still much easier to just push you Go binary to a destination. Though with Docker and company deploying PHP code is not a big issue these days I assume.
- heywhatupboys 3y ago
  > >I couldn't fit the data set in memory with PHP. But I could do it with Go. when would you ever have a website serve a request, and have to use gigabytes of memory to do so? > Consider the following (covers both statements above): you need to get some data from a few sources (databases etc) do some computation on each set and then do some sort of mapping to get the resulting set. You may want those computations to run in parallel and idealy you'd like to start mapping as soon as each computation function starts producing results. Again, why would you ever have an HTTP server do so much work in order to serve a request?
  - konart 3y ago
    >when would you ever have a website serve a request, and have to use gigabytes of memory to do so? I'm pretty sure that PHP is not only used for web sites otherwise comparing to Go is simply meaningless. There is little to no point in using Go to build something with a relatevely low load. >Again, why would you ever have an HTTP server do so much work in order to serve a request? http server != website. You can have two services somewhere down infrastructer that communicate via http(s).
    - heywhatupboys 3y ago
      > I'm pretty sure that PHP is not only used for web sites PHP is explicitly designed to serve web content. It's usage may vary, but it is unfair to expect it to optimize towards anything but as a web backend.
- creamyhorror 3y ago
  > you need to get some data from a few sources (databases etc) do some computation on each set and then do some sort of mapping to get the resulting set. You may want those computations to run in parallel and idealy you'd like to start mapping as soon as each computation function starts producing results. This definitely sounds like a typical situation for handling the job in a queue (plus with an async library like spatie/async to retrieve data in parallel), though I see the advantages and convenience of using a natively-async language here.

kgeist 3y ago

I agree, the main problem with PHP in my experience so far has been that it's very memory-hungry and slow (even PHP7/8), especially when coupled with frameworks/ORM magic. I remember after spending some time with Go, I got used to being able to process tens of thousands objects in memory in milliseconds. When I proposed to do the same in PHP, during architecture review, PHP devs thought I'm out of my mind because that would take like a gig of RAM (which would compete with other PHP processes on the server) and considerable amount of time. You have to use a lot of hacks to make it all fit in memory and be fast. Our Symfony framework also initializes in like 300 ms on each request, while in Go it's below 10 ms. As every PHP process dies after serving a request, you have to reinitialize the whole dependency container on each request from scratch, and in large enterprise applications, that's a lot of dependencies.

jensensbutton 3y ago
PHPs language peers are things like Python and Ruby, both of which are slower.
- giaour 3y ago
  The way developers are encouraged to structure PHP projects (mainly due to autoloader semantics) always felt more like Java or .NET to me than it did like python. The resource consumption comparison between a Symfony web app vs the same thing written in ASP.NET or Spring Boot has a pretty clear winner, and it's not PHP.
- winrid 3y ago
  Well that depends. There are like a dozen python interpreters and JIT compilers. PyPy is fast, albiet memory hungry.
naiv 3y ago
What you are describing only happens in dev environment The Symfony container does not rebuild in production and requests should easily be served within 5-10ms as well so you might want to check your deployment pipeline and that you correctly composer dump-env prod
3y ago

_the_inflator 3y ago

I agree with every checkmark except for Go. PHP was the right tool at the time especially when everything on the web was somewhat Wordpress first. PHP felt like a blast with WAMP/LAMP. Since then I have moved on and honestly it never occurred to me, that PHP still could be an option in my tech stacks, neither one of my devs recommended it. No one hates or disliked PHP, there are simply other options. Looking back, recommending PHP today feels like "You can do this with jQuery, too" in the Frontend domain. Yes, you can, but maybe you shouldn't or only if you have the right people. And PHP is a rare skill now.

asdfman123 3y ago

I’m not defending PHP necessarily, but yes, obviously a language that’s more performance oriented will be better at performance-oriented tasks.

codersfocus 3y ago

In terms of parallelization and reinterpreting every request, there is Swoole (implemented in Laravel as Optane) that fixes both of those issues. Most Laravel projects can handle 2x as many requests with a simple modification.

zmxz 3y ago

[flagged]

xu_ituairo 3y ago
Your response here feels unkind and combative
crazygringo 3y ago
If you had stuck to facts rather than being insulting and inflammatory, I don't think your comment would be downvoted. You make some interesting counterpoints but people aren't going to see them because of the counterproductive language surrounding them. You should take a look at the HN guidelines.
dang 3y ago
Yikes, you can't attack others like this on HN. We ban accounts that do that, regardless of how wrong someone else is or you feel they are. If you'd please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.

Cthulhu_ 3y ago

I'd say PHP is great to get started, Go is for when you need more control, more mechanical sympathy. I did write a REST/JSON API in PHP 5.2 (two years ago, I'm aware there's newer versions out there but they aren't easily available in RHEL 6/7 used at our customers at the time - it was a slow moving industry); it's doable, and using best practices learned from other languages makes it look maintainable at least. Did run into some issue with large datasets though, but that was an implementation problem; the original author would read a CSV, convert it to XML using concatenation, then parse the XML to convert it into JSON because at some point a decade ago he found out that the X in XHR was no longer (and never was) the norm, all in memory. That broke when there were more than a few thousand rows in the CSV.

deleted 3y ago

[deleted]