Live data from Hacker News

Go with PHP

gowithphp.com

341–350 of 532 posts

Re: Go with PHP

#341
post #219

Earlier quoted context omitted.

Oppositely: not being able to articulate the problems with PHP/Laravel compared to a stack of say Kotlin/Ktor or C#/MVC or Java/SpringBoot is a red flag too in my book.

Have worked at a few places where PHP was dumped on because “it doesn’t have threads”. The dumper-folks were also noted to be for spending most of their time trying to fix threading issues (Java, usually). Saw this in person twice, have heard similarly from other colleagues over the years.

I agree “it doesn’t have threads” is a bullshit reason. Especially since it took JS's threadlessness to make evented (aka async, aka promise-based, aka callback-based, aka eventloop-based) mainstream, and for good reasons! It allows many to maximize the compute resources better than possible with the threaded approach.

There are good reasons to avoid/switch-away-from PHP... Like weak compile time quality guarantees, messy std lib, low quality of available libraries, many security issues; all WHILE great alternatives exist for free! (e.g. Kotlin, Rust, C#, Java)

Re: Go with PHP

#342

Earlier quoted context omitted.

If you may, could you point out what are the TOCTOU bugs you have mentioned?

Everything between checking if the user can "place-order", and then validating the inputs, and then finally creating the order.

I don't think the request object can be modified by the end user or that it is modified by the server at that point. If my belief is correct, does this code still contain TOCTOU bugs?

Re: Go with PHP

#343
The last time I used PHP was in 2004 or 2005, PHP was at version 4.something, and I did not like it. That kind of formed my opinion on the language, even though I know it's come a long way since. OTOH, I have no reason currently to take another look.

But it's nice to be reminded, I guess, PHP isn't the dumpster fire it was 18 years ago.

Re: Go with PHP

#344

Earlier quoted context omitted.

PHP8. You think it's a red flag when people don't believe that PHP 8 finally got their shit together. What's that George W Bush line, Fool me once, shame on...shame on you. Fool me—you can't get fooled again. But we're not talking about getting fooled just once, or twice, we're talking about eight times .

First off, this comment reveals some ignorance about the language. PHP 6 never existed. Trying to infer anything off version numbers like this is goofy; in a much shorter time period Node is up to v20. Does 20 versus 8 mean anything? No. No one got “fooled”. The got a useful tool that got better over time.

Anybody who believes that this time PHP isn't awful can expect the same disappointment as the last few times. I'm an old man, I remember all the pain of upgrading to PHP3 and for my sins my current work includes trying to cajole somebody's PHP7.x code into running even though it appears their employer disowned the project we know if we don't make it work the "replacement" will never actually materialise.

This is a language built by people who didn't really know any better, so I don't blame them, but it's ludicrous to pretend that it's a "red flag" to have noticed that this keeps happening and learned from that experience.

Re: Go with PHP

#345
post #292
post #253

Earlier 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.

> 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

#346
post #122

Earlier quoted context omitted.

> The documentation reads like a tutorial, which is fine the first time you read it, and really annoying the next 99 times when you're just trying to find something. Ah yes, the Ansible approach. I've used it for a decade, and I routinely get lost in its utterly terrible by-example documentation. They are the golden standard on how not to write documentation. God, I hate the Ansible docs so much, they are the reason…

What is wrong with the Ansible documentation?! Almost all Ansible module documentation pages follow the same structure: a one-sentence synopsis, a list of OS packages needed to be present on the machine where Ansible runs and on the target machine, a table of parameters including aliases, default values and other hints, a list of attributes exported, some notes, and real-world examples. It doesn't get more clear than…

Outside of modules documentation, the rest of Ansible docs are examples. For instance, there is no page where all ways of accessing inventory variables are listed. Or supported jinja filters. They are all scattered in a myriad of examples, which you have to read, carefully, to find what you need.

https://docs.ansible.com/ansible/latest/playbook_guide/playb...

On this page there is no quick index of all the functions available, their argument and a short summary of how they work. You need to synthesize this information yourself by reading through ALL the examples, and hoping your niche use case is listed.

There are more than one type of documentation, with different use cases. There's the tutorial/list of examples, which Ansible excels at, and is ideal for a first timer reading the docs from cover to cover. Then there's the API reference with quick index, for intermediate to advanced users, where they know roughly what they need, they just need to find it. In this, Ansible's docs fail dramatically.

Re: Go with PHP

#347
post #307

"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.

That was a bad way to make the point, because you could serve five orders of magnitude higher with PHP, or node or go or python or pretty much any language right now.

On top of that, You don't need massive k8s infra for any other framework either, so it isn't really a selling point for PHP itself.

Re: Go with PHP

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

[deleted]

Re: Go with PHP

#349
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 the BMX of the languages.

How should I interpret this? The language is cool? Can perform cool tricks?

Re: Go with PHP

#350
post #303
post #292

Earlier 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.

I agree with you. But, and this is a big but, it's a tradeoff. You also get benefits. This is why I said "buy-in". If you are comfortable with doing things in their way, you get a ton of leverage: easily consistent code, a fast and productive "get off the ground" experience. The downside is what you described. Personally I'm just not a fan anymore of these things. You quickly produce code that _looks_ clean and consi…

I've been building on Laravel for some years now and I'm always delighted how you can just ctrl+click and see the internals (and the magic). They're pretty modular and extensible/overridable.
Post reply on HN