Is it possible to write long-running processes well in PHP today? Is the memory management of PHP up to the task? Or is it all a *cgi-based execution model? This question still is what makes it hard to place PHP. Basically all "high perf"/"high load" applications of it I know about run under PHP-FPM or webserver modules or uwsgi.
A look at modern PHP
151–160 of 610 posts
Re: A look at modern PHP
#152I'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…
> 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.
So just out of curiosity, if you hypothetically did start learning web development today from scratch, what would you spend time learning instead of PHP?
Re: A look at modern PHP
#153Earlier quoted context omitted.
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.
This.
I was using TypeScript for anything that looked like I'll be the sole maintainer but for something that could last for 10+ years, I started it out as PHP as I may not be the only maintainer one day and can't ask the client to look for more specialized talents for no good reason.
Re: A look at modern PHP
#154Earlier 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.
If putting a job/event into a queue, or writing a log entry is taking so long that you need a separate thread just to enqueue/log that entry, something is dreadfully wrong with your application.
Re: A look at modern PHP
#155people make fun of php all the time... just see the comments in this thread. people forget though that wordpress, drupal, joomla and magento are all written in php and most likely accounts for 70% or so of all the websites online today. php is going to be around despite all the negativity and fanboyism of other languages. you can't go wrong with knowing php if you always want something to fall back on if you need a j…
I am a PHP dev with 12 years of experience. I think I have been unemployed 1 week total.
Re: A look at modern PHP
#156Why 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 wo…
As soon as you hit a certain level of complexity in your solution/software/whatever, you will be using multiple languages. You'll have scripts written in Bash, front-ends using PHP, back-ends using C or whatever. You are definitely correct that there is no black and white here, all software just needs to be "good enough" to actually solve a problem and be worth paying for.
If PHP being slow stops you from being "good enough" then it's very likely that you can just isolate the part where PHP isn't doing a good job, re-write that in another language and keep the parts where PHP is working fine.
Re: A look at modern PHP
#157Why 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 wo…
> 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?
Because, if others use it, I have a higher chance of also having to use it.
I do not use Java and JS at work because of my like or dislike of these languages; I use them at work because, many years ago, whoever started the project I'm working at chose these languages. Had they chosen Python or Ruby or C# or anything else, I would have to use these languages. And it does not apply only to work: if I want to contribute to the Linux kernel, I have to do it in C; if I want to contribute to LibreOffice, I have to do it in C++; if I want to contribute to MediaWiki, I have to do it in PHP; and so on.
Convincing others to not use a poor language reduces the chance of myself having to deal with it later.
Re: A look at modern PHP
#158Earlier quoted context omitted.
Generally lower quality talent. That's half the reason PHP got its abysmal reputation. Brilliant programmers using PHP must be annoyed that they're thusly tarnished. I suppose that's not so different from JS. To the flames with both of them, though, I find them genuinely depressing languages to work with.
> 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, actually. Oh well. :'). You make a perfectly reasonable business point.
Re: A look at modern PHP
#159so is PHP worth learning right now? and what is the job prospect looking like? if I study the language for the next few months what is the lickely scenario I will find a career in it.. I actually enjoy and like PHP unlike other people idk what it is about the languauge it looks fun and enjoyable to play with . Plus it's simple and easy opens doors to more complex languages later on down the road
> what is the job prospect looking like? I hope you like working on legacy projects full of spaghetti code.
In that case it really doesn't matter where you work.
Re: A look at modern PHP
#160Even 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…
> 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.
Of the first programming languages that cater to novices to some degree (which is important to project health, because excessive gatekeeping is toxic), PHP was the first to make Curve25519 and Argon2id widely available (through the sodium extension). (7.2)
Even with the "just use FFI" mindset of other languages, the experience is janky at best.
For example: Before sodium-plus [1] came along (which was something I created, so I'm removing it from the table for my criticism of the JS crypto ecosystem), JavaScript required knowing which of the following packages to install: [2] [3] [4]
There was no guidance available anywhere. Some of these APIs were suitable for browsers, others for mobile devices, and still others for server-side JavaScript. And their APIs were subtly incompatible with each other.
Java's in a similar situation [5] today.
> Java (Java Native Access): libsodium-jna
> Java (Android): Lazysodium for Android
> Java (Android): Libstodium
> Java (Android): Robosodium
> Java (Android): libsodium-JNI
> Java: Apache Tuweni (crypto module)
> Java: Lazysodium for Java
> Java: jsodium
> Java: Kalium
Yikes.
With PHP7, you just had to update to the latest version (and make sure your OS package vendor isn't huffing or eating glue, which was rare but still existent) and you had it.
There are probably still languages and runtimes today that make using modern cryptography (Ed25519, X25519, etc.) a miserable experience.
Miserable experiences moving to modern cryptography keep peoples' projects trapped in an early 2000's RSA-PKCS#1v1.5 + AES-CBC hellscape reminiscent of SSLv3 but somehow worse.
Thus, I would argue that what PHP did with libsodium counts as revolutionary.
Your move, $languagesThatHackerNewsFindSexierThanPHP
[1]: https://github.com/paragonie/sodium-plus
[2]: https://www.npmjs.com/package/libsodium-wrappers
[3]: https://github.com/sodium-friends/sodium-native
[4]: https://www.npmjs.com/package/sodium
[5]: https://libsodium.gitbook.io/doc/bindings_for_other_language...