[normaljoe]

Tooling is not the issue here, nor is autoloading.

ISO C and C++ doesn't provide tooling, nor should any language. Tooling is better handled by third parties and implementers. Language should be focused on application and execution of the language. Unfortunately for PHP the language and implementation are tightly coupled as is Java and Swift.

A well constructed modern PHP project using composer has the tooling needed to statically validate. Personally I use PHPStorm but I also use IntelliJ for Java and Android. There are others out there as well.

Autoloading used correctly is no more than Java using a package line or namespace.

I find no problem with TypeScript and others. I however have a 10+ million line code base of PHP that predates TypeScript and others and needs to get a viable transition path. This gets things closer with real type errors at runtime. That is way better than my mainframe COBOL counterparts who have no path forward at the level of modern code.

[j_jochem]

Tooling inside IDEs is somwhat useful. But being able to just run a compiler-like CLI tool to tell you if there are type errors in your program is much more useful still, since you can run it in pre-commit hooks and on the CI. As far as I know, a tool which can do this _without_ requiring extensive configuration and without throwing false positives does not exist yet for PHP.

As for the "language shouldn't provide tooling" argument: You picked C / C++ as a positive example for this. Those are standardized languages which evolve at a glacial pace. For most of their use cases, this is a good thing. But I'd say PHP's faster evolution over the last decade was the right thing for that language. Other modern language projects seem to follow a strategy of a single standard implementation with extensive tooling pretty successfully (e.g. Go, Rust, Swift, ..).

[cutler]

10+ million lines of PHP? What kind of hardware is required to power such an elephant?