Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A look at modern PHP

lwn.net

Post reply on HN
Print view View original

91–100 of 610 posts

Re: A look at modern PHP

#91

Post by dep_b »

Tried PHP again (using it since the 3.x days off and on) a few years ago and didn't dislike it. It would be great if types were even better enforced. But then again I could have been working with Microsoft MVC instead and have an even better experience, especially in terms of autocomplete in an IDE (because C# has stronger types and they are more logical to find by trial and error, like typing a . after a string value), something which I highly value.

But I still think PHP is really cool when you just want to hack something together and indeed like many people said before run it anywhere without headache. You can output formatted text really easily. Other languages are way more formal about output. I hacked together a song recommendation and voting system for my marriage website in a few hours and people loved it.

Re: A look at modern PHP

#92

Post by 72deluxe »

I still can't see how it can be "mature" if it offers an iterable returnable type like in the article example yet doesn't indicate the type of the object it is returning!

It has type hints for function parameters and return types but not for arrays. This makes it useless to me.

I know everybody will say "just add comments so an IDE can interpret it" but this should be a feature of the language. Just adding comments to hint to an IDE is not a real solution.

It's still just a vector in C++ parlance. Nobody would take you seriously if you said "just add comments to indicate what your void* might be" in a large codebase.

Re: A look at modern PHP

#93

Post by simion314 »

solraph wrote: post #75
simion314 wrote: post #55

Earlier quoted context omitted.

What do you mean by concurrency here? JS like async or Java/C# like threads? And why would concurrency help in problems where PHP is involved, in the problems I solve with PHP I don't think I ever needed async. For unning more things in parallel like processing 1000 RSS feeds you can spawn 10 scripts that run in parallel and if one crashes the others still continue to work(I had experienced crashes with some RSS XML…

Not the parent, but it would be nice to have separate thread for things like logging and firing events into a queue.

Just curious what problem are you trying to solve, I never had the need for different threads to communicate in PHP, most of the time in my work a user makes a request, and a PHp scripts does something like update the database or does some searching/working and returns a result.

Re: A look at modern PHP

#94

Post by cageface »

simion314 wrote: post #55
cageface wrote: post #40

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.

What do you mean by concurrency here? JS like async or Java/C# like threads? And why would concurrency help in problems where PHP is involved, in the problems I solve with PHP I don't think I ever needed async. For unning more things in parallel like processing 1000 RSS feeds you can spawn 10 scripts that run in parallel and if one crashes the others still continue to work(I had experienced crashes with some RSS XML…

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.

Re: A look at modern PHP

#95

Post by Okawari »

onli wrote: post #61
Svip wrote: post #14

Even with PHP7, PHP still feels like it is playing catch up. There is nothing new or revolutionary in PHP7, just adopting features present in other major languages. Adopting as other newer languages like Go and Rust seems to be moving beyond those features. A catch up into a world that's on its way out, if one will feel so blunt. PHP's raison d'être remains its ease of getting an instance running on a webserver. But…

> But with fewer people self-hosting these days, that has become less an advantage. I don't think fewer people self-host. There are some going to big clouds, there are some using integrated offerings like squarespace, but there are still many hosting their website with a regular hoster. And probably in total many more than in the past. > And even for those who do self-host, the advantage is becoming narrower as other…

I'll concede that PHP focused hosting solutions such as your traditional shared webpage hosting environment is better at hosting PHP than any other language, and sure there are less services out there that lets you deploy code "as easy as PHP".

I had to check and I'm paying about 4$ a month for a traditional PHP server host vs 5$ for a VPS which I can run whatever I want on. And if you want a barebones deployment for lets say rails, what is stopping you from just copying files over with scp and running bundle and rails s from the shell. Then only thing that makes this harder is having to kill the server and restart on deployment. I dont find that to be that much harder.

Re: A look at modern PHP

#96

Post by solraph »

jfkebwjsbx wrote: post #90
solraph wrote: post #66

Earlier quoted context omitted.

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"?

Compile to Javascript, and compile to native binaries supported by the core language team.

Re: A look at modern PHP

#97

Post by mxschumacher »

luckylion wrote: post #73
frenchman99 wrote: post #38

Earlier quoted context omitted.

I remember reading about Ghost.org team members saying that if they had chosen PHP instead of Node.js when they got started, they'd be much further along in their roadmap [0]. PHP has a reliable ecosystem of 3rd libraries with LTS releases. I am not aware of something like Symfony [1] for Rust or Go. [0] https://www.indiehackers.com/podcast/007-john-onolan-of-ghos... [1] https://symfony.com/

Another big bonus for PHP to me is: there are plenty of people who are comfortable with it. Most things aren't genius-scientist-required kind of things where you lock some genius in a room for eighteen months and they revolutionize the industry. Most things are pretty average and you just need somebody with a good understanding of the problem and experience to do them. You'll want plenty of those people to get things…

From a business perspective this might also translate into lower development costs and easier access to talent.

Re: A look at modern PHP

#98

Post by ohmaigad »

echelon wrote: post #83
bzb3 wrote: post #65

Earlier quoted context omitted.

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.

"Vastly superior" how? I can have those features with a tool like deployer (written in PHP) and the only dependency is SSH.

Re: A look at modern PHP

#99

Post by cageface »

solraph wrote: post #66
cageface wrote: post #40

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…

Kotlin is really a fantastic language even without IntelliJ but with IntelliJ it makes these older languages feel archaic. Once you've had this level of explicit typing & null checking, code navigation, and refactoring that really works its very hard to go back.

Kotlin also feels like a pretty safe bet since both Google & Jetbrains are backing it.

Re: A look at modern PHP

#100

Post by fetbaffe »

Svip wrote: post #14

Even with PHP7, PHP still feels like it is playing catch up. There is nothing new or revolutionary in PHP7, just adopting features present in other major languages. Adopting as other newer languages like Go and Rust seems to be moving beyond those features. A catch up into a world that's on its way out, if one will feel so blunt. PHP's raison d'être remains its ease of getting an instance running on a webserver. But…

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, fast reload/build time, built in string templating, simplified variable syntax (auto, var), etc

I can go on, but if you already framed the question to the disadvantage of one party you will not really get a fair answer.

Post reply on HN