Live data from Hacker News

A look at modern PHP

lwn.net

81–90 of 610 posts

Re: A look at modern PHP

#81
I've been using PHP professionally since ~1999. I remember ripping the Perl fanboys in the early 2000's until the foundations of PHP started to crumble with what are issues that stick in peoples minds today; so I do wonder if we brought it on ourselves sometimes. But PHP moved on carefully to preserve backwards compatibility. I still have a SaaS first developed back in 2005 on the latest version of PHP that's happily ticking over with the minimal of maintenance required - the code base is horrendous but that's because a developer I had with me at the time made a massive case for "software design patterns" that he crowbarred into every nook and cranny regardless of if it was required or not.

I've done things with PHP that would give people nightmares. It's a far more capable language [1/2] than most realise and with version 8 bringing us JIT things just keep getting better. Would I use PHP if I was starting out today? Unlikely, but I know PHP inside out and can wield it to my wicked ends with ease so won't be dropping it anytime soon.

[1] https://stitcher.io/blog/php-in-2019

[2] https://stitcher.io/blog/php-in-2020

Re: A look at modern PHP

#82
post #41

PHP, Python and Ruby all feel to me like last-generation languages. IMO we should be building new frameworks on modern languages that support concurrency & static typing. The most promising new stack I've seen is Kotlin's KTOR framework. Thanks to the expressiveness of Kotlin it's not really any more verbose than something like PHP or Ruby but it's far more powerful and robust.

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.

Bytecode is simple enough to alter at load time. This gives you aspect-oriented programming and instrumentation of everything that statically linked binaries have never offered. And I don't think anything compares to the JVM's GC throughout yet; why roll your own if it's slow?

Re: A look at modern PHP

#83
post #65
post #36

Earlier quoted context omitted.

Most webhosts provide some kind of support for containers don’t they? Perhaps I’m completely missing the point here? I’ll readily admit that Im young enough to have used docker to deploy apps nearly everywhere I worked. Is php useful for ultra low cost websites? Is it low maintenance? Is that the appeal? Genuine question.

Dropping PHP files to a FTP site is as easy as it gets.

That's an incredibly process-immature way of managing deployment.

How do you know what version you have deployed unless you copy everything you deploy to some archive somewhere?

How do you roll back?

How do you find out if you monkey-patched something?

Deploying Docker images or static binaries is vastly superior and no more difficult. It's just a new paradigm.

Re: A look at modern PHP

#84
post #47

If you're starting with WebDev in 2020, choose Go or Rust. Concurrency & safety + simple deployable static ELF binaries > weak typing and legacy bloat.

> weak typing and legacy bloat

Lots of legacy stuff has been removed.

Static typing has been added as a feature back in PHP 7.0.

Re: A look at modern PHP

#85
post #66

PHP, Python and Ruby all feel to me like last-generation languages. IMO we should be building new frameworks on modern languages that support concurrency & static typing. The most promising new stack I've seen is Kotlin's KTOR framework. Thanks to the expressiveness of Kotlin it's not really any more verbose than something like PHP or Ruby but it's far more powerful and robust.

Alas, I feel the same way. After much thought this weekend, I concluded that it was time to move on from PHP. I decided against the any other scripted language (Ruby, Python), as it felt like more of the same. Requirements were strict typing, functional programming support, built-in concurrency, decent library support, and real support for both native and Javascript. It pretty much came down to Kotlin or Rust. I real…

Why not C++ in this area? The more I use PHP the more I appreciate C++'s type system.

Re: A look at modern PHP

#86
post #79

Earlier quoted context omitted.

FYI when you start a PHP project you need to change your dev machine php.ini to be super strict, so all warrnings should just error out. The inconsistency seems to have it's logic and at that time was consistent and made sense, you need a good IDE to help with this. Using PHPStorm and then using PHPDoc to define your functions parameters and return type is a joy, the IDE will catch your type mistakes, show you where…

It never made sense. The original hash bucketing mechanism for the function lookup in PHP was the length of the name of the function, so each new function was named a specific length to ensure the function list was evenly distributed across the hash table.

Can you link or be more clear? I assumed you are talking about the array and string related functions that are not consistent in argument order.

Re: A look at modern PHP

#87
post #19

I use php daily. Mostly Symfony/Laravel stuff. There are still some stuff it needs what other languages have. (Can't really right now remember all the stuff i stumble upon sometimes which gives me the feeling "damn if i could do this like i do it in rust/java/cpp/(w/e)") Maybe the worst thing is the composer (it's slow.)

Try Prestissimo, which enables composer to download packages in parallel composer global require hirak/prestissimo

The dependency solver is what is slow, not so much the downloading.

Re: A look at modern PHP

#88

Whether you like or hate PHP, it has achieved something that no other language has done - made it easy to host a dynamic website or app on the server. Other languages may claim to be 'web-friendly' (e.g. Python, Ruby) but when it comes to ease of deployment, they are anything but 'web-friendly' or easy. This is what programmer and blogger Jeff Atwood - who isn't a fan of PHP - has written about PHP: "If you want to p…

>If you want to get your customers to self-install your software as painlessly as possible, what other language can match or exceed the ease of deployment of PHP? Anything with containers. Docker was a real game-changer here.

For hosting companies, PHP has a unique benefit: A single installation which scales with the load. Most Python, .NET, Java, NodeJS, Docker, whatever require to run a seperate executable for each site permanently (producing a basic workload / memory consumption / security mgmt needs / ... ).

In that sense, PHP is like a early variant of Lambda ;) When there would be a universal, simple-install, simple-use, low-requirement version of Lambda (incl. Gateway etc) we would see a easier hosting market for all the languages beyond the public clouds.

Re: A look at modern PHP

#89
Why do these discussions always end up in some black/white dicotomy? Are there situations where PHP is a valid part of a tech stack? Sure. Are there places where, if you could choose, PHP is not a good choice in the stack, Yup.

My personal view of it is that it is part of our eco-system and will not go away, how eager some of us may be to have it disappear, so seeing it getting better as a platform should make the world a little better for a lot of people that need to use it in systems that are built with parts in PHP.I cant see how that is a bad thing.

The thing I dont understand is, if you for some reason do not like to use a specific language or tech, why bother trying to convince others not to use it?

Few of the people I worked with have only one tool in their belt, and they can work in any language. We all have some favorable setup that we think is best for us/others to use in order to build better software with quicker iterations. But all of us (hopefully) also know that few, if any, stacks are 100% solid and consistent after a couple of years. There is always some parts that we wish would not exist, some script that magically does stuff that we do not dare to touch, some service that is written in some fancy language by that awesome dev that worked here 10 years ago or some really central part of our software that is written in Python, talking to a module written in C that needs to be compiled with a specific compiler that went dead 4 years ago. Even if we dream about the perfect system that just works (LIKE I WANT IT) and has a fantastic setup, it is only at specific snapshots of time systems work like that. Time, people, organizations, product requirements, marketing efforts, buzz, hacks, fixes, playfulness, boredom etc all makes system degrade over time and while it is important to manage these debts, it is more or less impossible to have a system in a state where it will always have the tech stack you want right now. That way, we will always have to address bugs in PHP, old Python-versions, rage over custom compiled nginx or whatever. Whether or not PHP is a good language or not is a meta-discussion IMO. If languages that are used by a lot of people gets better over time, that is awesome in my book. Having a perfect tech stack with only funny/new/fancy/awesome tech is at best an interesting mind experiment.

Re: A look at modern PHP

#90
post #66

PHP, Python and Ruby all feel to me like last-generation languages. IMO we should be building new frameworks on modern languages that support concurrency & static typing. The most promising new stack I've seen is Kotlin's KTOR framework. Thanks to the expressiveness of Kotlin it's not really any more verbose than something like PHP or Ruby but it's far more powerful and robust.

Alas, I feel the same way. After much thought this weekend, I concluded that it was time to move on from PHP. I decided against the any other scripted language (Ruby, Python), as it felt like more of the same. Requirements were strict typing, functional programming support, built-in concurrency, decent library support, and real support for both native and Javascript. It pretty much came down to Kotlin or Rust. I real…

What do you mean by "real support for both native and Javascript"?
Post reply on HN