Live data from Hacker News

PHP in 2022

stitcher.io

61–70 of 318 posts

Re: PHP in 2022

#61
post #40

Earlier quoted context omitted.

> Why would I choose PHP when starting a greenfield project? Because you don't know better. If all you have is a hammer, everything looks like a nail. Ruby + Rails is miles ahead of PHP + Laravel. If you want more static typing (which I currently believe is a good thing) I really like Kotlin (+ KTor or + Javalin). If you are okay without OO and like static typing Haskell + IHP is pretty complete. If you are okay with…

You can write JavaScript via Typescript, and you now have one of the best and most popular languages there is (including sum types). There are still a lot of warts, but it’s actually a really nice language IMO.

Have you seen ReScript and/or ReasonML? They are much nicer IHMO, but, yes, not as popular.

Re: PHP in 2022

#62
post #52

Javascript is what PHP should be since day 1.

id this why js devs rewrite everything in typescript now?

Because it's flexible and type-safe. You have both productivity and scalability on both syntax level and infrastructure level. It's suitable for 99% of programmers and the businesses for now.

Re: PHP in 2022

#63
post #17
post #9

Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language? PHP is not a likable language but it's probably not going away any time soon. Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course. That, and also the fact that it ma…

Slow change is good for small projects that you want to build once and use for decades without much maintenance.

A language that uses archaic syntax with dollar vars, semicolons, is pretty verbose itself may die before it evolves into something sensible. Not that I believe PHP will die any time soon, but just replying to your "slow is good".

Re: PHP in 2022

#65
if you are working on PHP projects - dont forget to look into swoole/openswoole. all major PHP frameworks are adopting it now.

this way you can do async and build websocket servers and such and build http applications with event loop and without apache/nginx and such. etc etc

Re: PHP in 2022

#66
post #32

Earlier quoted context omitted.

Because it wasn't designed for long-running processes or data processing at first. It evolved a lot, but I don't see it outside of simple backends for websites.

> It evolved a lot, but I don't see it outside of simple backends for websites. I'd say that something like MediaWiki, Wordpress or Drupal exceeds the definition of "simple backend". Personally, I even tend to write shell scripts in PHP simply because the language is far more sane than Bash (and god forbid naked old sh) and I don't have to fight whitespace with Python.

Wordpress is a complex project, but its backend does not require any background processing.

Re: PHP in 2022

#67
post #12

It's still a language that's mainly used for web development, right? Modern websites in big companies require pretty complex backends that require data processing queues and other background activities. Can PHP compete with languages such as Go, Python or Ruby in the future?

I'll take this comment as a genuinely curious inquiry instead of the veiled insult that others seem to be taking it as.

PHP is primarily used for web development, yes. That doesn't preclude it from offline processing, however. It's quite nice for quick file processing scripts.

Modern websites do not necessarily require complex backends. It depends on the site and its purpose. A minimal static site is just as modern as an ecommerce behemoth. Or are you using "modern" as a synonym for "complex?"

PHP can compete with languages such as Go, Python, or Ruby in the right circumstances. PHP has a vibrant ecosystem that Go cannot (yet?) match. It has a different feel that may appeal to people that dislike Python's syntax. It can also compare quite well with Ruby, though Ruby on Rails and PHP on Laravel are almost similar enough to make that contest a wash.

Re: PHP in 2022

#68
post #9

Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language? PHP is not a likable language but it's probably not going away any time soon. Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course. That, and also the fact that it ma…

The big guys, who know what they're doing use PHP because it makes devops stupid simple. Throw it on the server, its ready. That's always been PHP's killer feature.

Re: PHP in 2022

#69
post #40

I started my career in PHP ~15 years ago trying to do OOP in PHP 4.x. That was "fun". In the meantime I switched to other stacks but I've been keeping a distant eye on how PHP was evolving and I still am involved with PHP projects to a certain degree, though rarely at code level. I really appreciate the effort put into fixing most of the things I hated about the language, though at times it felt like the language and…

> Why would I choose PHP when starting a greenfield project? Because you don't know better. If all you have is a hammer, everything looks like a nail. Ruby + Rails is miles ahead of PHP + Laravel. If you want more static typing (which I currently believe is a good thing) I really like Kotlin (+ KTor or + Javalin). If you are okay without OO and like static typing Haskell + IHP is pretty complete. If you are okay with…

No post body was provided.

Re: PHP in 2022

#70
post #9

Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language? PHP is not a likable language but it's probably not going away any time soon. Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course. That, and also the fact that it ma…

Its concept of "one endpoint is one script" is one of its biggest killer features

Is that still a thing in PHP world? I recently ended up working on a 'modern' PHP project using Laravel and it was all routers and views and models and auto-generated scaffolding code, just like Rails and Django. There was no sign left of that 'old' approach.

Post reply on HN