Live data from Hacker News

A look at modern PHP

lwn.net

191–200 of 610 posts

Re: A look at modern PHP

#191
post #41

Earlier quoted context omitted.

Nah. The JVM must go; we have Docker and the universal platform are Linux ELF binaries so the entire "bytecode" concept makes sense for the compiler (i.e. LLVM), but no longer at runtime. It's just bloat.

Kotlin native might eventually make the JVM superfluous but for now there are a lot of benefits to being on the JVM including great performance, a huge ecosystem of Java libraries, and very battle hardened monitoring and debugging tools.

> Kotlin native might eventually make the JVM superfluous

That is probably never going to happen. GraalVM native images are a more realistic approach in this space, and even that is not trivial in most cases.

Re: A look at modern PHP

#192
post #44

Earlier quoted context omitted.

Did you actually read the article or just the headings? Any features that pre-date 7.x are discussed as being 5.x features and, where applicable, the author expands on how it's been further refined / improved upon in 7.x releases

Yes I read it, why accuse me of not doing so? The main block of sample code is highlighting OOP features in PHP, but PHP has had most of those features since 5.3, e.g. namespaces, so my point still stands. Those features are not part of "PHP showing its maturity in release 7.4", but have been around since at least 2009, so why lead with that example?

The article says those features are from PHP 5:

When objects were first introduced in PHP 4, the implementation was essentially an array with function references and was horribly problematic. The fundamental problems of that implementation were thankfully addressed with the release of PHP 5, featuring an entirely rethought object implementation. In the versions that have come since, up through version the current 7.4 releases, numerous interesting language features for object-oriented programming (OOP) have emerged.

I suspect you're narrowing the scope of what this article was intended to cover. It is not just a look at PHP 7.4; it's just using the recent PHP release as an excuse for a look back at the history of the language:

With PHP 7.4.5 released in April, it's worthwhile to take a look at modern PHP, how it has evolved to address the criticisms of the past, and what lies ahead in its future.

Re: A look at modern PHP

#193

Earlier quoted context omitted.

Wait, Go hasn’t had any revolutionary change since it arrived 10 years ago. It is still basically the same language/package. I’m not saying that is bad, but why does a language need to be constantly revolutionary if it solves what it sets out to solve well? Catch up to other languages? You can easily argue the opposite, that other languages has finally catched up to PHP, ease of deployment, ease of horizontal scaling…

Other languages haven't caught up on PHP about ease of deployment. If you need a fast hot reload, it isn't trivial in other languages. PHP does it with no effort. Save and refresh runs the updated code instantly, not to mention asking people to run PHP app is far easier as every general hosting provider has PHP installed. On the other hand, language structure is quite behind others but can't blame when it had been ar…

Hot reload is trivial in Common Lisp, and only marginally less so in Elixir. Turns out it's just not enough of a differentiator to actually tip the scales.

Re: A look at modern PHP

#194

Earlier quoted context omitted.

Agree that PHP, Python and Ruby Web Frameworks lack modern features. Have you tried Elixir + Phoenix?

Elixir and Phoenix look very appealing but I'm very firmly in the strong static typing camp.

Just a note, Elixir doesn't have static typing like you mentioned, but it does have fairly strong typing.

Re: A look at modern PHP

#195
post #112

The amount of misinformation, false claims and unsupported statements in this thread is mindblowing for the quality that I've been used to see on HN. Here are some facts: - Symfony was the backend framework with the most contributors in 2019 [1] (yes, out of any backend framework written in any language) - PHP has more active contributors than it ever had [2] - Laravel is one of the most used frameworks in the world…

PHP isn't being replaced by Rust or Go. It's being replaced by Medium, Wix, and Squarespace. At this point, the predominant reason it's still undergoing active development is that there is a metric ton of legacy PHP code. As the businesses still using it either mature, evolve, or fail, the need for PHP will begin to dry up. You're defending the language from an emotional standpoint. > choosing php for a new project i…

> As the businesses still using it either mature, evolve, or fail, the need for PHP will begin to dry up.

People have been calling for PHP's death, or saying PHP is a dying language, for as long as the internet has been around.

It's always the same arguments, that $newHipLanguage will replace it.

Then you actually do some research and understand just how much of the internet is still powered by PHP and will continue to do so for the forseeable future.

So, I'm still waiting for PHP's death. Or for this same predictable comment in 2030.

Re: A look at modern PHP

#196

Earlier quoted context omitted.

Anything that will block the server. Fetching data from an external API, doing some kind of expensive computation, sending an email etc. You can either handling this Node style with blocking i/o, throw the work onto a background queue like Sidekiq, or use a language with first-class concurrency support like Golang or Kotlin. To me Kotlin feels like a far nicer and more scalable language than Golang.

I like this about PHP, you don't have a callback hell. I don't disagree with you just sharing my experience here, we might work on different kind of problems.

I work on highly concurrent backends that handle 100k requests per second across a cluster, and PHP will never work in those situations. Any time you have to orchestrate multiple data store or service calls in the background, you don't want to block.

Callbacks are not how you do non-blocking IO. You typically have multiple threads and use constructs like futures or promises to make them easy to manage.

PHP bakes you into a very simple request flow. There's so much more you can build if you get out of that manner of thinking.

Re: A look at modern PHP

#197

Earlier quoted context omitted.

> Generally lower quality talent. Which is totally fine btw. Most work isn't "we're engineering a new motor for a F1 race car", most work is "this car's motor is broken, replace it". You don't need a CS degree and brilliance to write code that deals with databases and APIs, which is the super majority of code. You need smart people that spend a lot of time on difficult problems to create strategies that are easy to f…

Our abstractions become the basis of our imagination - do we want developers to think and experience joy? Do we want their minds to spark and innovate and solve and embrace the full power of computing? Can anything compare with the illuminating glow of a powerful abstraction that reveals a new technique - perhaps not 'world changing' - that improves our software and our programmatic structures? I guess we don't, actu…

And business is, imho, not just "for profit", but society in general. I feel about it similar as I feel about wood working mastery. Creating incredible joints with extreme attention to detail and a lot of experience fascinates me. But to build furniture for more than one person a year, I'd prefer nails, power tools and a bunch of people that are experienced enough not to nail parts of their body to the wood.

If we want to provide something to the masses, we'll have to provide something that can be used by the masses, not just by a highly trained elite. PHP is mass production development. It's not necessarily elegant (though you can do a lot in it, it doesn't have to be as messy as WP is), but it gets the job done AND it empowers large groups by being easy to learn and not requiring advanced understanding before you can actually achieve something with it.

I do still believe that we want experts that do the kind of work you're describing though. But I believe they shouldn't distance themselves from the ordinary people, but instead find their elegant solutions and then give them a handle so that the uninitiated can use them. Tooling is leverage, individually but even more so collectively. Imho, if you're a brilliant computer scientist and you work on "normal" real world problems, you're wasting your talent. Even if you find the greatest thing that runs 100 times as fast as the previous one, you've sped up one thing out of a million. Instead, build something that'll enable normal people to speed up their projects by factor two, your impact will be immeasurable.

Re: A look at modern PHP

#198
post #195

Earlier quoted context omitted.

PHP isn't being replaced by Rust or Go. It's being replaced by Medium, Wix, and Squarespace. At this point, the predominant reason it's still undergoing active development is that there is a metric ton of legacy PHP code. As the businesses still using it either mature, evolve, or fail, the need for PHP will begin to dry up. You're defending the language from an emotional standpoint. > choosing php for a new project i…

> As the businesses still using it either mature, evolve, or fail, the need for PHP will begin to dry up. People have been calling for PHP's death, or saying PHP is a dying language, for as long as the internet has been around. It's always the same arguments, that $newHipLanguage will replace it. Then you actually do some research and understand just how much of the internet is still powered by PHP and will continue…

> It's always the same arguments, that $newHipLanguage will replace it.

It's not that a new language will replace it. It's that the people that hire PHP to solve their problem will now use a platform with no code to manage.

Engineers writing platforms will choose languages other than PHP to write them. You can't spin up multiple request threads to make concurrent non-blocking queries in PHP.

Re: A look at modern PHP

#199
post #112

The amount of misinformation, false claims and unsupported statements in this thread is mindblowing for the quality that I've been used to see on HN. Here are some facts: - Symfony was the backend framework with the most contributors in 2019 [1] (yes, out of any backend framework written in any language) - PHP has more active contributors than it ever had [2] - Laravel is one of the most used frameworks in the world…

Where to begin? - No proper connection pooling with circuit breakers. - No proper multithreading (that works in web environment) or parallelism in general. - Almost everything blocks (even `new PDO('mysql:...')` can block for whatever the execution time limit is, if there is an issue with connection or MySQL server). - Most libraries are implemented in C instead of in PHP, whereas with other languages people try to a…

Something being written in C does not mean "understanding or contributing is close to impossible". That's as much of a boogeyman as I've ever seen.

Re: A look at modern PHP

#200
post #112

The amount of misinformation, false claims and unsupported statements in this thread is mindblowing for the quality that I've been used to see on HN. Here are some facts: - Symfony was the backend framework with the most contributors in 2019 [1] (yes, out of any backend framework written in any language) - PHP has more active contributors than it ever had [2] - Laravel is one of the most used frameworks in the world…

Most of the comments against PHP are from developers that wrote PHPThere are still some issues but considering the current state of language, frameworks, libraries, and the ecosystem, it's very practical and productive environment to build any project.

I've been doing Typescript, Scala, and recently also Go in last few years. Scala and Go have decent language design and I'm a fan of both of them. But, when it comes to productivity and ecosystem they don't come anywhere close to PHP. If I was about to build my own web startup, I'd definitely build it with PHP because I'm sure I could launch it 10 times faster with Laravel.

Post reply on HN