5 seconds per request isn't anything to shout about in 2023.
Laravel gets over 2000 requests per second in PHP 8.1 https://kinsta.com/blog/php-benchmarks/
Unless you specify the hardware and compare with the OP your claims are meaningless.
Go with PHP
451–460 of 532 posts
Re: Go with PHP
#452Earlier quoted context omitted.
> >I couldn't fit the data set in memory with PHP. But I could do it with Go. when would you ever have a website serve a request, and have to use gigabytes of memory to do so? > Consider the following (covers both statements above): you need to get some data from a few sources (databases etc) do some computation on each set and then do some sort of mapping to get the resulting set. You may want those computations to…
>when would you ever have a website serve a request, and have to use gigabytes of memory to do so? I'm pretty sure that PHP is not only used for web sites otherwise comparing to Go is simply meaningless. There is little to no point in using Go to build something with a relatevely low load. >Again, why would you ever have an HTTP server do so much work in order to serve a request? http server != website. You can have…
> I'm pretty sure that PHP is not only used for web sites
PHP is explicitly designed to serve web content. It's usage may vary, but it is unfair to expect it to optimize towards anything but as a web backend.
Re: Go with PHP
#453Earlier quoted context omitted.
Go
If you're going to pull numbers out of a hat at least provide some evidence, especially evidence based on a comparable workload.
I actually wrote a whole article about this myself: https://alicegg.tech/2023/02/06/4dollar-vps.html
TL;DR: go can handle 1000+ RPS on a ridiculously small server
Re: Go with PHP
#454Laravel is probably the top reason why I moved away from PHP to Go. I find it frustrating to have to learn custom DSL and custom syntax to do basic stuff. Which then of course if you learn is going to be useful until the next major version of the framework, at which point you will have to re-learn everything over again. I like how I can just know the Go standard library go into dozens of different projects and still being able to contribute because there are no custom frameworks and DSLs.
Re: Go with PHP
#455Earlier quoted context omitted.
"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.
Boasting about 0.2 requests per second, even on a minimally spec'd VPS, is damning with faint praise.
An "order" would involve far more requests than just one however...
Re: Go with PHP
#456Earlier quoted context omitted.
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.
> PHP has matured and has been a nice language for a decade now. And how did it manage that? Python forced people to deal with encodings properly and the result was a lot of pain. You're claiming PHP somehow invisibly fixed the numerous problems of the language without anybody noticing? That "fractal of bad design" blog post, everything described in it has been fixed? If so I want to learn how they did it. That's som…
> everything described in it has been fixed?
Everything? No.
Much of it? Absolutely (and the more widely a particular point is agreed upon, the more likely it's fixed). The article is eleven years old.
Re: Go with PHP
#457Earlier 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.
Well that depends. There are like a dozen python interpreters and JIT compilers. PyPy is fast, albiet memory hungry.
Re: Go with PHP
#458As 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…
What about people who get their stuff done with mature, well established, and high performant Java and C# frameworks? The benefits of static languages is already established, particularly for longer maintained and larger code bases where multiple people work on them.
Re: Go with PHP
#459Earlier quoted context omitted.
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…
I am certainly not one to defend the new ansible docs, but part of the woes that you're describing are due to the fact they just doubled down on `ansible-galaxy install` based setups, meaning there isn't "an answer" to what filters are available in ansible
The authoritative answer to what filters are currently available in your distribution is by running `ansible-doc -t filter --list` which does include a summary line, although for some of them it's "geez, thanks" just like any open source collection of disparate modules glued together
I used to actually build the ansible docs locally with singlehtml because I despised that chopped-up view, but now that they're all "galaxy all the things" it's practically useless again (although I will also say that building it locally and eliding all their tracking bullshit makes the pages load like a bazillion times faster, so ... still valuable in that way)
Re: Go with PHP
#460Earlier 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…
This comes across exactly what the previous poster was saying as someone who turns their nose up to PHP. Especially the "you have to" gibe. > 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…
I don’t turn up my nose though. I don’t judge anyone for choosing tech, especially if they have good reasons.
I’m also very loyal and pragmatic. I really tried.
I don’t want to start a language war here either. What I said above was a counterattack on the idea avoiding tech that doesn’t agree with you is somehow a red flag.
My general point is: consider that there are people who have earned their opinion the hard way. Even if you disagree.