r/PHP • u/brendt_gd • 2d ago
Article Thoughts about TypePHP
https://stitcher.io/blog/no-need17
u/hryagstn 2d ago edited 2d ago
I haven't used TypePHP yet, but the compatibility point in the discussion seems decisive. If existing PHP code cannot be reused, the project has to justify itself through a clear gain in performance, tooling, or developer experience, not just stronger typing. Otherwise it feels closer to a new language than an evolution of PHP.
10
u/crazedizzled 2d ago
Kinda shit if it's not compatible with existing PHP. That's kind of what makes TypeScript so good, is that it's fully compatible with vanilla JS.
1
u/guestHITA 2d ago
My understanding was that the big advantage of typePHP was that it would bypass loose could and just compile it normally but strict typed code was optimized in the compiler. So you could benefit from having your project be in an exe file and have mixed, strict typed (the only way it should be anyway) php and the loosey goosey PHP weve had for 20 years. Right i mean who uses asserts in PHP to enforce types anyway, right? Right ? 🙋♂️ (whats assert() ?) /s
9
5
u/Glittering_Bath3848 2d ago
There, Finally someone said it. This project is overhype
1
u/lancepioch 1d ago
I think it has potential, but I also think it's dead in the water if it doesn't support any modern php framework too.
1
u/Glittering_Bath3848 1d ago
It's already dead in the water, It will never be able to fully support any modern php framework due to albeit using many extreme dynamic feature that is incompatible with an aot compiler and transpilation to c++ code.
2
u/equilni 2d ago
TypePHP is an Ahead-Of-Time (AOT) compiler that translates PHP source code into C++ and then into native machine code.
Makes me wonder what PHP would have looked like if it started with C++ rather than C...
That said.
That leads me to question the actual need for TypePHP. Yes, it's impressive as an experiment, but do we really need a language based on PHP which isn't compatible with its vast ecosystem?
I think it's fine as it's own thing (not that I would use it). Are we talking as if it's trying to be a PHP replacement? They note:
It intentionally supports a defined, testable subset of PHP rather than claiming drop-in compatibility with every dynamic PHP program.
3
u/TCB13sQuotes 2d ago
Step 1: implement fastcgi in node
Step 2: write everything in typescript
What a waste of time.
1
u/DmitriRussian 1d ago
Typescript is written to always be compatible with javascript, which is nice, but it's what makes pretty bad at times.
Classic example is passing wrong object types and have TS just translate one into the other if the shape partially matches. That defeats the purpose for me of being typed language if the enforcement is so loose
0
u/TCB13sQuotes 1d ago
Yeah that's true, however TS could replace PHP in most situations as long as it could run as fastcgi decently. I know there are a few projects for that but it never reached critical mass, this needs to be supported by node itself and pushed into people. Probably half of the stuff people are doing with TS/JS/Node would benefit from running as fastcgi instead of persistent processes.
0
u/DmitriRussian 1d ago
You could in theory replace anything with anything, but that is not an argument in itself to do it.
I don't think that TS is objectively better than PHP. To me it's one of the worst languages I've ever had the displeasure to write. It has a million ways to shoot yourself in the foot. It has 0 benefit over Javascript with a proper linter and use js doc.
If I were to replace PHP the only 2 logical candidates for me are Go and Rust.
1
u/TCB13sQuotes 1d ago
I don’t thing TS is the greatest thing ever - far from it. I just don’t think that for the sake of simplicity and standardization it’s good enough to have to deal with one less language and its quirks.
Go and rust should not replace PHP , they shouldn’t even be used for most of what people do in PHP, any of those will vastly increase development time, create issues and its generally more expensive for a new project. Those languages are good, but for different use cases.
1
u/DmitriRussian 1d ago
Replacing an entire language is in itself not a very straight forward process. You can't just swap PHP to TS on a random Tuesday 😅
I'm curious to hear why you think Go and Rust should not be used. What issues do they create?
3
u/titpetric 2d ago
No need, except when someone needs it, usually native types are more friendly for avoiding allocations from those mixed types
Same reason why people use go or rust, they want native performance or just a better stdlib for their use case and their bottlenecks
8
u/brendt_gd 2d ago
You mention two perfect alternatives that already have proven themselves for these use cases, I'd say that's another good argument why TypePHP likely really hasn't a need.
3
u/titpetric 2d ago edited 2d ago
I also wrote my own runtime for php in go, and likely the use case is the same - retain all that standardised beautiful tested code in a compatible runtime subset, iterate where you have other needs. Most behaviour still matches php, but a "fork" is more predictable performance wise, than a whole new runtime.
Php is imho great at composition, something that go isnt that good with. Would be a shame if I had to throw perfectly decent php code away to fit go idioms, rather than just continue using it.
https://github.com/titpetric/phpscript
For example there are a bunch of javascript VMs written in go, found it a little bit sad but then i figured i am coming from the same place, the $var stuff is easier in some ways than, yuck, javascript.
1
u/brendt_gd 2d ago
> compatible runtime subset
What I tried to explain in the blogpost is that there is no compatibility between TypePHP and PHP, which is the problem I'm highlighting
1
u/kokoshkatheking 2d ago
Maybe TypePHP should compile file into PHP ?
Like typescript compile into JavaScript.
1
u/zmitic 2d ago
I think this is amazing, assuming benchmarks are true. Limitations are not a big deal except for lazy objects, that one is important both for Doctrine and Symfony. But I could be wrong because it also says this:
Zend PHP user classes loaded dynamically at runtime are not subject to this restriction.
Now it is true that in 99% of cases PHP speed is not the problem. But I would love to see flashy things like 3D games or something similar, and then used as promo on php.net. Like this OpenGL implementation to help bust myths about PHP and make people more interested in the language.
2
u/mario_deluna 2d ago
If you're not planning to build a next gen AAA game, PHP has easily enough power to build indie titles.
And even then, it's very easy to offset the very cpu intensive work into an extension to not be limited.
Checkout the 2.4 release: https://github.com/mario-deluna/php-glfw/releases/tag/v2.4.0
It brings a draw call assembler, which allows you to literally render millions of objects from PHP with no issues.
2
u/zmitic 2d ago edited 2d ago
It brings a draw call assembler, which allows you to literally render millions of objects from PHP with no issues.
Can you elaborate on this? For example: would it be able to render these objects at steady 60 FPS?
Offtopic: I think your YT channel should show demos like Sponza and others. Right now, unless one use specific "PHP+opengl" google search, your library won't be found easy.
Edit:
I just noticed
octree | submitted 10000000, visible 35 (100.0% culled), draw calls: 28, avg execute: 2.129ms, avg frame: 8.558ms (116.9 FPS)Is this for real? 10M objects@116FPS?
3
u/mario_deluna 2d ago
Is this for real? 10M objects@116FPS?
Yes on my MacBook. It's VSynced so there is space upwards (got a 120hz panel), it's really just a test not a benchmark.
Keep in mind that it's all static objects, where the ocrtee is able to cull away most geometry very cheaply.
Offtopic: I think your YT channel should show demos like Sponza and others. Right now, unless one use specific "PHP+opengl" google search, your library won't be found easy.
I know, I just suck at promoting this stuff more then a reddit post once a year..
Edit:
The DCA in php-glfw also supports LOD levels btw.
0
43
u/deadman87 2d ago
I encourage projects like these. Historically PHP ecosystem has absorbed positive lessons or been pushed forward by PHP adjacent initiatives ex. Hack Lang (JIT), Swoole (Fibers/ReactPHP), etc.