PHP in 2019 • Hacker News Board

Re: PHP in 2019

#481

Post by codesushi42 » Sat, May 18, 2019, 12:24 AM UTC

bernawil wrote: post #478

codesushi42 wrote: post #477

Earlier quoted context omitted.

You don't seem to understand the basics of how Java web containers work. The thread stack size is irrelevant in most cases. You're going to be using a thread pooled server anyway to handle requests. Conceptually this is no different than using a forked model. You just use a pool of threads instead of processes. Are you telling me that you run a process pool of thousands of PHP instances on a single machine? I hope no…

>Your notion that forked = better is outdated. You're beating a strawman here. Nowhere did I make the claim that it was better. I even said multithreading is more performant. The only claim I make is that immutable and shared nothing model of PHP servers makes horizontal scalling more straightforward. >You're going to be using a thread pooled server anyway to handle requests That doesn't take away the fact that n par…

>That doesn't take away the fact that n parallel requests will require n threads.

What's your point? In PHP's model, n requests will take n processes. There's no event loop in PHP.

The forked model has nothing to do with making scaling horizontally more straightforward. In either scenario, you'll end up running a different process on another machine once you exhaust your resources.

Re: PHP in 2019

#482

Post by cutler » Sat, May 18, 2019, 1:32 AM UTC

dominicl wrote: post #316

momokoko wrote: post #294

Earlier quoted context omitted.

My issue with modern PHP is that it's essentially becoming Java. And with the JVM and the Java ecosystem, what is the compelling reason to not just pick Java at this point? With Java you are basically writing exactly what you would be writing with PHP, except with more language features and the ability to opt into other languages on the JVM like Kotlin and Scala. The modern additions are fantastic for projects and te…

Interesting analogy, performance wise PHP has made impressive progress. On par with node and the JVM. But Java code specifically is just so bloated. And then there is the worker-per-request model in PHP - All resources isolated to a worker and cleanup on exit. This avoids global garbage collection freezes by design. Something you would get otherwise only from Elixir/Erlang natively. Compared to the JVM that allows PH…

I don't get it. Java is bloated but PHP isn't?? PHP has been doing its best since 5.0 to become a Java clone.

Re: PHP in 2019

#483

Post by strictfp » Sat, May 18, 2019, 8:16 AM UTC

wyqydsyq wrote: post #431

strictfp wrote: post #277

Earlier quoted context omitted.

It also allows you to utilize and extend the full http protocol, something which most "serious" frameworks hinder.

PHP doesn't have anything to do with the HTTP protocol, Apache/Nginx/etc handle HTTP and simply call your PHP script with some global variables set to values parsed from the HTTP request

No, but PHP does not get in your way unlike many other web frameworks.

Re: PHP in 2019

#484

Post by cutler » Sat, May 18, 2019, 10:05 AM UTC

mateuszf wrote: post #135

GrumpyNl wrote: post #91

Earlier quoted context omitted.

You can be burned by every program language if you dont know the in and outs. It all boils down to, pick the right language for the job and more important, know the language you choose.

There are languages which have great design from the start though (like Clojure). PHP, javascript are not them. Probably that's the reason why Clojure tends to be in top of the "developer happiness" polls.

.... and the bottom of "jobs available".

Re: PHP in 2019

#485

Post by cutler » Sat, May 18, 2019, 10:15 AM UTC

smolder wrote: post #195

cntainer wrote: post #121

Earlier quoted context omitted.

Well if 80% of the web was running on ruby there wouldn't be any difference. Most people don't understand that 99% of performance issues are not caused by language performance but by bad architecture and bad developers. Always choose the best tool for the job, you rarely get to that scale and quality of software design that only the raw language performance is left to be optimized :)

There absolutely would be a difference. IME, people take this "performance is not a major concern when choosing a stack" thing a little too far and apply it too broadly, often without ever having benchmarked anything. When I can handle 300+ requests per second in one implementation and only 50 in another on the same hardware, that's going to be a big difference in costs that matters for everyone except fledgling busi…

5x-10x differences only exist between statically compiled and dynamically compiled languages. The differences in performance between dynamic languages is marginal. As for Ruby it's now slightly faster than Python for most things except C-based numerics.

Re: PHP in 2019

#486

Post by lazerlapin » Tue, May 21, 2019, 1:32 AM UTC

owenwil wrote: post #2

I've actually been really impressed with Laravel after switching back to PHP for a few projects. Not only is the developer tooling experience some of the best I've experienced, it's just really the only framework I've ever experienced with a high quality ecosystem of tools—from Forge[1], which makes it dead-simple to deploy a Laravel app into production to things like Horizon, for managing Redis queues. A great examp…

Honestly I don't see what's all the fuss about Laravel, especially when you compare it to Django. I mean, you have an admin ready out-of-the-box, and database migrations are automatically generated. Correct me if I'm wrong but, Laravel you need to do those things manually...!

Re: PHP in 2019

#487

Post by bradezone » Thu, May 23, 2019, 9:22 PM UTC

Personally I'm a fan of the Phalcon framework. It's also structured similarly to Laravel/Cake/Rails but is compiled into a PHP module and thus runs super fast by comparison. PHP has certainly improved with the 7.x line so I'm happy to continue using it.

Re: PHP in 2019

#488

Post by matt_wohler » Fri, May 24, 2019, 1:50 PM UTC

exclusiv wrote: post #466

Aeolun wrote: post #424

Earlier quoted context omitted.

I feel Laravel is fantastic for Junior and medior programmers, while Symfony appeals more to seniors.

All the worst projects I've inherited and rescued were Symfony. Developed by senior devs that overengineered. I'm sure newer Symfony is better and there's some good stuff out there but as a decade+ senior engineer I like Symfony components but not the framework. Love Laravel and Lumen and also some of the other microframeworks for some things. Enjoying Laravel Nova right now too.

Perfectly encompasses my experience with it as well. The community of Laravel-focused developers is extremely proactive in sharing best practices and very much encourages simplicity.

Re: PHP in 2019

#489

Post by smolder » Wed, May 29, 2019, 1:25 PM UTC

cutler wrote: post #485

smolder wrote: post #195

Earlier quoted context omitted.

There absolutely would be a difference. IME, people take this "performance is not a major concern when choosing a stack" thing a little too far and apply it too broadly, often without ever having benchmarked anything. When I can handle 300+ requests per second in one implementation and only 50 in another on the same hardware, that's going to be a big difference in costs that matters for everyone except fledgling busi…

5x-10x differences only exist between statically compiled and dynamically compiled languages. The differences in performance between dynamic languages is marginal. As for Ruby it's now slightly faster than Python for most things except C-based numerics.

When you start mixing in things like random number generators, different methods of string manipulation, different data structures and so on, there can be pretty dramatic differences in performance within each category. (static or dynamic) Every language has building blocks that come with it that are far from equal.