6 ms·

Not to derail the thread at all. But, for a brand new greenfield application. Why would someone choose PHP for their backend, when Golang is available? I was

Not to derail the thread at all. But, for a brand new greenfield application. Why would someone choose PHP for their backend, when Golang is available? I was at a developer meeting with a company who were reviewing what to use for a client project. The developers are from PHP/jQuery shop, however they felt it necessary to be with the times so to speak, for the future to get other projects. They opted for Vuejs and Golang with server side processing. Apparently the client has some server side operations which are particular heavy and mentioned that php/python/ruby are just too slow with their own internal testing. Many thanks!

tonyjstark 10y ago
You would probably choose PHP because - it's easier to find PHP programmers - you get a lot of mature frameworks with huge communities - most of the time you don't need fast but fast enough just some of the reasons, PHP7 is actually quite nice.
pearjuice 10y ago
Because in PHP, you can actually pinpoint dependencies on a specific version.
kyriakos 10y ago
Your last sentence really doesn't leave much of a choice.
- smcl 10y ago
  Guess that depends on whether you take the client's word at face value. If they've done the necessary profiling and analysis, sure - but if not it's also possible they're performance constrained by their DB layer or some badly structured code. No way for me to know though, of course :)
ceejay 10y ago
I'd say probably a large part of the reason PHP devs opt to use different languages in new projects (when given the choice) is because of FUD spread about PHP. Everyone wants stability in their career. If the voices on the interweb are loud enough saying PHP is dead / dying, it kind of becomes a self-fulfilling prophecy. I would hazard a guess that if PHP was not so hated (like the one kid on the playground that everyone decides to mock because everyone else is, and because it keeps attention off of them) devs who are familiar with and articulate in PHP would not hesitate to start new projects with it. Anyways, my personal perspective is server-side is becoming a smaller and smaller piece of the web. Any reasonably designed language should be sufficient. Unless maybe if you're Google or Microsoft, or deal heavily with extremely large datasets such as BigData / Analytics / Machine Learning companies. And even then worst case scenario you just throw all the data into AWS RedShift or something like that. If you're writing an OS, building a Linux driver or writing a memory management library I'd certainly recommend avoiding PHP :) BTW, I've run side projects where PHP (before 7.*) sufficiently handled databases with 100's of tables containing billions (yes, that's a 'B') of rows each on a single $250 laptop. That includes jobs running relatively heavy analytics jobs on those tables. My guess is if the company was spending money to get appropriate talent to handle their infrastructure they might be able to make PHP work well for them without a lot of trouble. And by that I don't necessarily mean they have untalented people. I'm saying if they're truly "fluent" in PHP, or are willing to put in the effort to learn PHP, it shouldn't be hard to do.
- vesak 10y ago
  >I'd say probably a large part of the reason PHP devs opt to use different languages in new projects (when given the choice) is because of FUD spread about PHP. Everyone wants stability in their career. If the voices on the interweb are loud enough saying PHP is dead / dying, it kind of becomes a self-fulfilling prophecy. No programmer can expect to use just a single language over their whole career. They might have career stability if they choose that but very risky stability.
  - ceejay 10y ago
    True. I read the OP as describing a scenario where (a) Devs were originally hired as PHP devs, (b) Those devs decided to use a different language in the new project.
vesak 10y ago
No reason really to use PHP for a new project in 2016. Then again, no huge reasons not to use it, either. Sure, it's slightly sub-standard in many small ways, but your success or failure is probably not hanging on those things. So if Go looks better to you, you should use that.
naranha 10y ago
Yeah PHP can be pretty slow. For example on the symfony3 project (also with Vuejs) I currently work on which has ~6 doctrine DB classes, 5 controllers and returns just a simple json representation (1kb) of one the entities using symfony serializer I get response times of 70ms in production mode on an i7-4790K with 16 Gigs of ram. Getting the same entity simply from CouchDB yields response times of 3ms. The problem is that PHP needs to bootstrap the entire environment for every request (minus some more or less efficient caching) which may be OK for monolithic applications but as soon as you want to build an app on HTTP2 that runs many requests, it will just always feel sluggish. And for this symfony already cheats massively by merging all class files into one huge bootstrap.php file etc. PHP just wasn't made for large applications.
- fetbaffe 10y ago
  With Doctrine, you need to know what and when to enable caching in the correct layer. Complicated. Personally I avoid ORMs and write SQL, better control and better performance.
  - naranha 10y ago
    It's not just doctrine that makes it slow, it's the whole bootstrapping process on every request. Compare this to a Java Application using JPA and JAX-RS with >50 model classes and >10GB data which gives response times of <10ms with debugging enabled (OK it uses more RAM, but meh).
    - fetbaffe 10y ago
      Yes, that is problem, therefore I avoid frameworks to have total control when bootstrapping.
    - mschuster91 10y ago
      > It's not just doctrine that makes it slow, it's the whole bootstrapping process on every request. When you use proper opcode caching, you avoid the startup hit. And having a generous amount of RAM usable as disk cache also helps in framework-heavy projects - the more files can be cached in RAM, the less PHP has to hit the disk on require/include.
fetbaffe 10y ago
- easy deploy - large community - anyone can code PHP and become productive fast - No built in shared state. - PHP is available almost everywhere - proven - simple development cycle
jstewartmobile 10y ago
As someone who uses both Go and PHP, I think they're separate use cases. The up-side to PHP is that it is super-flexible. The down-side to PHP is that it is super-flexible. You can work fast with it, which also allows you to be extremely sloppy with it. The programmer has to wield all the discipline, because the language sure isn't going to help. The up-side to Go is that Rob Pike is older, wiser, and learned all of the mistakes of C and C++. Rather than have it be all things to all people, he made some very opinionated design choices with crystal-clear trade-offs. More code will have to be written. It will be in an imperative style. Errors will need to be handled explicitly rather than through a catch-all exception. Elbow grease! Elbow-grease that results in more robust code that is easier to understand and reason about. So, why PHP? Sometimes quick and workable is preferable to slow and great.
Lazare 10y ago
Golang isn't a bad option...but neither is (modern) PHP, Python, or Ruby. (Or .net, JVM, nodejs...) Each has some specific advantages, and that absolutely includes PHP. PHP right now is in an interesting space: It's very stable, it has an enormous ecosystem, it has some extremely strong frameworks and tooling, the syntax has stopped being egregiously bad, it's starting to get quite fast, and the PHP request/response model is very attractive for some purposes, and avoids an entire class of bugs which crops up with, eg, nodejs. If you're doing something where PHP is appropriate (which is a lot of stuff), and you're familiar with it, you're going to be extremely productive. Switching to golang (especially if not familiar with it) is like deciding that instead of going to the supermarket and buying a loaf of bread, you're going to buy a farm and figure out how to grow wheat. You have the ability to end up with a better product, but there's no promise you will, and it'll be a lot more work. > Apparently the client has some server side operations which are particular heavy and mentioned that php/python/ruby are just too slow Of course if the client requires you to use golang, then sure, use golang. But it makes me wonder about the design the client is imagining. If your web server is trying to do very intensive calculations as part of the request/response cycle, you're probably doing something very, very wrong. But if you're not doing that, why does your need to do intensive calculation impact your choice of frontend? What's stopping them from having a lightweight frontend which queues up jobs in a task queue, and then have workers written in golang or C or whatever? And then maybe a websocket server to feed results back to the browser as they arrive? Where did they get the idea that a project needed a single language for every feature?

tonyjstark 10y ago

You would probably choose PHP because - it's easier to find PHP programmers - you get a lot of mature frameworks with huge communities - most of the time you don't need fast but fast enough just some of the reasons, PHP7 is actually quite nice.

pearjuice 10y ago

Because in PHP, you can actually pinpoint dependencies on a specific version.

kyriakos 10y ago

Your last sentence really doesn't leave much of a choice.

smcl 10y ago
Guess that depends on whether you take the client's word at face value. If they've done the necessary profiling and analysis, sure - but if not it's also possible they're performance constrained by their DB layer or some badly structured code. No way for me to know though, of course :)

ceejay 10y ago

I'd say probably a large part of the reason PHP devs opt to use different languages in new projects (when given the choice) is because of FUD spread about PHP. Everyone wants stability in their career. If the voices on the interweb are loud enough saying PHP is dead / dying, it kind of becomes a self-fulfilling prophecy. I would hazard a guess that if PHP was not so hated (like the one kid on the playground that everyone decides to mock because everyone else is, and because it keeps attention off of them) devs who are familiar with and articulate in PHP would not hesitate to start new projects with it. Anyways, my personal perspective is server-side is becoming a smaller and smaller piece of the web. Any reasonably designed language should be sufficient. Unless maybe if you're Google or Microsoft, or deal heavily with extremely large datasets such as BigData / Analytics / Machine Learning companies. And even then worst case scenario you just throw all the data into AWS RedShift or something like that. If you're writing an OS, building a Linux driver or writing a memory management library I'd certainly recommend avoiding PHP :) BTW, I've run side projects where PHP (before 7.*) sufficiently handled databases with 100's of tables containing billions (yes, that's a 'B') of rows each on a single $250 laptop. That includes jobs running relatively heavy analytics jobs on those tables. My guess is if the company was spending money to get appropriate talent to handle their infrastructure they might be able to make PHP work well for them without a lot of trouble. And by that I don't necessarily mean they have untalented people. I'm saying if they're truly "fluent" in PHP, or are willing to put in the effort to learn PHP, it shouldn't be hard to do.

vesak 10y ago
>I'd say probably a large part of the reason PHP devs opt to use different languages in new projects (when given the choice) is because of FUD spread about PHP. Everyone wants stability in their career. If the voices on the interweb are loud enough saying PHP is dead / dying, it kind of becomes a self-fulfilling prophecy. No programmer can expect to use just a single language over their whole career. They might have career stability if they choose that but very risky stability.
- ceejay 10y ago
  True. I read the OP as describing a scenario where (a) Devs were originally hired as PHP devs, (b) Those devs decided to use a different language in the new project.

vesak 10y ago

No reason really to use PHP for a new project in 2016. Then again, no huge reasons not to use it, either. Sure, it's slightly sub-standard in many small ways, but your success or failure is probably not hanging on those things. So if Go looks better to you, you should use that.

naranha 10y ago

Yeah PHP can be pretty slow. For example on the symfony3 project (also with Vuejs) I currently work on which has ~6 doctrine DB classes, 5 controllers and returns just a simple json representation (1kb) of one the entities using symfony serializer I get response times of 70ms in production mode on an i7-4790K with 16 Gigs of ram. Getting the same entity simply from CouchDB yields response times of 3ms. The problem is that PHP needs to bootstrap the entire environment for every request (minus some more or less efficient caching) which may be OK for monolithic applications but as soon as you want to build an app on HTTP2 that runs many requests, it will just always feel sluggish. And for this symfony already cheats massively by merging all class files into one huge bootstrap.php file etc. PHP just wasn't made for large applications.

fetbaffe 10y ago
With Doctrine, you need to know what and when to enable caching in the correct layer. Complicated. Personally I avoid ORMs and write SQL, better control and better performance.
- naranha 10y ago
  It's not just doctrine that makes it slow, it's the whole bootstrapping process on every request. Compare this to a Java Application using JPA and JAX-RS with >50 model classes and >10GB data which gives response times of <10ms with debugging enabled (OK it uses more RAM, but meh).
  - fetbaffe 10y ago
    Yes, that is problem, therefore I avoid frameworks to have total control when bootstrapping.
  - mschuster91 10y ago
    > It's not just doctrine that makes it slow, it's the whole bootstrapping process on every request. When you use proper opcode caching, you avoid the startup hit. And having a generous amount of RAM usable as disk cache also helps in framework-heavy projects - the more files can be cached in RAM, the less PHP has to hit the disk on require/include.

fetbaffe 10y ago

- easy deploy - large community - anyone can code PHP and become productive fast - No built in shared state. - PHP is available almost everywhere - proven - simple development cycle

jstewartmobile 10y ago

As someone who uses both Go and PHP, I think they're separate use cases. The up-side to PHP is that it is super-flexible. The down-side to PHP is that it is super-flexible. You can work fast with it, which also allows you to be extremely sloppy with it. The programmer has to wield all the discipline, because the language sure isn't going to help. The up-side to Go is that Rob Pike is older, wiser, and learned all of the mistakes of C and C++. Rather than have it be all things to all people, he made some very opinionated design choices with crystal-clear trade-offs. More code will have to be written. It will be in an imperative style. Errors will need to be handled explicitly rather than through a catch-all exception. Elbow grease! Elbow-grease that results in more robust code that is easier to understand and reason about. So, why PHP? Sometimes quick and workable is preferable to slow and great.

Lazare 10y ago

Golang isn't a bad option...but neither is (modern) PHP, Python, or Ruby. (Or .net, JVM, nodejs...) Each has some specific advantages, and that absolutely includes PHP. PHP right now is in an interesting space: It's very stable, it has an enormous ecosystem, it has some extremely strong frameworks and tooling, the syntax has stopped being egregiously bad, it's starting to get quite fast, and the PHP request/response model is very attractive for some purposes, and avoids an entire class of bugs which crops up with, eg, nodejs. If you're doing something where PHP is appropriate (which is a lot of stuff), and you're familiar with it, you're going to be extremely productive. Switching to golang (especially if not familiar with it) is like deciding that instead of going to the supermarket and buying a loaf of bread, you're going to buy a farm and figure out how to grow wheat. You have the ability to end up with a better product, but there's no promise you will, and it'll be a lot more work. > Apparently the client has some server side operations which are particular heavy and mentioned that php/python/ruby are just too slow Of course if the client requires you to use golang, then sure, use golang. But it makes me wonder about the design the client is imagining. If your web server is trying to do very intensive calculations as part of the request/response cycle, you're probably doing something very, very wrong. But if you're not doing that, why does your need to do intensive calculation impact your choice of frontend? What's stopping them from having a lightweight frontend which queues up jobs in a task queue, and then have workers written in golang or C or whatever? And then maybe a websocket server to feed results back to the browser as they arrive? Where did they get the idea that a project needed a single language for every feature?