Hacker News Reader

Comment by momokoko | Hacker News Reader

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 teams that have a specific need to stay on PHP. I still work on projects with PHP and am thankful it has so many improvements. But in its current form and direction, I'm not sure how it has not become simply a little bit worse version of Java.

View on HN

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 PHP applications to scale vertically to any amount of RAM/CPU, and horizontally to any amount of machines. If you let me free choices I'll do Elixir all day long. But pressed on Java vs. PHP for a web app it's PHP for sure.

"On par with node" wow looks fairly close "on par with JVM" thats a big stretch

Fun stuff here is that PHP hipsters currently gravitate towards node like runtime models. It isn't really eating the platform right now, but I see it as a risk.

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.

Have you ever tried building, deploying and maintaining Java? There is more to a language than the syntax

I have. And honestly, with modern, professional PHP development, most of us are not just FTP'ing PHP code to our shared host to deploy. So realistically, we are dealing with some of that deployment complexity regardless.

The modern Java ecosystem has tooling like Maven and Gradle. IDE support and static analysis in Java is more advanced as well.

As I said above, the additions are fantastic and I think they have absolutely improved the PHP experience for projects where PHP is required. But for new projects, I just do not see deploying PHP vs deploying Java with modern tooling as holding up like it may have 7-10 years ago.

I agree that once you get a certain size of application, you effectively reduce the complexity of deployment to a small portion of the overall work. In those cases, something like Java is probably appropriate. In fact, most companies leave Ruby/PHP for Java service once they mature.

I was more referring to your statement of using Java over PHP. PHP's syntax may be approaching something like Java, but the differences between the languages are still so vast, that they are only similar in syntax.

I'm not one to proselytize since I use a handful of languages every day, but when my Java hat is on, I double click a build target, my software is tested, built, deployed side-by-side with my current production build.

New users are automatically pushed to the new build, and users with existing sessions remain on the previous build. When I undeploy the previous build, the rest of the users start seeing the new build as well.

That's all out of the box with small config tweaks for our environment. It is truly torturous.

What's your setup?

Grails / Tomcat

Java is killing itself at a rate of 6 months. They removed javapackager, which means the official tool to build releases is missing from the LTS version. The EE ecosystem is collapsing thanks to Oracle opposing the Eclipse Foundation, making the quest to build enterprise applications challenging due to namespace collisions and overrides, because of modularisation.

PHP is on this aspect still strong and you can still choose your weapon of choice to build whatever you want and not being hostage of a company.

The only missing part is a good private composer repository for companies who don't release source code.

It looks like Packagist has a private commercial offering: https://packagist.com/

And it even looks like the code for Packagist.org is open source, although not meant for self-hosting as there is no docs, support or BC compatibility guarantee: https://github.com/composer/packagist

You can push libraries privately to GitHub and use with with composer directly, no packagist or anything else required.[0]

[0]: https://getcomposer.org/doc/05-repositories.md

Except PHP is not Java, and it never can be.

What is PHP's multithreading model again? Hotspot VM? NIO?

I'm sure someone will chime in and cite something similar in PHP, but the comparison will be laughable in reality.

I'm not a concurrency expert (haven't had to do much high-performance stuff), but php does have coroutines like go's --if you use swoole, the performance is actually higher than node in some benchmarks and other multi-threaded / parallel programming paradigms, which comforts me to know that if I have the use case it's there, so I don't necessarily need to drop everything and pick up rust or java or go or another language w/ native concurrency models.

Not saying php is better, there's definitely reasons using rust, elixir, et al would be a better decision for scalability/etc... Just saying it isn't as far off from java, and it's getting JIT I believe in 8.0 (tentatively), whether that improves speed/proficiency is yet to be determined.

That said, I've been a laravel dev since 2013, getting a little bored, so have been branching out and toying w/ other things like clojure, elixir, rust, and node.js for backends to web/mobile apps. Though, laravel is easiest/fastest most of the time to get a project completed by myself.

Coroutines do not mean that you get parallel execution. Concurrency is not the same as parallelization.

If PHP does not have JIT, then it's nowhere near the speed of Java. Even if it did, Java would likely beat it significantly. I would encourage you to read about Java's Hotspot VM and its adaptive optimizations.

Multithreading is not strictly parallelism, typical discussions of multithreading regard concurrency, and multithreading is what you initially asked about. PHP 7.4 will ship with a JIT as an experimental feature and PHP 8 will ship with it built in standard.

Multithreading in Java means parallelism, which is what I was originally asking about.

You're confused. Nowhere did I claim that multithreading always means parrelalism.

In my experience Clojure with Luminus is the quickest for getting something up and running. No brittle ORM to deal with - just HugSQL for turning raw SQL into functions.

>What is PHP's multithreading model again

Since it's inception, the PHP implementation hasn't been threadsafe and since, the way of doing paralellism has been process forking. Later iterations where released with support for long-lived processes and threads but it's still not officially "stable" since again, historically the model of process forking made the ecosystem take for granted non-memory safety.

On the other hand, at least since the last time I was doing Java, paralellism is done via multithreading. Sure, there must be someone doing some else out there, but relevant frameworks like Spring work by making 1 thread by http request.

IMHO the right way of dealing with concurrency is the Node way. But comparing the PHP vs Java y think the PHP way is better. In small-medium scale the Java way is obviously more performant. The problem is when you scale to more instances. The PHP way of immutable processes really makes vertical scalling easier.

PHP scales better than Java? Java is only suited for small to medium scale? That's absurd and you are completely wrong.

Java web servers are multithreaded. Java has JIT. Java has a Hotspot VM with JIT optimizations at runtime.

This is why companies like Google and Amazon run their stacks on Java. It scales. Facebook had to write their own fork of PHP due to performance issues.

>Java is only suited for small to medium scale?

Never said that. What I said was that in the small to medium scale Java was obviously more performant because of the persistent instance & multithreaded model. But beyond that it really is no longer true. The immutable "shared nothing" process forking model of PHP scales horizontally very easily.

>Java web servers are multithreaded

this really is a disadvantage when scalling. The default linux thread stack is 1024k for 64-bit VMs, can't find what's the minium if you tweak it enough. You can see how bad that scalles to thousands of concurrent requests.

And then there's containerization and microservices, where each instance needs a full JVM.

>This is why companies like Google and Amazon run their stacks on Java

You can make anything scale with Google or Amazon budgets.

Again, just listing some pros and cons of both approaches, both of which I think are not even the best.

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

Your notion that forked = better is outdated. Running processes has overhead, even with read only shared mem. Micro processes are the way to go, and are being embraced by newer languages. You get min mem and context switching overhead, along with the parallelization of running on multiple cores.

Even so, threads are still going to be lighter weight than forking new "heavy weight" (non micro) processes.

And this doesn't even get into the more efficient compilation. PHP has no JIT yet. There's overhead for type inference. Etc etc

>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 parallel requests will require n threads.

>And this doesn't even get into the more efficient compilation. PHP has no JIT yet. There's overhead for type inference. Etc etc

I don't make any claims here either. Of course Java is faster here. My point was specifically about which model of concurrency and paralellism is better for server IO.

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

> what is the compelling reason to not just pick Java at this point?

Oracle.

The funny thing is, I don’t like java because of all of the historical problems and reputation it has. And I’m a PHP dev.

I really do need to get over all of that and give it another shot.

Reply on news.ycombinator.com