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…
PHPs language peers are things like Python and Ruby, both of which are slower.
Go with PHP
351–360 of 532 posts
Re: Go with PHP
#352"500,000 orders per month" That's like, what, 12 orders per minute? Is this meant to be impressive or something? I bet any language run on a modern laptop can handle that.
"when hosted on a $6/month server" Dropping half a sentence will often make it sound goofy, yes. The point being made is "you don't need a massive K8s infrastructure to handle hundreds of thousands of orders a month". Most people don't; https://www.joelonsoftware.com/2001/04/21/dont-let-architect... is an oldie but a goodie on the subject.
Re: Go with PHP
#353"500,000 orders per month" That's like, what, 12 orders per minute? Is this meant to be impressive or something? I bet any language run on a modern laptop can handle that.
"when hosted on a $6/month server" Dropping half a sentence will often make it sound goofy, yes. The point being made is "you don't need a massive K8s infrastructure to handle hundreds of thousands of orders a month". Most people don't; https://www.joelonsoftware.com/2001/04/21/dont-let-architect... is an oldie but a goodie on the subject.
So with hardware specs better than the Chinese laptop I bought second-hand for 150 EUR (which has a Celeron J CPU), the very same one that can serve 2000 req/s on Elixir and 5000 req/s with Rust, then?
Sure, waiting on the DB is often 95% or more of the request, I get it, but 0.2 requests per second (which is the 500K orders per month when you do the math) is nothing to brag about regardless of which language or DB are being used.
It's even below the level of having a bash script doing the heavy lifting.
Re: Go with PHP
#354As a fullstack developer who has worked many, many years in the javascript hellhole, I mean ecosystem, as well as the python ecosystem and .NET; coming back to PHP the last 2 years, working essentially in Laravel and the like - I couldn't approve more of this message. Seriously, PHP is the grand father that will drive you to class and you'll never be late, the car will never smell and everything will always just be f…
The NPM/JS/TS hellhole is real. Moved on from it a couple of years ago, and today I switch between Go and PHP (WP custom stuff). Obviously Go and PHP are two very different languages but they bring me peace in ways JS never did. Especially when reopening older projects.
Re: Go with PHP
#355Earlier 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…
> 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 their own amusement vs. what the business needed, etc. etc. Red flag. I get that you are arguing from personal experiences, people you met and worked with. But this statement lacks context and nuance. There…
Those resonate with me reminding menof some of the worst development experiences in my career. Different language, different domain, but I recognize it. The simplicity is alluring, and even enticed me at first. It just doesn't scale for problems that are complicated vs the ones you are shown as marketing. The managers and architects like it because it hides the confusing or non-elegant details from view, but that just makes it hard for the devs to work on it.
Re: Go with PHP
#356Earlier quoted context omitted.
Just made the same comment and deleted it seeing that you already stated it. Protecting against all of these is hard and no tech is going to automatically protect for all of this on its own. Such a weird statement to make that takes away from the message of the site entirely.
Rails does a pretty good job.
Re: Go with PHP
#35715 years later I joined a marketplace startup that was doing 10,000 transactions a day.
Built as a PHP monolith.
I was sooooo confused at first. “PHP??? That strange language I used to host a forum is powering this app??”
Turns out the founding engineer was self-taught and PHP had the most tutorials or something lol
Re: Go with PHP
#358Earlier quoted context omitted.
> magic framework stuff that Laravel/Symphony provide The magic in these frameworks is evil, and likely a big part in ruining PHP's reputation. Laravel in particular hides way too much stuff behind magic, and when it goes wrong you find yourself sifting through OOP-obfuscated layers of framework and libraries just to find out how exactly your controller is called.
> when it goes wrong you find yourself sifting through OOP-obfuscated layers of framework and libraries just to find out how exactly your controller is called. debug_backtrace() has always been my friend in situations like this
Re: Go with PHP
#359Earlier 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…
> 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 their own amusement vs. what the business needed, etc. etc. Red flag. I get that you are arguing from personal experiences, people you met and worked with. But this statement lacks context and nuance. There…
> But there are many who have so many battle scars and war stories with the language and its ecosystem that they decided it's just not worth the pain anymore.
I could say the same thing about javascript from the early days, through Jquery, and beyond. Should I turn my nose up to modern javascript because of the past 2+ decades I've been working with it? No because they are "outdated reasons" as you say
> The effort required to make PHP work with you, in comparison to other languages, becomes too large and painful. I'm not talking about superficial things here, nor do I have the tendency to overengineer stuff, quite the contrary. I'm talking about writing simple, robust and efficient code.
Do you have an example of this?
Re: Go with PHP
#360Earlier quoted context omitted.
> 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 their own amusement vs. what the business needed, etc. etc. Red flag. I get that you are arguing from personal experiences, people you met and worked with. But this statement lacks context and nuance. There…
> magic framework stuff that Laravel/Symphony provide The magic in these frameworks is evil, and likely a big part in ruining PHP's reputation. Laravel in particular hides way too much stuff behind magic, and when it goes wrong you find yourself sifting through OOP-obfuscated layers of framework and libraries just to find out how exactly your controller is called.
Have you actually used Symfony?
It's an absolute pleasure in its domain and includes rich debugging abilities through its dev toolbar.