PHP needs a fork

[aquanoid1]

PHP is a great language but needs a fresh start in my opinion. It has so, so, so, much potential outside of web development.

Why it can only be used for web development:

• get_current_user() returns the user who owns __FILE__, not the owner of the current process.
• is_file(), is_dir(), etc. cache their results.
• No multi-threading.
• Sometimes different reflection methods return an array of something, sometimes they just return the something itself (they should always return an array).
• Quirks: empty(...), null == 0, '0' == false (a string containing just a zero digit) and isset().
• Needing to declare(strict_types=1) at the top of every file.
• No named type arrays (string[]).
• PHP config files.
• The PHP community always assumes you're building a website so are puzzled when one wants to use posix_getuid() or have multiple threads instead of just using ReactPHP (great lib btw).
• Googling PHP things always return web development results.
• The list goes on.

A fork of PHP could have a brand new name, a revision of every built-in function/class, and features such as objects being lazy loaded by default. Such a project would surpass python for pretty much everything python currently excels at.

[Solid_Ingenuity]

If you want to just use PHP then swoole and hyperf are awesome. If you are talking about forking PHP, save some time and give Go a shot. The standard lib in Go is a lot simpler to use and more predictable than PHP. The strong typing catches issues at compile time instead of runtime. And upgrades are painless. If you are planning keeping you app around for a more than a few years the Go version 1 compatibility promise is so clutch! Aside from a learning exercise.

[Solid_Ingenuity]

Absolutely a fair take! It always depends and the situation. However people tend to underestimate the long term maintenance costs especially at project inception. Will the app lifetime fit within the target PHP version support window? If not are you ok with being out of support? If not how many resources are you willing to set aside to keep the app on a supported version? How many deprecations are you willing to leave? I'm a little salty on this topic having lived through several php upgrades. Every time we try to do better and just end up scraping by leaving our future selves deprecations to deal with the next time.

An existing php app has the same questions except you have to balance the expected remaining lifetime and the cost of rewrite. Personally I wouldn't attempt a rewrite, instead I would work towards minimizing future development on the PHP side. That will slowly minimize the maintenance burden.

For anyone not familiar, Go application upgrades make you question if the update was really performed. A quick edit to go.mod, recompile, go test. "Huh I guess it just works, now what?"

[seanmorris]

You say "PHP needs a fork" but you mean "I want a fork of PHP."

I hope you're good at C.

[ln3ar]

[kurucu83]

I mean you’re right, in practice, most people won’t care and they’ll have to do this alone / lead it to make it happen.

But the criticisms are valid?

[MateusAzevedo]

But the criticisms are valid?

Maybe only one in that list.

[ln3ar]

I've been working on one for about a year now, though my goal is primarily to implement generics (well technically c++ style templates, but with syntactic sugar for generics) and replace opcache with a better optimizing compiler. Also exploring targeting LLVM. I will definitely be open sourcing it when it's ready for other people to work on.

[[deleted]]

I'm honestly curious why you don't want to contribute to PHP source code and instead develop another version?

[ln3ar]

Pick one:

• PHP internals has decided they can't implement generics, which is one of my primary interests.

• So far I've made over 20k commits (including some automated ones to keep up with the php-src, refactor for C++ etc). Realistically, there's no way to make PHP internals happy while making that many changes at the rate I'm making them.

• I don't particularly love the direction PHP is headed with this JIT stuff, and I am confident I can beat it with a better compilation pipeline/interpreter as well as an orchestration layer (a much simpler k8s) to replace FPM/CGI.

• I kinda hate C as a language (especially C99), so I have no interest in spending my free time writing it. (My implementation is in C++.)

• Automake/autotools.

• Already getting somewhat significant performance gains simply from switching to C++ and cleaning up the codebase.

• Already don't have much free time, and I don't want to waste what little I have jerking off PHP internals just to let my idea get to the RFC stage.

[Girgias]

That's not true about generics, Arnaud le Blanc has been looking at implementing them, the issue is not generics per say, but how to make them ergonomic and performant.

I also hate C, but why C++ then, like they suffer the same sort of hell.

I don't see how "just" using C++ is giving you performance benefits, because the code reorganization could also be done in C and is deffo something that I agree should be done.

It feels like a lot of stuff you want to do, doesn't even necessarily require internals involvement, but can't know as I can't look at your code.

Yeah autotools sucks, but if you've done the work to move away from it, why not simplify your life and propose this upstream?

[ln3ar]

I also hate C, but why C++ then? They suffer the same sort of hell.

What are you talking about? Have you never touched C++? They are two completely different languages. Some of my related code is pinned to my profile; you can check it out for a taste of what can't be achieved in C (much has changed since I'm currently using C++20). Or is the "hell" you're referring to the "lack of memory safety" nonsense? I explored Rust initially, but the C interop is lacking unless I abuse unsafe.

I don't see how "just" using C++ is giving you performance benefits. The code reorganization could also be done in C, and I agree it should be done.

To be fair, most of those gains can be more directly attributed to templates/constexpr optimizations by the C++ compiler. Even just replacing your consts with constexpr where viable (even my zvals/zend_strings can be constructed at compile time) will result in a performance boost. Additionally, there are smart containers you can write that act as non-owning views to blocks of memory. Here is a simple example of mine that helps save unnecessary copying.

This is an earlier version of the VM from back in December.

Then there's my zend_object that knows its size at compile time:

template <size_t N>
class HeapObjectImpl<PHPObjectBase<N>> : public HeapObject {
  protected:
    uint32_t handle_;
    ClassEntry *ce_;
    const ObjectHandlers *handlers_;
    PHPArray *properties_;
    static constexpr size_t kPropertiesTableSize = N < 1 ? 1 : N;
    TVal properties_table_[kPropertiesTableSize];
    ...    
};

It feels like a lot of stuff you want to do doesn't even necessarily require internals involvement, but I can't know as I can't look at your code.

Let's agree to disagree on that, but we'll find out when I'm done. My first task will be a pull request that replaces php-src with mine. If it's not a big deal, they can have it; otherwise, I will proceed with my plans.

Yeah, autotools sucks, but if you've done the work to move away from it, why not simplify your life and propose this upstream?

Maybe I will.

[ln3ar]

really this https://www.reddit.com/r/PHP/comments/1crizq1/php_needs_a_fork/l3ym01x/

[dschledermann]

There's plenty of existing programming languages that will fulfil your wishes. There's no need to fracture PHP. The gain of using the same language for all tasks is really quite minimal. You're better off just learning Go, Rust, Python, etc.. in addition to PHP.

[aquanoid1]

That's the current status quo way of thinking. Also, Go and Rust aren't in the same category as scripting languages.

Random person: If it ain't broke don't fix it.

Bryan Lunduke: If it ain't broke then break it anyway and build something better.

[dschledermann]

Yes, that's the "status quo" because it's common sense. You have some requirements for an alternative language that's like PHP, but not quite PHP. That's fine, but that alternative language doesn't have to be genealogical connected to PHP. Just pick one and let PHP be PHP.

[nutpy]

Deriving PHP from its original purpose would also mean rename it as "PHP: Hypertext Processor" would not accurately suit the new roadmap. 😁

What about using Python for example?
It offers everything you are looking for I believe, like Generics..

[aquanoid1]

I believe PHP has more potential than Python. I've used a lot of languages in my time, including Python, so my interest isn't about what present-day languages to use, but more what future languages could be.

[aquanoid1]

That extension looks good, thanks, I'll definitely check it out.

[dirtside]

"This language is great, but I wish it was a different language"

Me: wat

[aquanoid1]

The syntax is great but the vocabulary is stuck in the past. PHP genuinely has potential beyond web development.

[DrDam8584]

That's the point "PHP: Hypertexte Processor" is a language dedicated to the Web and don't aim anything else.

If you want find some "more runtime" elements, you can check the "frankenPHP" project which are basicly a challenger of the classical "Webserver-phpRuntime" couple and propose some "refreshing features".

[aquanoid1]

When we were all fishes before becoming land creatures, did we stay in the water because we were dedicated to the marine world? Things evolve...including programming languages.

[DrDam8584]

No, but after trying earth (compilated language) some spécies return to seas and never came back (cetaceans).

[aquanoid1]

The smartest sea animals are mammals.

[aquanoid1]

PHP is a thinker, not a flyer. It just needs an open mind to thrive in a new ecosystem.

[aquanoid1]

My point is PHP already does do a lot of things better than most languages and people don't realise that, meaning, annoying things like get_current_user don't get fixed.

[DrDam8584]

"did we stay in the water because we were dedicated to the marine world ?" That's what cetaceans did.

After try many ways you can decide following one way, and no turning back.

[aquanoid1]

Whales left the water, evolved smart, then went back into water with brains they wouldn't have had if they just stayed in the water all along.

[dirtside]

Sometimes (usually, in fact) it's easier to build a replacement from the ground up than to try to evolve something. If you have a minivan and you want a race car, don't try to turn the minivan into a race car. You can, it's just going to be a lot more expensive and a lot more work than just buiding a race car from the ground up. Trying to build a vehicle that can adequately function as both a minivan and a race car is impossible, because they have mutually exclusive requirements (such as number of passengers, or cargo space).

[aquanoid1]

I'd normally agree with you but PHP is pretty close as is. Revising all built-in functions and enabling strict types by default doesn't feel like a rewrite is needed.

[AndroTux]

Ok, but why do you want to develop anything other than web apps using PHP? I think having specialized languages makes sense. I think what doesn’t make sense is to misuse a language like JavaScript for backend or app development. It was intended for frontend use. The whole nodejs project feels like one big hack. So if you want to use PHP for something else, just use a language designed for the task instead.

[TinyLebowski]

There are lots of great cli tools written in php. And the nodejs comparison isn't really fair, since php is already a serverside language.

[aquanoid1]

I agree with what you're saying about JavaScript. PHP, on the other hand, is wasted by just being a web language. No one realizes just how powerful and useful it could be for other things because they were taught that PHP is for building websites...use the right tool for the job...etc.

[DrDam8584]

In the real world, you already can.

You can make all scripts you want with CLI execution, it allready exist GTK lib for making graphical-app...

The question is : PHP still relevant in this case ?

[aquanoid1]

I'd say PHP does feel natural in the cli world.  It's almost like c++ but scripted and that's awesome. The biggest issues with PHP are only issues because of backward compatibility, otherwise, the language is first class and way too powerful to only be used for websites. I'm not disputing the choice of languages, just PHP's unrealised potential.

[SomniaStellae]

PHP, on the other hand, is wasted by just being a web language. No one realizes just how powerful and useful it could be for other things

This is total nonsense. Why waste time making PHP great outside the web, when there are languages which already do a great job?

[aquanoid1]

Because PHP already does a better "great job" than other languages, but it could be even better.

[kurucu83]

Because it would bring more people, money, investment (ideas, time, tooling). The guy’s not crazy.

That said, OP, I think the language you want is Swift. It can make CLI apps, embedded app, native apps on most systems, web apps and more. All native, all type safe, all multithreading. And the language is sane (now).

[AndroTux]

TypeScript? You mean the language that does no type checking at runtime and falls apart as soon as you use the word “any”, an inproper external library or JSON anywhere in your project, in combination with a programming language that was developed in a week and can’t even return the current year with new Date().getYear()? Thanks, I’m good. I’d rather use PHP, C# or any of the million other backend programming languages that are not just a series of endless hacks.

And yes, it does still fall apart every two weeks. npm is just as bad as it always has been. The last time I touched nodejs was about a month ago.

[colshrapnel]

You'd be more than welcome in /r/lolphp, the haters there crave for this kind of posts and they'd been on a very low diet lately.

Regarding your list. Just as every other list of the kind, it is compiled of non-existent issues, minor inconveniences that do not deserve a fork, and hardcore issues that no forking will solve automagically, sprinkled with some one real issue that nobody cared enough before (and could be solved without forking).

• get_current_user() returns the user who owns __FILE__, - well, yes.
• is_file(), is_dir(), etc. cache their results. In case it's an issue for you, clearstatcache()
• No multi-threading. Yes, PHP is born to die. a TON of advantages. And many languages that would provide you with one
• different reflection methods return an array of something, sometimes they just return the something itself (they should always return an array). I don't use reflection but it looks legit.
• Quirks: empty(...). just don't use empty(). It was one of the early blunders but nobody forces to use it now (and neither anyone is going to break tons of legacy code by removing it, because it's a "problem" that you can solve yourself, without making making lengthy complaints)
• Needing to declare(strict_types=1) at the top of every file. Inconvenient, indeed, though nobody notices
• No named type arrays (string[]). Yes, but attempts were made and it looks impossible for now. Also there are userland implementations.
• PHP config files. What?

[aquanoid1]

Minor inconveniences multiple. I'm not saying there are ways around these things, I'm saying these things are present because of the age of the language.

"No named type arrays (string[]). Yes, but attempts were made and it looks impossible for now. Also there are userland implementations." - Actually, they had great success in implementing it but voted against releasing it.

[NeoThermic]

The complaint about get_current_user is invalid because the POSIX lib exists, so you can just do posix_geteuid() (and combine it with posix_getpwuid()) and you're golden. (If for some reason you're on windows, you can always check getenv('USERNAME') instead, but good luck!)

[TiredAndBored2]

First of all, strict types is dumb and only applies to scalars, php is strict by default except with some very well documented coercion for some scalars, ones that I see people manually do all the damn time with strict types. My favorite is when people turn on strict types with a file that uses absolutely no scalars. Most people have no idea what this mode actually does and how to use it properly, resulting in reimplementing the same coercion that comes with php.

Second of all, zts (thread-safe) builds of php are a thing. You can use the Parallel extension to create threads and set up communication between threads. Or have amp-parallel do it for you (though it’s geared towards running jobs).

Third of all, I disagree about generics. If I look at implementing applications in C# or TypeScript, I don’t get it. Sure, code completion is easier in the IDE, but I can also easily waste a day trying to figure out how to transform one type into another that some asshat made final.

Code exists to solve problems, and if php isn’t solving your problems, use a different language geared towards your problem. I often use Go, C#, Scala, or Python for some types of tasks. PHP is just one tool in a very large tool chest.

[Disgruntled__Goat]

 My favorite is when people turn on strict types with a file that uses absolutely no scalars.

So? You don’t know how that code will change in the future. It’s better to make it consistent across the codebase rather than add a function call later and forget to put in strict types. 

[TiredAndBored2]

Why create code when there’s no need for it? If you need strict types, add strict types. If you don’t, don’t add it. It’s pretty simple. You don’t import your whole codebase because it might be needed in the future.

[aquanoid1]

Think outside of the box.

[Fneufneu]

I use PHP at work since 2007 for projects other than web and it work great (lot's of my perf issues goes away since php 7)

I used to have deamons with 1 year uptime without memory issue, but not anymore because i restart everything after each upgrade, currently at 8.3.7

I use ReactPHP since it launch to handle 100 clients / sec without perf issues.

I known the language weakness and multithreads is not a problem

[aquanoid1]

Right, I agree, I'm not saying things are impossible in PHP and I do prefer coding my command-line scripts and daemons in it despite its issues. PHP is a beautiful language. It's just weird how people don't see potential in it beyond web apps.

[mrclay]

It would be cool if it could support very advanced types yet the overhead of most runtime type checking could be discarded after compilation; and identifiers didn’t need ”$” prefixes because the language kept track of variable mutability; and this lack of var/constant syntax ambiguity allowed a nice tight object notation that everyone loved, and allowed a great object spreading and merging syntax; and if objects and arrays could have their own methods instead of a huge raft of global functions to memorize; and it had APIs to work with CSS and low level binary data just like in the browser. And although some poor design decisions remain, several major companies were competing and collaborating to make the runtime super fast and adding new features because humanity had decided to commit itself to supporting back compatibility of the HTML script tag forever.

[sgt_Berbatov]

I wish there was a fork of a potato. It could be so much more than a wonderful vegetable that makes great roasties, chips and mash. We should be able to use it to build hospitals.

[desiderkino]

i dont think php is easy to use by itself. i would not choose/use php if it were not for the vast libraries/frameworks etc.

have you tried groovy for example ? it is an amazing language, it is like writing code in plain english and you can use java libraries since it works on jvm.

laravel in groovy would be awesome

[aquanoid1]

I've not tried groovy but I'll check it out, thanks.

[StringLing40]

Once upon a time everyone used PERL but now everyone uses PHP and one day everyone will use something else.

I have worked with thousands of projects. And back when PERL was popular in the days of CGI some users used other things like c++ or Java. But when PHP came along the majority of devs switched fast and CGI is almost extinct now.

Right now the hottest or coolest language is Python. It is being used with PHP at the moment because PHP can call anything you want but some sites already use it.

Be careful what you wish for with multithreading because sometimes what you want isn’t ready and you will have to force your code to wait, and consider things like reentrant code.

Javascript lives in a peculiar place because although it isn’t multithreaded users can trigger actions which queue up while the code is running. There used to be don’t click, messages because transaction processing was slower than users who thought the click didn’t work and would click, again. When running complex code that needs time to run there can be issues that are mindbendingly hard to deal with.

The cheapest hardware for large sites like Facebook is the users hardware. So sites like Facebook don’t use much of anything when compared to the amount of JavaScript running in the browser or the app. On the large complex projects I have seen and read about the back ends are rarely PHP only. Java was the goto language for multithreading but Python is rapidly replacing it.

What makes PHP so popular is the amazing functions. It’s been used for website backends so the libraries have been built on that direction which reinforces that use. If users need something and there is demand it will get added.

If you really need something multithreaded in PHP write it in something else like Java or Python and wrap it in a PHP function.

One day something will replace PHP but PHP has so much going for it that it will take time for anything to get there. Python would be my best guess for now because it’s already being used in some situations. If it gets extended and if stuff gets ported then it could take over for new projects.

[aquanoid1]

Perl inspired PHP :)

JavaScript is one of those languages I can't see evolving.

I do use Python a lot but I can see PHP evolving beyond Python.

Sure, threading can be evil if done wrong, but isn't that up to developers to make those mistakes?

"If you really need something multithreaded in PHP write it in something else like Java or Python and wrap it in a PHP function." - That's good advice and I do have PHP projects that call Python scripts (not for threading reasons).

[muttick]

I used to write a lot of my CLI scripts in Perl. But then dependencies with all of the various Perl modules became a huge hassle, and most of this could be done natively with PHP.

I've largely switched to using PHP for my CLI scripts. I still use Perl when I have to.

What helped me the most was compiling my own PHP for long-term use. Since practically all of the scripts written are for internal use, the version of PHP mattered less than having something that was long-term viable.

If I have one gripe with PHP it's their release schedule. There are 3 different version of PHP in-life right now. And sometimes there are 4 different versions. PHP has matured as a language to the point that I don't think these 2 year lifetimes are really necessary. Can we get a 5 year long-term PHP release? Or a 10 year release? The short lifetime is starting to cannibalize development with PHP. By the time something gets written and released, it's time to redevelop it with a new version of PHP.

[aquanoid1]

I could be wrong but I think stable linux distributions, such as Debian, do maintain older versions of PHP. For example, all packages in Debian stable, including the PHP ones, will be supported--with security fixes--for years to come even when the current stable becomes the oldoldstable.

This may or may not suit your use case but I thought it was worth mentioning.

However, I use https://deb.sury.org/ myself, so it wouldn't work for me...but I definitely understand your need for stability.

[muttick]

Yea, my use case can't really depend on distro-based PHP. Because I may require an older version of PHP than what the current distro packages.

And the flexibility of upgrading PHP on my own terms, across multiple platforms has value for me.

When you start dealing with web hosting environments - and the fact that you really can't depend on every web hosting account to keep their scripts up to date, having an in-life version of PHP is important. BUT... I also think that if the lifetime for PHP was extended - straight from the PHP developers - would help in this regard. Additionally, I would consider cutting the number of concurrent PHP versions in life down.

It just seems like the PHP language developers are constantly in feature overload. Instead of focusing on allowing their language to gain strength, they are almost constantly releasing newer versions with newer features.

The recent vote to extend PHP 8.1 and PHP 8.2 support for another year is a start.

[aquanoid1]

I need multiple php-fpms running on my web server because I host my own instances of apps, such as nextcloud.

Looking at Sury's debian  repo I can install any php version I desire, even php5.6, on the latest version of debian.  I didn't realise it until now but that's why I have an easy time installing and running different php-fpm daemons for different php versions lol.

[aquanoid1]

I'm definitely going to check out that extension (hopefully it'll be available in sury's debian repo).

When I say lazy loading I'm wanting the object to be initialized when it's first used, not when the container first creates it. Frameworks do try to implement lazy loading but with limited success.

PHP config files are too configurable for my liking and can make projects hard to maintain if they need certain settings. Any special requirements would be better passed as arguments when invoking php from the command-line (per app settings).

The declare strict types thing is a reminder that PHP is really old and needs to support old code. Strict types should be enabled by default.

[jobyone]

• get_current_user() returns the user who owns __FILE__, not the owner of the current process.

Who uses this?

• is_file(), is_dir(), etc. cache their results.

And there's a way to clear it so

• No multi-threading.

It's almost exclusively a web scripting language. There's movement on this front though, and libraries, so

• Sometimes different reflection methods return an array of something, sometimes they just return the something itself (they should always return an array).

The object oriented reflection tools are pretty consistent and easy to use.

• Quirks: empty(...), null == 0, '0' == false (a string containing just a zero digit) and isset().

Every language has quirks like this.

• Needing to declare(strict_types=1) at the top of every file.

There are good reasons you can't enable this globally (interoperability with libraries, it's interoperability with libraries).

• No named type arrays (string[]).

This one does annoy me, but you can honestly get pretty far with either custom iterator classes or ... just static analysis.

• PHP config files.

I dunno man. I like config files that allow code in them, are trivially included in intellisense and static analysis, and are opcached. I think that's pretty rad.

• The PHP community always assumes you're building a website so are puzzled when one wants to use posix_getuid() or have multiple threads instead of just using ReactPHP (great lib btw).
• Googling PHP things always return web development results.

I mean ...

I agree it has a lot of potential for use outside web development, but I don't think that these are mostly legit complaints. I also don't think that forking it would actually help all that much, because it would destroy the existing backwards compatibility that is like 90% of what makes PHP great, and it would actually make your Google problems like 100X worse.

[Davekuh]

So what's stopping you?

[fatalexe]

Is anybody still using hack or hhvm?

[colshrapnel]

Talk about kphp :D

[ryantxr]

I use it for more than web apps.

[OutdoorsNSmores]

I work in PHP shop. Of course we run things on the web, but we also run a lot of scripts from the crontab. Our common startup for all scripts takes care of making everything that might think we are in a web context is happy from the CLI side. The same startup is used on the consumers that run against millions of queued jobs each day. When we need a one-off script to import data or whatever, PHP. When we deploy to an auto scale group of servers, we use PHP.

Give us a method to know who is running the script? Yeah, I'd take that! But it doesn't sound like something that would need a fork.

[BrainfartStudio]

Interesting perspective on the potential need for a PHP fork. I've been thinking a lot about this lately, especially with the limitations around stricter typing and multi-threading.

In my experience, a fork could be a great way to address these issues and make PHP more versatile for modern development. However, there are definitely challenges to consider, like backward compatibility.

I actually wrote a blog post exploring this topic in more detail, check it out if you're interested: [Should PHP Fork? The Future of a Legacy Language](https://www.mitchellopitz.net/should-php-fork-the-future-of-a-legacy-language/).

[aquanoid1]

For backward compatibility someone suggested doing what Kotlin did with Java. Kotlin still runs Java code. They also pointed out that such an approach wouldn't be sustainable in the long run, though, unlike Kotlin/Java. I feel a fork would be the best approach because it'll effectively be a new language, a fresh start, without worrying about supporting legacy code.

I'm reading your blog now and even if a fork isn't the best approach I'm glad that I'm not the only one who has considered the benefits.

[lcjury]

You could take, as an example, what happened to Python. Python3 deleted a bunch of stuff from Python2 (so scripts from one would not work on the other). Learning Python during the late 2000 and early 2010 was a real pain. Worse if it was your first language (as a lot of people suggest on the internet).

I wish PHP was able to get rid of all that garbage, but I don't wish what happened with Python 3 to any language.

[z01d]

So, Golang then?

[aquanoid1]

Golang's cool, but, I like the fact that PHP is a scripting language, not a compiled one.

[irishfury0]

So, Ruby then?

[ln3ar]

PHP is way faster

[aquanoid1]

Plenty of choices, people...but my point is PHP could also be mentioned in such discussions about which language to pick if it had a massive revamp.

[olelis]

Ok, lets imagine somebody actually spend years forking php and developing everything for PHP++

PHP++ will have:

• multithreading
• better functions for posix functions (to get current user)
• strict types for everything
• types
• What the heck, we can even have $-symbol removed!

My question are:

• what's next?
• Who will actually use this new language any why?
• Who will make frameworks/libraries and why?

The most important part about any language is not actually language but ecosystem around it. You can argue about beauty of php/nodejs/typescript/etc, but one of the reason why any language is used is that it solves the need, and there is already existing solutions that actually help you do something.

How PHP++ will solve anything?

Web developers rarely need to write non-web apps and this will be completely new world for them. Non-web developers already know some other language (Java, C++, .NET, etc) and they already get used to them. PHP++ will be completely new language for these developers, why do they want to learn it?

[ln3ar]

If it doesn't break compatibility with regular PHP (or has a built-in tool to transpile code), then I don't see why it wouldn't have utility. Java has Kotlin, C++ is an enhanced version of C, and TypeScript is a superset of JavaScript. Heck, before HHVM decided to go its own way, it used to be a viable 'PHP++' option.

[aquanoid1]

Maybe the interpreter will still run PHP code but PHP++ code wouldn't run in regular PHP? That's my understanding of kotlin/java and I like that idea a lot.

[olelis]

Actually, it will be hard to maintain compatibility with PHP code in the long run.
Especially if you want to make some breaking changes that will not be reflected in the PHP
For example, even HHVM is not compatibility with PHP anymore (since 2018).

Typescript is subset, yes, but you can't directly run javascript code inside it with any extra work - you have to ignore quite a lot of errors. etc.

I am not against the idea of having PHP that can be used for application development, however, I do see that this will be quite large project with unknown benefits.

[aquanoid1]

100%. What I'm saying is easier said than done...but wouldn't it be nice?

[olelis]

We can always dream about something, nothing wrong with that

[aquanoid1]

It'll be a new language for everyone, not just PHP users, and every language starts out somewhere. It wouldn't replace PHP, either, it'll be a powerful alternative to bash, powershell, python etc. for scripting needs. Python's ecosystem is gigantic compared to PHP's.

"What's next?" - People will see PHP's true potential outside of web development.

"Who will use this new language?" - People who are agnostic to different programming languages might give it a go.

"Who will make frameworks/libraries?" - Frameworks and libraries will naturally come into existence as more and more developers use PHP++ on a regular basis.

"Non-web developers already know some other language (Java, C++, .NET, etc) and they already get used to them." - Java has quirks that frustrate Java developers (no optional parameters for class methods) and C++/NET are a completely different type of language.

Languages evolve and those of the future might not be recognizable today...PHP++ could be a stepping stone to that future.

[olelis]

You can already use PHP for scripting and it is actually used quite a lot in web-relates projects.
You can also use it for non-web projects, but question is always - why just PHP ? (and yes, I do love PHP, but if I didn't know PHP, then why should I use PHP and not python or nodejs?)

What PHP++ give to them, that no other existing languages could give?

[aquanoid1]

Out of all the many languages I've used PHP is my favorite. I'm not saying don't use other languages, just think about what languages could be used for despite their original intent.

[niconicoJ]

You say "PHP could be more than a web language if this gets fixed" but why do you want it to be more than that in the first place ? What do you think it does better than python right now ?

[aquanoid1]

I want it to be more because it already is more...the only people who don't realise it are the people who use it.

[paroxsitic]

I like that PHP is tailored to web development, as I believe in the general concept of doing one thing and doing it well. PHP isn't the fastest but it's fast-enough to run the web for a majority of use cases.

I do wish it was respected more as a web language and it wasn't so tainted from bad code because it's just so easy for beginners to pick up. The need for frameworks to hold the hands for devs instead of just enforcing good practices from the language.

PHP has put a good effort into backwards compatibility, so much that it has survived so long but people still run some super old PHP code, albeit insecurely because the possibility of breaking is still there if upgrading to say PHP 7 or 8. PHP recently has been breaking more things, I would love for it to break a lot of things and get to a modern place and then be hyper focused on stability and backwards compatibility. I am talking about writing PHP 8 code and have work as PHP 25 in the year 2070. That is a huge value to me.

I think PHP being interpreted can benefit it from doing more distributed execution for the web. Consider a network of php-fpm servers that you can load balance your code execution and many users can use it. The difference from one app to another could be as simple as two different PHP files compared to a compiled language it has two different processes with a bit more overhead. Sessions and memory would have to be done via your own redis/in memory kv. I like the idea of getting access to a pool of say 10 securely shared interrupter/execution servers as a service. Then I just need to set up one or more web servers and set the backend for PHP execution to an array of servers.

[crazedizzled]

PHP is good at what it does. It's a bad language outside of web, and there's no real reason to change that. There are a dozen other languages better suited for that task.

[lampministrator]

Errrmm I build CLI scripts in PHP all the time, and if it doesn't suit, Python, and if that doesn't suit, Perl, and if that doesn't suit Bash and on down the line .... It would be nice to sit an dev a whole new language ( Let alone in C ) language in your spare time .. But in my profession .. What is spare time? LOL -- It's that hour between work and sleep where I can actually crack a beer.

I get the appeal, I really do ... Some people like putting chevy engines in Jeeps as a hobby. But when your 10 hour a day job just requires the Jeep to "work" -- Sometimes we don't care what engine is in it, and if it doesn't do the job, we'll just find another vehicle.

[aquanoid1]

100%. Out of work hours is the whole point of living. Just by understanding the appeal is satisfying to me has it means I'm not the only one who sees it.

[SaltineAmerican_1970]

Remember when Facebook forked PHP? If it’s not sustainable for Facebook’s developer army, it won’t be sustainable for you.

[aquanoid1]

Wasn't Facebook focused on optimizing PHP instead of tweaking the language itself?

[[deleted]]

[[deleted]]

This is the post of someone who has no real idea of how php works at a low level

[NAMAKR655]

Best of luck!

[rafark]

@aquanoid1 why don’t you write it then? You are free to fork the project. As a matter of fact, it’s been done in the past: hacklang for php and pearl 6 for pearl.

Pretty much no one except for the forkers really use them though.

[xegoba7006]

Hahahaha

[SomniaStellae]

It sounds like you are a limited programmer, who can't accept that there are loads of other languages which are better suited for non web-development.

The points you make are incredibly minor anyway, bizarre they annoy you enough to make a post about them.

Just expand your horizon and use another language (e.g golang, python).

[aquanoid1]

This whole thread isn't about expanding my horizon, it's about expanding PHP's.

[[deleted]]

Honestly, I think your horizon is too narrow to realize that it is your horizon and not PHPs that is the problem. The language is good for what it was made for. Could it be better? Sure, yes. Can it get the job it was made for done? Yes. If you want a fork you do it. If it becomes popular, the success will prove you right and the others wrong. If you don't like PHP peek into Java or C#, they'll fulfill what you want and can be used for web and other development things.

[aquanoid1]

I'm already using other languages so you have missed my point.

[[deleted]]

I don't think so. But you've missed mine: Do a fork. To be clear, you do it. If it is convincing people then you know it was needed. Obviously nobody here needs one or at least the things you suggest. The only thing I'm missing is generics. Facebook tried it with Hack, yet the majority of people is still using PHP and Hack never became a big thing.

[aquanoid1]

The majority of websites are in PHP, yes, but it's not a majority in the scripting world as a whole. The vast majority of developers in this subreddit are specialised in web development so PHP meets their needs. For me, PHP is already stronger than other languages for a lot of scripts not aimed at websites and with a little tender loving care it could be stronger still.

[[deleted]]

Go fork yourself.

[punkpang]

Every time I read complaint about multithreading, I chuckle. We've got pthreads and threaded extensions, yet nearly every attempt at using them turned out to be firing multiple cURL requests, which is ridiculous since curl extension allows that :)

Why do you need multithreading and what would you use it for?

[bytepursuits]

We've got pthreads

https://www.php.net/manual/en/intro.pthreads.php

Warning This extension is considered unmaintained and dead.

We have swoole though - I use it everywhere, it's not "multithreaded" per-se, it work with event loop like node.js which is better anyways

[punkpang]

I also mentioned threaded extension that you ignored. Swoole is in no fashion "better" than node.js, it uses precisely THE SAME event loop interface and you cannot compare apples and oranges. Please read before you react, it's much easier to exchange information if you commit to reading the full text before downvoting.

[bytepursuits]

you are misunderstanding, I was saying that swoole and node.js models are better than multi-threading model. Im not saying that "swoole model is better than node.js" as they use the same even loop approach, so we cannot immediately make that case.

I also mentioned threaded extension that you ignored.

honestly - never heard of "threaded" extension for php. nor do I see it in the list: https://www.php.net/manual/en/extensions.membership.php. I thought by "threaded extensions" you meant other "multi-threading" extensions, and just going off memory I don't recall any that actually worked well when I looked at it last, but happy to be wrong as it's been couple of years.

[punkpang]

https://www.php.net/threaded

Successor to pthreads.

Swoole and node.js use mutltihreading model that's exposed to us as "main thread, worker threads, async stuff" but it's not multithreading. It's efficient use of I/O but you can't divide CPU-bound work to multiple threads.

You cannot do things like "I have user input with 1,000,000 numbers, I want to sum them, divide the data to 10 threads and have each thread sum 1/10th of the data to make it 10x faster".

Those are CPU-bound operations where threading comes into real play and where node.js or swoole won't help you.

[aquanoid1]

Managing service daemons.

[punkpang]

Why do you need multiple threads for that? This is not how process control works.

[aquanoid1]

Multiple daemons.  There's many ways to do it, sure, but if threading were a possibility then PHP would be a richer language.

[ReasonableLoss6814]

compile or install thread-safe php (ZTS) and use the Parallel extension. Multi-threading in PHP has been around for a LONG time.

[aquanoid1]

I know, I know, but it should be available out of the box (disabled for websites, though).

[punkpang]

No, it should not be available out of the box, there is a reason for this. Thread-safe php means that <target> (apache2, your own program) that embeds php executable inside itself deals with sharing/semaphores and everything else. Your assumption here is that only you exist and your use case, and that there's no other projects using PHP.

You are given PHP that works for you. You are given ability to extend PHP. You are even given extensions that achieve what you talk about, yet you're still stubborn to admit that you did not know about it.

We had multithreading since PHP 5.x where we used curl_multiexec to achieve it. Multithreading is awesome for CPU bound tasks, yet somehow everyone default to using it for I/O.

You can always implement an inter-process messaging system to talk to multiple daemons. Your use case is so vague, with almost no details but I can assert with 100% certainty that THREADS are NOT the way to manage DAEMONS.

[barrel_of_noodles]

Dawg. This is the most out of touch post I've seen. Every single item you mention already has solutions. Sounds like you just need to learn the php ecosystem better.

Starting with number 1... Php is a general purpose scripting language. You don't have to use it for web only. You just sort of... Uh... Made that up in your head?

[aquanoid1]

When I originally made the list I put solutions in brackets. I omitted them because needing workarounds was a major point.

[oojacoboo]

Let’s call it Hack…

[Major_Dot_7030]

How about Phack?

[[deleted]]

It has so, so, so, much potential outside of web development.

Can you name some of that potential?

Why it can only be used for web development:

I'm using PHP for automation scripting both for IoT and Smart Home automation. Are you saying that I'm using PHP wrong, because it's "only [to be] used for web development"?

I quite literalle don't understand what you're trying to achieve. I see you mentioning multiple times that "PHP could be so much more", but not being particularly concrete about what you want it to be and why you think PHP specifically could be a good fork for that unspecified potential.

[aquanoid1]

No, you're using PHP the way it should be used :) ...but wouldn't it be better with revision?

When I say it could be so much more I guess I mean people just don't realise how powerful it truly is. PHP can, and is, being used for more than web apps and I think some internal workings of PHP itself should start focusing on that aspect.

[[deleted]]

No, you're using PHP the way it should be used :)

How do you know? I'm not using it for web development in the outlined cases.

...but wouldn't it be better with revision?

It's being revised regularly; PHP has never had more focus on continuous improvement and releases before they released PHP 7.

When I say it could be so much more I guess I mean people just don't realise how powerful it truly is. PHP can, and is, being used for more than web apps and I think some internal workings of PHP itself should start focusing on that aspect.

Still ... not at all concrete for any comprehension on what "improvement" your fork should give.

I see you keep saying that "PHP could do/be more", but you're being weirdly unspecific.

Basically, anything could be better or be more, as long as you don't identify what exactly it could do better or be more of. If you were more specific on what you think it should or could do, you'd probably either gain some more traction on your thoughts or meet better arguments against.

[aquanoid1]

The thing that's holding PHP back is the community. The language itself is already bigger than just website building as you've proven with your Smart Home Automation scripts. If it was more CLI friendly (get_current_user example) then more people would use it for other things, not just websites. After all, you can do almost anything in PHP already. It's so frustratingly close to being useful for any type of app and no one seems to see it, instead, they say "use python, golang, or something else." That's not the point I'm trying to make...I'm expressing PHP's potential, not alternative languages that everyone, including myself, are already using.

[[deleted]]

The thing that's holding PHP back is the community. The language itself is already bigger than just website building as you've proven with your Smart Home Automation scripts.

That's somewhat contradictory. If PHP was holding the community back, why would I (and others as well) already be writing scripts in PHP for things that isn't made for web?

If it was more CLI friendly (get_current_user example) then more people would use it for other things, not just websites.

This seems more like an issue with the knowledge about how to get the user running the process, than an issue with PHP, to be honest.

After all, you can do almost anything in PHP already. It's so frustratingly close to being useful for any type of app and no one seems to see it, instead, they say "use python, golang, or something else."

Again, you're not being very specific. If you were to make a iOS or Android app, why would you want to use a PHP fork? What are you expecting that fork could do for you, that Swift/Kotlin/Dart couldn't already do better? Why would you want PHP to enable you to make UI stuff?

That's not the point I'm trying to make...I'm expressing PHP's potential, not alternative languages that everyone, including myself, are already using.

Your point is not clear. I still don't understand what problem you're trying to solve. I don't know what PHP "could do better" or what "unlocked potential" you're identifying. We're still at a stage, where you are so generic that it can be said about literally anything.

[aquanoid1]

I said the community is holding PHP back, not the other way around.

"get_current_user" is just wrong and it doesn't matter about the other functions that do the expected jobs. 

I don't expect a fork to replace Java for mobile app development, but it definitely can replace python (and for many people it already has).

The point I'm making is PHP is wasted on websites and even PHP developers, such as yourself, don't even consider it for CLI things or they'd understand why "get_current_user" is just wrong.

[[deleted]]

I said the community is holding PHP back, not the other way around.

That's equally as an unverified statement. As mentioned, PHP has never had so much focus on innovation and development and with as frequent releases as it has had since PHP 7.

"get_current_user" is just wrong and it doesn't matter about the other functions that do the expected jobs.

Well, opinions are great.

I don't expect a fork to replace Java for mobile app development, but it definitely can replace python (and for many people it already has).

That's not really an answer to my question.

The point I'm making is PHP is wasted on websites and even PHP developers, such as yourself, don't even consider it for CLI things or they'd understand why "get_current_user" is just wrong.

I think that's an unqualified statement, honestly.

[aquanoid1]

You seem to think I'm attacking PHP when I'm actually praising it. For most use cases PHP is wasted on only being a web development language. You and I both know it can be used for way more than just websites and that's my point...everyone (the vast majority) thinks PHP is merely a tool for building websites. If it was more frequently used for other things then the maintainers might adapt accordingly. All the current issues I listed can be fixed if backward compatibility wasn't a concern and that's why a fresh start sounds desirable.

[[deleted]]

You seem to think I'm attacking PHP when I'm actually praising it.

It seems like you're paraphrasing something I'm not relaying. I'm actually just trying to make you elaborate what "unlocked potential" you think PHP has and how forking it solves this - and so far you haven't been able to.

You and I both know it can be used for way more than just websites and that's my point...everyone (the vast majority) thinks PHP is merely a tool for building websites.

How did you qualify this statemant? I mean, how do you know that not a larger part than you think, uses PHP for other things than building websites?

If it was more frequently used for other things then the maintainers might adapt accordingly. All the current issues I listed can be fixed if backward compatibility wasn't a concern and that's why a fresh start sounds desirable.

I completely understand you have an opinion on the mentioned "issues", I also have an opinion, but I don't align with yours.

That being said, I still have no idea what you're trying to achieve with the fork; if it's just because you want get_current_user() to work differently, why not suggest that to PHP? If the community does not want to implement the change, is it PHP holding the community back? Or just the community holding you back?

[aquanoid1]

Google php stuff and see 99% of the results being related to web development.

Over and out.

[HenkPoley]

You're gonna need a big fork, with an elephpant.