News for hackers. Stuff that matters.

brentroose

I'm biased (I'm a dev advocate at JetBrains), but I also still actively write code and use PhpStorm almost daily.

Yes, we're writing less code, but the job of "a programmer" has always been about so much more than _writing_ code. It's about code reviews, QA, debugging, discovery, and maintenance; much more than the "writing" part. Anyone with production code will agree, I think: the writing part is the easy part. That's where I still very much prefer a proper IDE over a text editor or terminal. I want easy code navigation, I want proper static analysis without relying or waiting on third party tools, I want a visual overview of changes that happened. I want to stay in charge of whatever is writing my code. On top of that, I want my agents to have access to the tools that have made me the most productive developer for years.

Curious about your thoughts?

Re:100M-Row Challenge with PHP on Wednesday February 25, 2026 @03:42PM (#47157567)
The rules state that FFI and the likes isn't allowed because the goal is to do it in PHP :)
Re:100M-Row Challenge with PHP on Wednesday February 25, 2026 @03:41PM (#47157554)
True, it's a bug that I'm going to fix, but it only impacts local test data sets and not the real benchmark :)
Re:100M-Row Challenge with PHP on Wednesday February 25, 2026 @08:32AM (#47151243)
Around 7GB
Re:100M-Row Challenge with PHP on Wednesday February 25, 2026 @08:31AM (#47151240)
Almost all, actually. I wrote about it here: https://stitcher.io/blog/11-million-rows-in-seconds

A couple of things I did:

- Cursor based pagination - Combining insert statements - Using database transactions to prevent fsync calls - Moving calculations from the database to PHP - Avoiding serialization where possible

Re:100M-Row Challenge with PHP on Wednesday February 25, 2026 @08:29AM (#47151217)
The FAQ states that solutions like FFI are not allowed because the goal is to solve it with PHP :)
Re:100M-Row Challenge with PHP on Wednesday February 25, 2026 @05:24AM (#47149753)
A month ago, I went on a performance quest trying to optimize a PHP script that took 5 days to run. Together with the help of many talented developers, I eventually got it to run in under 30 seconds. This optimization process with so much fun, and so many people pitched in with their ideas; so I eventually decided I wanted to do something more.

That's why I built a performance challenge for the PHP community

The goal of this challenge is to parse 100 million rows of data with PHP, as efficiently as possible. The challenge will run for about two weeks, and at the end there are some prizes for the best entries (amongst the prize is the very sought-after PhpStorm Elephpant, of which we only have a handful left).

I hope people will have fun with it :)

Re:Moving PHP open source forward on Friday October 03, 2025 @02:11AM (#45459568)
Out of curiosity: do you know why they pay for it themselves instead of asking their company to do so?
Re:PHP in 2023 on Tuesday January 17, 2023 @06:58AM (#34411485)
The rich ecosystem, the amount of developers experienced with it, ease of deployment and maintenance
Re:PHP in 2023 on Tuesday January 17, 2023 @06:45AM (#34411405)
Yeah, doc blocks. It's a name that originated within PHP a long time ago: https://docs.phpdoc.org/guide/guides/docblocks.html
Re:PHP in 2023 on Tuesday January 17, 2023 @06:44AM (#34411397)
You could probably use GIT commit history as a data source?
Re:PHP in 2023 on Tuesday January 17, 2023 @06:30AM (#34411323)
Thanks! I'm the author of the post and creator of the video :) Appreciate the kind words.

Older ยป