11 ms·
Writing with PHP is better than ever... and getting better and better. And... you don't need too worry too much about the server, or the request lifecycle, or
by ilmiont 7y ago
Writing with PHP is better than ever... and getting better and better.
And... you don't need too worry too much about the server, or the request lifecycle, or networking... you just write your app, in a language which is, in my opinion, going in the right direction with a stronger slant towards OOP and types.
Of course it's still entirely possible to write garbage PHP code... but it's possible to write garbage in anything.
I'm increasingly proud to say I'm a PHP developer; it still gets a lot of bad commentary but it all tends to be based on historical stigmas which are increasingly untrue. Yet all the original benefits are still here, and the language itself is going from strength to strength...
- momokoko 7y agoMy 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.
- ppeetteerr 7y agoHave you ever tried building, deploying and maintaining Java? There is more to a language than the syntax
- momokoko 7y agoI 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.
- ppeetteerr 7y agoI 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.
- runin2k1 7y agoI'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.
- ppeetteerr 7y agoWhat's your setup?
- runin2k1 7y agoGrails / Tomcat
- dominicl 7y agoInteresting 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.
- qaq 7y ago"On par with node" wow looks fairly close "on par with JVM" thats a big stretch
- vast 7y agoFun 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.
- cutler 7y agoI 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.
- IloveHN84 7y agoJava 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.
- frenchman99 7y agoIt looks like Packagist has a private commercial offering: https://packagist.com/ 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 https://github.com/composer/packagist
- bluefirex 7y agoYou 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 https://getcomposer.org/doc/05-repositories.md
- codesushi42 7y agoExcept 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.
- gremlinsinc 7y agoI'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.
- codesushi42 7y agoCoroutines 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.
- kamranjon 7y agoMultithreading 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.
- rodgerd 7y ago> what is the compelling reason to not just pick Java at this point? Oracle.
- skoskie 7y agoThe 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.
- neop1x 7y agoEven the nature of server-side PHP is bad. Running the script like an executable and using opcache on better case is no good. Also it is not uncommon to upload a php shell using some crappy upload.php forgotten script... Come on, it's Personal HomePage language - you shouldn't do anything bigger than your home page in it.