Live data from Hacker News

Go with PHP

gowithphp.com

51–60 of 532 posts

Re: Go with PHP

#51
post #17

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

> Laravel is [...] reasonably well documented

Hard disagree. Sorry, I don't have a computer science degree, why does their documentation make that assumption. I find their docs very hard to grok.

PHP.net docs are no-frills no-fuss, straight to the point. Other frameworks are documented very well too, CakePHP comes to mind (at least, when I was using it last in v2 and v3).

I can't say I've read the absolute latest version of their v10 docs, but when I was neck deep in 5.8 I found I had to switch to older versions of the documentation to read up on some of the most basic of Laravel features. eg. What's the syntax of using Form in Blade templates? I had to go back to v4.x docs to read up on it, Blade templating hardly got a mention in v5.x documentation, despite it being critical component in a Laravel application.

If there was a bug in a project and I had management breathing a fire down at me because it's breaking the site / losing sales / stopping monthly reports from going out, I shouldn't need to decode computer science terms, or look through previous versions of documentation to find the solution.

This is why, in my opinion, Laravel documentation sucks hard.

Re: Go with PHP

#52
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…

When are these ever issues? In a real life scenario

Re: Go with PHP

#53

> It can handle more than 500,000 orders per month How many seconds in a month? 60 * 60 * 24 * 28 = 2,419,200. So basically, its performance is at least 0.2 requests a second...

Realistically, and speaking from professional experience of over a decade, "creating an order" can be one of the most complex tasks your frontend part (as opposed to admin/cronjobs parts) of the web app is going to do. It is not a rare thing to see dozens of records in a dozen of tables being created/updated at order creation time. All of these "order creation" examples are super naive. Once you develop for a shop that operates in $10M+/year range (i.e. there was probably time and money to bloat all the user/cart/stock/warehouse/sales/dispatch/marketing operations and metadata), god forbid a shop that has lots of legacy code and data structures, you will be fine with anything around 1s at order creation.

(Not that I want to defend Laravel's speed, it's not really anything to brag about, and the typical "cache everyhing everywhere all the time" aswer is not that useful.)

Re: Go with PHP

#54
Also: lets not forget one very important and under-rated side-effect of PHP -- it lets you write server-side code that can leverage a 'public' address. You might think 'well, doesn't everything let me do that?' Not quite. On 'free' VPS servers they usually have 'ephemeral' IPs or IPs that change. So while you get free bandwidth and compute -- it's hard to actually do anything useful with it like run a service if you don't have a public address. With PHP it's assumed it will be accessed from the web so if you run it on free shared hosting you get that accessibility built in.

PHP is very good for writing services that cost literally nothing because you can run it on free hosts like 000webhost that give you everything you need to host complex services (upload, database, sub-domains, and more.) It's perfect for budget devs or maybe devs that want to make their infrastructure more resilient to ah... financial upsets...

Re: Go with PHP

#55

> It can handle more than 500,000 orders per month How many seconds in a month? 60 * 60 * 24 * 28 = 2,419,200. So basically, its performance is at least 0.2 requests a second...

I have a client that handle peaks of 7k requests/s using php-fpm + nginx + MySQL. Using their own custom framework in PHP.

It all sits in a single 5 year old machine with 8 cores and 16GB RAM. Their bottleneck is actually MySQL but they have room to spare so no need for upgrades right now.

Re: Go with PHP

#56
post #46

I agree with the message, but the example has: - hidden global state - arbitrary string literals Is that Laravel?

It's been a long time since I had to deal with Laravel, but that code snippet looks very similar to the Laravel version I had to work with ~6 years ago.

I hated it (Laravel) for those reasons, along with the madness that was the DI container. Guess I'm just not "web artisan" enough.

Re: Go with PHP

#57
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 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.

Re: Go with PHP

#58
post #17

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

> it's typed (now) To note, you'll need strict mode for type hints to be useful. https://www.php.net/manual/en/language.types.declarations.ph... The fun part is, instead of going for a generic strict mode system we would have expected, PHP went pragmatic: as most application won't be 100% strict typed, you need to declare it file by file, the icing on the cake being that the restriction applies on the caller of the f…

> To note, you'll need strict mode for type hints to be useful

This is not really true — those type hints can be read by static analysis tools, preventing you from many of the issues that would also be caught in strict mode at runtime.

Re: Go with PHP

#59

> It can handle more than 500,000 orders per month How many seconds in a month? 60 * 60 * 24 * 28 = 2,419,200. So basically, its performance is at least 0.2 requests a second...

While 500k order does not sound as much - you have to remember an order != a request.

Not to mention that as long as you have a direct sync query to a database - your code will have to wait, lol.

Re: Go with PHP

#60
post #17

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

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…

I love PHP, but a red flag?! If they’re busy in the Ruby/Java/C#/Go worlds (all get-it-done environments) then I’d just assume they don’t read many Hacker News praises for PHP. It’s easy to have not encountered it since the bad old days unless you work on a team that uses Laravel for some things.

I do understand hiring someone who has that tradesman programming ethic and is comfortable with Linux, but that’s more requiring certain positive traits.

Post reply on HN