Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go with PHP

gowithphp.com

Post reply on HN
Print view View original

231–240 of 532 posts

Re: Go with PHP

#231

Post by cardanome »

cutler wrote: post #202
ofrzeta wrote: post #167

Earlier quoted context omitted.

I guess it depends on how it's communicated. If someone tells me he doesn't like PHP because of this and that reason, that's fine. Getting wound up about some specific programming language (feature) or any tech still raises a red flag for me. But then I might be terrible as well :)

Whatever happened to passionate programmers?

One of the reasons why I love working on PHP jobs is that I get to avoid "passionate" programmers.

It's fine to be excited about programming but those that build their whole identity around it are just super obnoxious and not fun to work with.

Re: Go with PHP

#232

Post by stef25 »

gumballindie wrote: post #155
safety1st wrote: post #44

Earlier quoted context omitted.

This 100%. It's actually a bit of a red flag to me these days if a developer turns up their nose at PHP. The language has matured a lot and building stuff with it is simple, cheap, straightforward and fast. If someone's still hating on PHP in 2023 it makes me wonder if they've been focused on more exotic technology because they were looking to pad their resume with more expensive skills, build science projects for th…

PHP has matured and has been a nice language for a decade now. But PHP developers havent. Cargo culting “good practice” and lack of creativity plagues the community. Frameworks have become so heavy that you spend more time configuring them than actually adding value. Oh and some still argue over setters and getters.

> Oh and some still argue over setters and getters.

Serious question, what does that argument consist of ?

Re: Go with PHP

#233

Post by jensensbutton »

kgeist wrote: post #57
mholt wrote: post #24

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 respon…

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 tha…

PHPs language peers are things like Python and Ruby, both of which are slower.

Re: Go with PHP

#234

Post by sjamaan »

BulgarianIdiot wrote: post #168

The problem is this page advertises Laravel, not PHP. Ruby on Rails has many similar "demo worthy" snippets that make complex tasks seem readable and intuitive to the layman. Laravel and Ruby on Rails have something else in common: due to the focus on these "natural" interfaces, they compromise in every other way. Architecture, performance, testability and so on and so on. For those who know PHP, this code is full of…

> In a nutshell, every line of code you write this way comes loaded with a pound of irreducible, unfixable tech debt.

And worst of all, you are stuck with a shitload of churn every time a new Laravel version comes out. But this is true for Rails and CakePHP and probably many others as well. At least Django seems to be moving a bit slower and not deprecating loads of features on every release.

Re: Go with PHP

#235

Post by cutler »

callahad wrote: post #199
alexriddle wrote: post #154

Earlier quoted context omitted.

What stack can handle 500,000 orders per minute - 22.3 billion a month - on a $6/month server?

Most of them? 500k per minute is around 8k reqs/sec. $6 will get you 2 vCPU, so each CPU only needs to handle 4k requests per second. I'd at least expect that to be possible in Node, and would be somewhat surprised if a Go or Rust framework didn't hit that mark.

Maybe with "Hello world" in Node but not orders. Business-grade Rust web framework? Give me a break.

Re: Go with PHP

#236

Post by cutler »

zer0tonin wrote: post #205
cntrl wrote: post #151

Earlier quoted context omitted.

500,000 orders per minute on a $6/month server? Which language is able to achieve that?

Go

If you're going to pull numbers out of a hat at least provide some evidence, especially evidence based on a comparable workload.

Re: Go with PHP

#237

Post by blueflow »

diordiderot wrote: post #112
awestroke wrote: post #88

Earlier quoted context omitted.

> It’s cool to see PHP getting its second heyday once again. It’s currently a perfect storm of two communities starting to notice PHP. Really? I see no evidence that this is happening

The Frontend / server less / JS ecosystem craziness and high rate of change has left a lot of devs disenchanted. High profile posts over bundlers, tailwind, and microservices set the scene. A few popular people on Twitter have been talking about Laravel which has influenced other devs. Wind is in Laravel's sails, not php's

PHP has never been replaced as the dominant scripting language for the web.

Re: Go with PHP

#238

Post by jeroenhd »

thaumaturgy wrote: post #186
kgeist wrote: post #57

Earlier quoted context omitted.

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 tha…

FWIW: There are a bunch of ways to "do" php execution, and a lot of them are wrong. That's not exactly PHP's fault, just that there's been a lot of blind-leading-the-blind. Assuming that you're not spinning up and tearing down a container for every request, you want to be sure you're running php with a php-fpm configuration (preferably talking over a unix socket) -- this is the fastcgi process manager, which maintain…

My experience is that Symfony, in its fat, batteries-included form, does take quite long time to initialize on cold caches. The first request can take hundreds of milliseconds but usually the very next request is in the normal 10ms range. This is especially noticeable on (cheap) shared hosting which has always been a common place to run PHP.

I've never found it to be a problem on a VPS but if you're developing on something slow like a Raspberry Pi I can see this happening regularly. If you're used to deploying stuff in containers and constantly throw out the cache the initialisation problem can happen very easily as well.

Re: Go with PHP

#240

Post by tpetry »

mongol wrote: post #68

> It can handle more than 500,000 orders per month when hosted on a $6/month server Is this a statement from the real world? What business sells 500,000 orders in a month from a $6 server? I mean, if you sell that much, you would probably want a high-availability solution and they don't sell for 6 bucks.

The message seems to be targeted at the „webscale“ folks. Something like: Look, one 6$/month server can do more than you ever need. You don‘t need {complicated stack}.

Just use two 6$/month servers.

Post reply on HN