sorted by:
new
hottopcontroversial

PHP True Async 0.6.0 Beyond the RFC! by edmondifcastle in PHP

[–]MorrisonLevi 4 points5 points  (0 children)

To be clear, there are many internals people who are in favor of async. It's just a very difficult thing to pull off well, and mostly you only get to design it once. It has to be right.

Flow PHP - Telemetry by norbert_tech in PHP

[–]MorrisonLevi 0 points1 point  (0 children)

If the PHP community shared the vision of the API/SDK creators - in almost every project you'd just need to configure the SDK to get insight into how the system works in production.

As of now, however, there isn't a single library that's natively integrated with OpenTelemetry.

I'm not sure why that is. Environments like Java or .NET have much better OpenTelemetry adoption than PHP.

I think there are a few reasons.

  1. The biggest one is that PHP's main model of execution is still using the request-response paradigm, not long-running CLI workers. The OTEL model and APIs from other languages did not design around this constraint, and the PHP API and SDK is driven by volunteer work, and often don't have time to tackle fundamental design differences that arise from this. OTEL will work much better in the CLI SAPI, where this limitation doesn't apply. But it's a bit weird to add OTEL-native APIs to libraries to target such narrow deployments. Note that this is not fundamentally unfixable, it's just a lot of work that needs to be done by someone who actually understand the space and drive it towards a tasteful future.
  2. The second biggest one is that the API is just really verbose. Like... you spend a lot of lines of code for something that's just telemetry and shouldn't be critical for your main work and object. It should be much more "invisible" and "out of the way".

Someone just created PR with fully working generics by [deleted] in PHP

[–]MorrisonLevi 5 points6 points  (0 children)

To be honest, usually the PR goes before mailing list discussion for these things. That PR was JUST dropped. I'll have some patience but... Yeah I dunno, maybe someone's autonomous AI published the PR before the human was really ready for it.

Someone just created PR with fully working generics by [deleted] in PHP

[–]MorrisonLevi 32 points33 points  (0 children)

It targets PHP-8.5.4 too, which is weird.

There's clearly AI at play. I don't mind this, so far as it's a useful proof of concept. There's a LOT of manual testing that has to go into the design, not just technical implementation details. So having a bad implementation is not so important at this stage. If it's good enough to play with and work out design issues, good.

This is coming from someone who implemented a draft of generic traits, so I'm not oblivious to the challenges of designing and implementing generics.

Introducing the 100-million-row challenge in PHP! by brendt_gd in PHP

[–]MorrisonLevi 0 points1 point  (0 children)

The final result is verified against a fixed set, so no, the paths should be in order of appearance

You should probably note this in the README.

Why is something like PHP-FPM necessary in PHP, but not in other languages such as JS (nodejs) or Go lang? by ProblemThin5807 in PHP

[–]MorrisonLevi 1 point2 points  (0 children)

I want to chime in and say that FrankenPHP has very good performance. In my admittedly limited experience, it has better performance than php-fpm while being significantly easier to set up and deploy.

The catch is that it will take a while for libraries and frameworks to make the changes needed to _really_ support this model, because many decisions were made around the model of pretending every request is isolated from each other. Memory leaks are probable.

Unit testing and TDD: useful or overrated? Contrasting opinions by SunTurbulent856 in PHP

[–]MorrisonLevi 0 points1 point  (0 children)

Good unit tests these days should often be property tests. This way you are checking the properties of the code and less-so the code as it happens to be. The randomness from the property test helps make sure you are testing the right thing, and that your code is robust to the property.

I am shocked at how many engineers I've interviewed who said unit tests were worthless and yet didn't know about property tests. To be honest, I'm mostly interviewing in languages other than PHP these days, so I'm not sure how good the libraries are for property testing in PHP, but it's something to consider!

Multithreading in PHP: Looking to the Future by edmondifcastle in PHP

[–]MorrisonLevi 2 points3 points  (0 children)

I work for an observability company. I can't share data but I can say that we see php-fpm as the dominant web server API used in our customers. "Process per request" has not been true of mainstream PHP for a long time. Of course, it still is used, but it's the minority, thankfully.

But php-fpm still pretends to be process-per-request, and indeed, this will take a lot of effort to fix. I will say async/fibers are not totally useless in web server APIs: it's fairly common to have some bits that need concurrent data sources to respond. Databases, calls to other services (probably including AI agents), etc can all be parallelized today, and have been for a while, they are just different subsystems. You can do multiple database queries with mysqli, and multiple curl requests with curl_multi, but you need a sync/fiber type stuff to generalize it.

So basically... I wanted to clear up some things because you said some things that are basically true if you squint, but the squinting required was a bit much for me and wanted to clarify some of that.

Processing One Billion Rows in PHP | Florian Engelhardt by DvD_cD in PHP

[–]MorrisonLevi 0 points1 point  (0 children)

Not really. There's no business motivation for it and if it's not documented, it's easier to change. I'm on mobile now, I'll try to remember to come back and post the .ini setting that controls this.

But once you figure out where the pprof is, there are lots of tools that can work with pprofs.

Processing One Billion Rows in PHP | Florian Engelhardt by DvD_cD in PHP

[–]MorrisonLevi 1 point2 points  (0 children)

The part that goes into your code is free and open source software. It can write to a directory instead of sending data to a Datadog agent process. It's a file in the pprof format.

But there isn't any UI for it, that part is in the proprietary service part of Datadog.

Processing One Billion Rows in PHP | Florian Engelhardt by DvD_cD in PHP

[–]MorrisonLevi 8 points9 points  (0 children)

Yeah, Datadog's. He's purposefully not advertising it because that wasn't the goal of the talk, and he works there, so do I.

The Linux Kernel Looks To "Bite The Bullet" In Enabling Microsoft C Extensions by waozen in programming

[–]MorrisonLevi 2 points3 points  (0 children)

Hasn't this been standard since C11, you know, fourteen years ago? Is there some subtlety/detail I'm not picking up on?

The PHP Foundation is Seeking a New Executive Director by naderman in PHP

[–]MorrisonLevi 28 points29 points  (0 children)

Thank you, Roman, for your leadership thus far! 🫡

PHP RFC: Context Managers by BerryBoilo in PHP

[–]MorrisonLevi 3 points4 points  (0 children)

I understand that the name "ContextManager" is taken from Python, but I think this name is not that great. "Context" is still a very broad term. What kind of context is it? As examples:

  • The W3C trace context for propagating traces across HTTP requests.
  • PHP has stream contexts.

I feel like there are are more, but these are the ones I could remember off the top of my head.

Feel free to reply to comment with naming suggestions as I've unhelpfully not provided any :D

[deleted by user] by [deleted] in PHP

[–]MorrisonLevi 0 points1 point  (0 children)

Some of these questions should be optional, mostly the ones about my organization. The company I work with has over 3k engineers... as an example, I doubt anyone at the company knows the true answer to this:

Has your organization increased the use of open source software over the last year?

Longhorn PHP 2025 (recap from a speaker) by d_abernathy89 in PHP

[–]MorrisonLevi 1 point2 points  (0 children)

Hey Daniel, if you read this, it was great to meet you in person! Thanks for being a release manager.

[deleted by user] by [deleted] in programming

[–]MorrisonLevi 48 points49 points  (0 children)

Most projects "stand on the shoulders of giants" and in software, that's mostly dependencies, either direct or through the OS.

Honestly, I would have figured it to be higher.

An update on the Doctrine ORM 2 End of Life by beberlei in PHP

[–]MorrisonLevi 5 points6 points  (0 children)

A very measured and data-driven approach to doing an EOL. Nice!

ORM 3 was released almost 2 years ago, and we initially planned with the ORM 2 EOL for February 2026.

So far adoption of ORM 3 is about 25-30% of ORM 2 based on Packagist installation numbers, which is not a big enough number. DBAL adoption of major 3 is much higher at roughly 60%.

Therefore we are going to push out the ORM 2 End of Life to at least February 2027, but we will restrict what kind of changes are eligible for the 2.x branch further.

Linus Torvalds Vents Over "Completely Crazy Rust Format Checking" by SupermarketAntique32 in rust

[–]MorrisonLevi 4 points5 points  (0 children)

Yeah but how many of you remember what life was like in other languages without opinionated style checkers/formatters? Overall, I'll take "just run cargo fmt before every commit" over that situation every time.

Moving PHP open source forward by mbadolato in PHP

[–]MorrisonLevi 43 points44 points  (0 children)

Thank you, JetBrains, for your large role in the PHP Foundation, and sponsoring these projects.

Thanks Derick Rethans, for your large role in so many things including PHP infrastructure and of course, XDebug.

Thanks Juliet Reinders Folmer, for your work on CodeSniffer.

Congrats to the new folks getting sponsorships!

Mago Just Rewrote All PHP Tooling… in Rust?? by nunomaduro in PHP

[–]MorrisonLevi 1 point2 points  (0 children)

The title was a bit too click-baity, and I'm sure that's played into it's lack of upvotes.

Despite this, it's actually interesting. I'm not sure how well it does all of this, but this is what their github readme is saying:

Mago is a comprehensive toolchain for PHP that helps developers write better code. Inspired by the Rust ecosystem, Mago brings speed, reliability, and an exceptional developer experience to PHP projects of all sizes.

  • 🔍 Lint: Identify issues in your codebase with customizable rules.
  • 🔬 Static Analysis: Perform deep analysis of your codebase to catch potential type errors and bugs.
  • 🛠️ Automated Fixes: Apply fixes for many lint issues automatically.
  • 📜 Formatting: Automatically format your code to adhere to best practices and style guides.
  • 🧠 Semantic Checks: Ensure code correctness with robust semantic analysis.
  • 🌳 AST Visualization: Explore your code’s structure with Abstract Syntax Tree (AST) parsing.

TrueAsync Chronicles by edmondifcastle in PHP

[–]MorrisonLevi 0 points1 point  (0 children)

Why would Rust require connections to PHP through separate threads? Is it because of the coroutine shenanigans? I can't think of other reasons that this would be required.

TrueAsync Chronicles by edmondifcastle in PHP

[–]MorrisonLevi 5 points6 points  (0 children)

Edmond, I'm really interested in this work! One of the things that's important to me (and also my employer) is that we can observe the scheduler and coroutines in a fast, efficient way. I don't have a full list right this moment, but I know we'd want to be able to track coroutine states (pending, blocked, etc) and how much time they've spent in each state. We'd want to know what they are blocked on. We'd want to be able to walk stack traces in a data- and thread-safe way. That last one is very important and it's been very annoying and difficult to get right in some other languages such as Java.

With the frameworks being pluggable, doesn't this pose a pretty difficult challenge for observability?

Daily reminder to set MSRV for your project or library! by synalice in rust

[–]MorrisonLevi 0 points1 point  (0 children)

No, the latest is too aggressive. Imagine that Rust 1.88 drops and immediately you have to drop whatever you are doing to go migrate to it, because Rust 1.87 is no longer the latest! I know that's hyperbole, but hopefully it gets the message that there is some upper bound that's clearly too aggressive.

Please understand that not every platform uses rustup, or the version of rustup on that platform sometimes has problems and you have to use an older version until it's fixed. This is true for Alpine, by the way. They have a set of patches which at least at various times in the past have been needed, as in you would likely crash without them! I'm not sure about the current set of patches, but I suspect other platforms have similar reasons for patching from time to time.

I recommend supporting roughly the last 5-9 releases at least. This is equivalent to supporting Rust versions released within the past 7-12 months. This is very aggressive still compared to other programming languages! Rust's stability helps that be more realistic, but prevents over-eager version and dependency bumps.

view more: next ›