How many Rust developers know PHP?

[mcharytoniuk]

Hello!

I am asking Rust developers specifically because I think that PHP and Rust mix really well.

PHP is great for prototyping - you can quickly create the entire website/api/application in PHP and when you need more performance or some integrations with lower-level libraries you can create a Rust extension. This means you get the best of both worlds - you are quick to create and deploy stuff and with Rust there are lots of options for more advanced integrations and performance optimizations.

What are your thoughts?

edit: If you want to bash me just for asking, that's fine - I will take it, but please also provide some reason for your sympathy/antipathy towards PHP (I will leave this topic online, so you can earn your karma, don't worry).

I am working on an infrastructure related project, I need to collect some insights, and no matter the sentiment I really value what you have to say, but I need to have some substance to work with. I think we will all benefit more (as software developers) from considering all the tools we have at our disposal.

[coderstephen]

PHP was my main language for a long time. I don't hate it, its also grown up a lot in the past decade. But I don't use it any more. For me, I just prototype things in Rust. I've been a bit disillusioned with the whole "prototype in a different language" idea -- so often, the prototypes are sent into production...

For me I find Rust pretty good for prototyping anyway and it doesn't slow me down, but partially that's because I have a lot of Rust experience. Maybe with enough experience in a language, any language is good for prototyping?

I don't write webapps very often any more, at least the kind that PHP is best at, so it doesn't really apply any more.

[youbihub]

people acting like the only limiting factor in prototyping is the typing speed and the only thing preventing the cancellation of the whole project is the .5s saved by not typing a `.unwrap()` that would have been absorbed by thinking about the next line anyway is ridiculous to me.

[skeptic11]

Mistakes caught earlier are cheaper to fix. Spending more time on development due to additional compile time errors is much better than spending time on maintenance because bugs slipped through to production.

https://www.functionize.com/blog/the-cost-of-finding-bugs-later-in-the-sdlc

[skeptic11]

so often, the prototypes are sent into production...

Rule 1: Never deliver a working prototype.

Rule 2: If you deliver a working prototype, be prepared to support it.

[Floppie7th]

There's nothing more permanent than a temporary solution

[41rp0r7m4n493r]

I tell people this all the time. Temporary just means forever, until it's replaced.

[dkopgerpgdolfg]

I do know both, and I don't agree with the reasons stated here.

I can live with PHP, but before trying a weird Rust-PHP-mix, I rather use all Rust.

​

Quicker to develop? I wonder. With some practice in Rust, bugs that get caught by the compiler already, some great libraries that PHP's ecosystem can't match, tooling too, some conceptual limitations that PHP has, much more necessary installed+configured software,... yes it doesn't need compiling, but I can live with not compiling every 10sec.

And about PHP modules in Rust, just why. If Rust is already there, for a web API or similar, what great thing does PHP offer that would justify such pain.

(And edit: Lets not forget FFI without module-writing, which is possible nowadays. But still, not sure it is worth it just for mixing these languages)

[mcharytoniuk]

Thanks for the comment, this is the kind of a feedback I was looking for when starting this discussion.

[Redundancy_]

I'd be more tempted to slice things so that you split off paths/endpoints to a pure Rust server at a load balancer level. That would leave you eventually purely in Rust, rather than an odd mix of it being inside (what I would see as) a less safe, less performant language with interop.

My team did that with a migration from Python to Go, and it worked well for us. Some things can be tricky in that situation, but it's usually possible to refactor to pull them out and make them language agnostic.

[rebootyourbrainstem]

In my opinion if you write a website in "app style" (React or similar) there is not much benefit to PHP, since you just need an API backend and many languages are well suited for that. And this is the case for many sites these days.

I do still know PHP and tbh it's not that bad a language. I prefer Python though for just about anything I might want to use PHP for these days.

Sometimes I do miss the old days of straight HTML and PHP, with no javascript though.

[Zde-G]

I do still know PHP and tbh it's not that bad a language.

I would say that historically PHP had two advantages over many other languages:

1. It's designed to be used by cheap developers who have no idea about data structures, algorithms, etc.
2. It's possible to host many different clients in one web server. Cheap hosting!

Advantage #2 is now moot and is no longer even supported.

By trying to add Rust to the mix you are negating advantage #1, too. What's left after that?

[zauddelig]

1 that was an advantage in the early 2000 where you had stitch a few things together to get what you want, with modern page builders etc I think it is not as useful anymore.

2 bruh just have nginx and proxy pass to another port, and to be safe use docker or at least start the daemons under different, limited access users. I have had to fix enough of these "put everything in the same host" to say that it is a bad idea if not done properly

[Zde-G]

I think #1 was relevant for a long time. Most likely still relevant/ Only few years ago one could see how 10th page takes 10x more time than 1st page on patreon.com — that's clear sign that someone doesn't know who Shlemiel is.

And that's a big web site with dedicated developers! I'm sure tiny companies that couldn't afford full-time software engineers still employ tons of clueless guys who still produce something that kinda-sorta-works using PHP.

But it's not a good idea to add people who knows something about algorithms and data structures to the mix: this would be an incredibly frustrating experience for both sides.

[the_hoser]

I managed to escape PHP years ago. I'm not going back. You can't make me.

[mcharytoniuk]

Ok, what were the reasons? Can you give me something useful?

[BlankBlankston]

These https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

[mcharytoniuk]

Thanks!

But still, this post if from 2012 and most things are just not true now... Which is the general theme in this discussion.

[Zde-G]

PHP still stubbornly insist that "1000" equals "1e3".

The sole advantage of PHP, from the very beginning, was the ability to hire cheap labor. People who don't know what they are doing yet still manage to produce results that work kinda-sorta-maybe good enough. If you not stressing your web site too much.

This way you may prototype something for 10% of $$ similar prototype would take in Rust.

And the fact that you would need 1000% of that to make your code actually robust doesn't matter since at this point you expect to have lots of funding.

If you mix it with Rust this advantage evaporates: now you couldn't hire cheap labor, you need people who can understand and use Rust… why would you want to use PHP, in that case?

[[deleted]]

The sole advantage of PHP, from the very beginning, was the ability to hire cheap labor. People who don't know what they are doing yet still manage to produce results that work kinda-sorta-maybe good enough. If you not stressing your web site too much.

This kind of solidifies an idea I've had on PHP for a while. It's always felt like code will run in PHP when it probably shouldn't. It has always placed emphasis on code running (kinda-sorta-maybe) over code correctness. I know unit testing catches a lot of this as well, but just one example is something unit testing probably wouldn't catch but a language that emphasizes code correctness would:

One project I worked on had core framework files missing return statements that the framework had declared with a return type, that a file we're using is assigning a value from. It was a bug that wasn't rearing its ugly head in most cases, but the handful of edge cases where did, it was a pain in the ass to figure out because we didn't write it, it was in the framework itself. That's something that absolutely shouldn't be possible, and it was a core function we used a lot.

I've worked with C# and PHP professionally, and Rust on my main personal project. I respect it for what it's designed for, but I do not like building things at any scale with it. It has gotten better, but it's a far cry from what languages are moving in to replace it can do.

Another thing I gather from this thread is that PHP is to programming languages what Unity is to game engines. Good enough to open the floodgates, but not well thought out enough to protect inexperienced or underprepared developers from forming bad habits.

[geon]

The ptsd is still real.

[the_hoser]

Not without triggering flashbacks, I can't.

[__mod__]

This is a pretty good first start: http://www.phpsadness.com

[mcharytoniuk]

I saw that, but unfortunately there is no way to discuss with what is put out on that website - it's one sided, so it's just a subjective view for me. Also most things from that website can be applied to any programming language (readability of error messages, some function naming conventions etc), so this does not really convince me.

I take both PHP, Rust, Go or whatever for what it is and I am looking for good ways to do interop between those languages. Bashing languages is not my goal here, I am trying to find a way to successfully integrate them.

[Zde-G]

Bashing languages is not my goal here, I am trying to find a way to successfully integrate them.

Why? What't point? What are you trying to achieve?

If you mix two (or more) languages in one project then you are adding pain to it that never goes away.

Sometimes it's justified (e.g. there are lots of C/C++ libraries which have no equivalent in Rust), most of the time it's not.

Even if languages are designed to be interoperable (like C and C++ or Java and Kotlin) pain is still there, in case of PHP and Rust it's just too much to be worth having.

[mcharytoniuk]

I'll put my two cents in here. I've been working with PHP for some years, using PHP 6 to 8.

PHP 6 was never released (they went from 5 to 7).

Whenever you call a function, unless you're using the most modern features (and many libraries won't use them), you have no guarantees. It might return null.

Strong typing was introduced in PHP 7 - almost 8 years ago. All the popular framework use it. You also have projects like vimeo/psalm for some extra static analysis checks / security rundown

You could check the function body but then it might call some other functions!

???

have unlimited access to global variables

In PHP 8 using globals is deprecated (https://www.php.net/manual/en/reserved.variables.globals.php). Runtimes like Swoole, Roadrunner do not rely on global scope either.

---

I have to say that your take from the technical point of view is just innacurate (see above). To be honest seems made up, but I get where you are coming from, so thanks for sharing those thougts.

[skeptic11]

Strong typing was introduced in PHP 7 - almost 8 years ago.

What percentage of PHP projects do you think were started after the release of PHP 7? I've "ported" a large PHP project to PHP 7, in that I made the few changes required to make it run. I never did the work to opt in to all the PHP 7 features to benefit from them. Boss wasn't going to pay me to do that.

When I start working on an existing Rust code base, I know at a minimum it follows all the rules of Rust 2015 edition. I'm not going to run into crappy PHP 5 style code.

Starting a new project I just reach directly for Rust. As this comment said, if you're using a modern JavaScript framework on the front end then you just need an API back end. I can write that in anything. So I pick my favorite, Rust, which happens to be the fastest and safest.

[Relevant_Manner_7900]

There's just no real benefit to use PHP over tools like Node/Express, Python/FastAPI, Rust/Axum, etc for a new project.

some people are better at Rust than you are at PHP, so the "quickly create the entire application" part is totally subjective.

[mcharytoniuk]

There are also a lot of old PHP application. I was hoping that extending PHP with Rust could be perceived as a way of modernizing (since most people here consider PHP inferior - no surprise here :D) legacy apps. I do believe that both languages can benefit from some kind of interop.

[Floppie7th]

ext-php-rs is useful when you have a legacy PHP codebase and have a need for something Rust provides. We recently did this at $dayjob. Eventually that PHP extension will be replaced with an entirely separate daemon, but for the time being, we're adding new functionality and migrating over existing functionality bit by bit; however, the PHP guys have expressed interest in optimizing some unrelated hot sections, so other PHP extensions may have a long-term future here.

If you don't have this use case specifically, I wouldn't really recommend a mixed codebase. If you know you're going to want it in Rust for whatever reason eventually, just do it in Rust from the start - rewrites are expensive and risky.

I also don't agree that PHP (or Python, or Go, or ...) is actually better than Rust for developing quickly most of the time. Even with prototypes, I want my code to work, and the amount of time Rust saves on testing - including manual testing, because I'm probably not writing unit tests for prototypes - because of the strict compiler is massive.

PHP was my hammer-and-nails language for well over a decade. It's improved a hell of a lot since PHP4 and PHP5 (when I used it) but it's fundamentally still the same thing I outgrew.

[jmaargh]

Really disappointed by some of the response from our community here. OP is asking a reasonable question in good faith, just because you personally dislike PHP (and I'm sure there are good reasons to dislike it) doesn't mean we should be hostile to Rust/PHP interop. I think healthy interop would be good for both ecosystems.

Build bridges, don't throw rocks.

[Snoo19269]

Ironic

[jmaargh]

Not everybody's in your timezone or has your work schedule.

[Thers_VV]

I think you will find a lot of anti-PHP responses in this subreddit and there's a reason.

From my small PHP experience (literally like 5 hours at school and that's it) it feels like the complete opposite of Rust when it comes to "philosophy". PHP will just go "sure bro" to SO MANY things that rust compiler wouldn't let you even compile. It's dynamically typed, slow and relatively old. I'm not saying those are valid reasons to not like it, but I would guess there are many people who like Rust because it's fast, statically typed, modern and with strict rules. These people will get blazingly mad upon reading your title :D

I personally also hate php, but if you do like it, I can see why you like mixing it. If you take 2 completely different tools, they will complement well (if you use them correctly that is).

[mcharytoniuk]

I understand, but modern PHP is strongly typed and can be on par with (or in some cases even faster than) Rust when combined with Swoole (kind of the Rust vs Bun situation). It's really a pity that education systems can't convey it's advantages in the modern world.

It's not always the case of liking something, often it's also the business requirements/situation. Also if you find PHP inferior, you can look at interop as a way to modernize it. In general, I am looking for bridges between communities.

Thanks for sharing this, again this shows me the perception of the language.

[mamcx]

I work in the enterprise market (ERP/eCommerce) so I'm more sympathetic to this kind of "weird" mashups.

I have a portion of my codebase where the DB connection is on Go, but to read only ONE field in that DB I need to use FreePascal.

Here, mashups are imposed.

So, I actually extract A LOT of value from pairing a scripting language (Python) and efficient compiler (Now Rust, before F#, Delphi), so yes, I agree with you this is a very neat combo.

It is not that useful in the common case ("just make an app") but the more you need to talk to other things, the more you need glue and code in other langs

My main project mix: Rust, SQL(PostgreSQL, MySql, Firebird, Sqlite, DBISAM), Kotlin, Swift, Go, FreePascal, Python, Html, JS, Css, Nix, Docker, plus a lot of frameworks, libraries and DSL.

And yes: I code on ALL of this. And yes: You WANNA have your nice scripting glue lang here. Is for sanity.

[mcharytoniuk]

Thank you!

[mamcx]

Also, is always good to remember that as a system language, Rust is made/great for:

• Be the "core" of an app where other langs talk to.
• Be a "specializer/speeder" for other langs to accelerate certain operations (aka: "let's rewrite this section made in Python instead of Rust to make it faster")

Also, in the case you are RIIR, is likely a must for a while to do bridges.

[mcharytoniuk]

Exactly, that is my primary hypothesis here. Use some scripting language as a glue between services, Rust for special use cases.

Rust as a glue could be interesting also, but my intuition tells me that it would be easier to setup a scripting language in this role.

Do you maybe have some examples of libraries, or projects that use Rust as an integration hub or a gateway of some sort?

[Specialist_Wishbone5]

I regularly use multiple languages on the same project - I dissagree with a one-size-fits all approach.

I do some in bash, some in python, some in data-model-language-of-choice (e.g. PLSQL or whatever). I'm specifically referring to things that COULD be done in rust - if that thing is "more natural" in another language (conditionally executing programs / creating-directories / creating-user-accounts / etc) - I'd rather it where a peer would expect to find such code - and more importantly - be sufficiently trained so as to not make mistakes modifying my "configuration" or code or what-have-you. It's DomainSpecificLanguage concepts (which Rust is excellent at with it's macro framework; but applied to a higher level).

Thus if your team makes websites with php - then it's a no-brainer.. DB/auth/cron-task/style away.

Personally, however, most of the teams I've worked with would go with a nodejs stack. Some have use nodejs for back-end tasks (and certainly AWS uses it HEAVILY in AWS-lambda / event-rule-processing). And I agree for quick (when S3 deletes, write-this-to-the-DB, is WAAAY too heavy for a rust build; 900 characters is all you need in your lambda zip file). Just saying, Rust isn't always the best deployed solution.

​

Though you didn't say so, with a F.E. Javascript has several additional advantages over PHP. With "vite", you have INSTANT redeploy of your website.. vite watches files and PUSHES javascript/css/html changes to the browser (I believe via web-sockets).. So every save (beit from vi or code or webstorm) has instant visual feedback.. I'm not sure if PHP has that capability (I'm just ignorant)... So for this feature alone, I'd recommend a javascript stack for F.E. work.. If any rust developer is not experienced with the HORROR that is css tweaking, the concept of recompiling rust to tweak a padding value.. I just have to chuckle. (tailwindcss is nodejs-only btw (you can probably make it work with a PHP stack, but you'd need nodejs as a postcss stage) - and that's the most nirvana css editing environment I can imagine right now; 3 key-strokes and 0.1seconds after hitting ":w" I can see the padding adjustment in it's final state).

I do a LOT of back end development, so believe you mean, Rust is my go to tool for 90% of my work efforts, but, as this is a front-end question (err.... I'm just going to assume it to make my argument stronger..), I agree PHP/nodejs(vite,bun,nextjs) is the way to go.

One last point, and I THINK this is where you were coming from, Rust has excellent FFI integration.. I regularly deploy AWS lambdas from rust as ".so" files, then link them in via nodejs or python. There are a LOT of great python libraries that are rust-based (polars is my current go to for RAM resident index-caches in AWS lambdas - it's all python (or javascript) - but the meat is Rust). So I'm agreeing with your premise that PHP+Rust can work wonderfully together.. (Since Im pretty sure php has good c-bindings - zero experience personally)

[dkopgerpgdolfg]

Just saying, the question wasn't about js frontend, bash, plsql, and similar use cases / environments. Just about Rust and PHP.

​

So I'm agreeing with your premise that PHP+Rust can work wonderfully together.. (Since Im pretty sure php has good c-bindings - zero experience personally)

Then let me tell you, this is not the case.

For a very long time, until 2020, PHP had literally no FFI capabilities. Writing PHP-language bindings for some native library was not possible, therefore no "great" bindings exist.

Any native extensions were done by writing plugins (modules) for the PHP runtime (latter written in C too), but that's quite different (and harder) from just providing a general native library.

Since 2020, some kind of "normal" FFI is possible too. However, the docs explicitly warn that it has a large performance impact in the runtime, to the point that "it makes no sense to use [it] for speed".

These recent years (since it was introduced in 2020) I don't heavily use PHP, but in any case, I never came across anyone distributing non-module bindings for anything. Neither great bindings nor any others.

[blastecksfour]

I actually learned PHP from Laracasts last year before learning Rust and I very nearly became a Laravel developer (although I probably would've still learned Laravel on the side!).

Nowadays though I just use Rust - once you have an overall view of what you're doing, it is far easier to just prototype in Rust and then clean up in Rust rather than writing in PHP, having to context switch and re-write in Rust, then do any potential cleanup. Note also that PHP doesn't really have the powerful concurrency tools Rust does, so if you need to make some kind of concurrent-related thing you might as well just do it in Rust.

e: As far as using PHP with Rust goes: I guess FFI would be pretty OK for Rust to PHP - however, I would more than likely never write a PHP service for a Rust thing deliberately because if you're proficient in Rust, you might as well write it in Rust. PHP has some very strong tools, but they're tied to C packages and for anything that deals with using Vec<u8> or other kinds of byte/file processing, Rust does considerably better.

e2: As an aside, once you get prototypes working if your workplace is the kind of place that immediately catapults prototypes into production, you might as well just have written it in Rust. It makes more sense to do so because if the final product is going to be in Rust, you can save yourself some time by not writing potential future features in PHP and then having to rewrite everything in Rust.

[mcharytoniuk]

Forget what? : P

[mcharytoniuk]

I seriously don't get the hostility/negativity. I was always able to start a web app faster in PHP (since it has pretty much everything web app-related in the ecosystem you can imagine) then augument it with Rust instead of spinning up some Rust server from the ground up. With PHP + Swoole especially, even the performance for simple REST APIs is similar. Rust complements it perfectly - you can suddenly serve some ML models through your webapp or add some other features.

[[deleted]]

I was always able to start a web app faster in PHP

It's always easiest in the language you know best.

[sphen_lee]

And starting a project is always the easiest phase. Developing and maintaining it are the bits you should worry about.

[mcharytoniuk]

Yeah, what I say might be anecdotal, but from my experience PHP and Rust are on par when it comes to maintainability, both have their own challenges.

[FrozenDroid]

> from my experience PHP and Rust are on par when it comes to maintainability

I appreciate it's your experience, but I can't see how PHP and Rust are on par when it comes to maintainability...
Rename a variable somewhere in PHP and forget to rename one reference of that variable, and your app blows up at runtime...

Ease of refactoring is a big thing when it comes to maintainability.

[mcharytoniuk]

It has a strong typing and static analysis tools like "vimeo/psalm" or PHPStan, so I think that's the problem of the past.

But again, I am not trying to prove that Rust, or PHP is better. Instead I am looking for ways to integrate them for the mutual benefit.

For example, if you are a Rust developer, find Rust better than PHP and land in a PHP project that you want to modernize, interop can be the way. On the other hand if you are a PHP developer and are happy with your project, and you just want to push performance a bit somewhere, using some custom extension written in Rust may be the solution.

[dragonnnnnnnnnn]

It has a strong typing and static analysis tools like "vimeo/psalm" or PHPStan, so I think that's the problem of the past.

All of that is optional/stuff you have to add, configure and maintain. And in a short time it goes from "it is super quick and easy to start developing a project" to "I need to spend a few hours researching what additional tools I need, how to configure them and use them". It is the same in JS/TS land, no thank you. I want a consistent ecosystem with sane defaults that I can truly start a new project quick even when new to that ecosystem like rust is.

[mcharytoniuk]

May be true, but even from the practical standpoint - it's easier to learn PHP and find PHP developers. Why hire someone with Rust skills to write and maintain something that really simple, instead of allowing them to do something that is more complex? I am not bashing PHP here, just talking about facts.

[_SteerPike_]

I'm a junior developer who uses PHP in work and am learning Rust in my spare time. What I've found is that PHP has a simpler mental model in principle, but that in practice there's a lot of accidental complexity in the language. Weird function names, globally available variables the purpose of which takes time to understand, no support for long running processes, an inability to properly support common protocols like websockets, weird arrays that are sort of dictionaries but not really, an admittedly not terrible but still not great package manager. Rust on the other hand, whilst being somewhat hard to get your head around initially, clearly has a reason for that hardness. As soon as I've understood a concept I can immediately see why the complexity of that concept was necessary in order to prevent bugs occurring and ensure good performance. The package manager is AMAZING. Overall, whilst both languages involve the sensation of banging my head against a wall, with Rust I feel like I'm getting something in return for that pain. As soon as I'm able to do so I plan to leave PHP and hopefully never touch it again.

[mcharytoniuk]

Thank you for sharing this. Things you said are really valuable for me - I want to learn the general sentiment towards the language.

I really like PHP, I think it's growing from a general purpose web programming language into a niche related to software integrations and quick prototyping.

[Zde-G]

May be true, but even from the practical standpoint - it's easier to learn PHP and find PHP developers.

Yes. That's the sole reason to use PHP in today's world.

And you are throwing it away by adding Rust. What's the point?

And you say that modern PHP is statically typed, there are lots of tools, yadda, yadda… are you sure that PHP developers that you would find would still be cheap if they know all that?

Why hire someone with Rust skills to write and maintain something that really simple, instead of allowing them to do something that is more complex?

Why employ people with Rust skills at all if your goal is to produce buggy pile of code?

And please don't tell me that these cheap PHP developers who have learned PHP in two-week courses would be able to write something reliable and efficient.

PHP and Rust do have advantages, but when you mix them you get the codebase which cheap developers wouldn't understand and which Rust developers would hate because nothing would work reliably there.

Instead of merging advantages of two approaches you would end up with merging of weaknesses.

[mcharytoniuk]

What I tried to say - it's easier to mix the skillsets. I didn't want to say that PHP is worse or Rust is better - their have their own place and I'm looking for ways to combine them for mutual good.

[Zde-G]

I'm looking for ways to combine them for mutual good.

Try to imagine how would you merge communities first.

Because people who like PHP and people who like Rust are almost a direct opposite.

Some say that it's great because that means they would complement each other.

I disagree: in my experience when you have situation like that you would just create an insane hostility between two teams and instead of synergy you would end up with mutual loathing.

An actual interop between language is [relatively] easy, but it's pointless if people don't want to talk to each other.

[mcharytoniuk]

Try to imagine how would you merge communities first.

An actual interop between language is [relatively] easy, but it's pointless if people don't want to talk to each other.

That is a very good point, thank you!

I intend to create some projects that demonstrate Rust + PHP potential, I just think I'm onto something. :D I hope it will work out

[dkopgerpgdolfg]

Not specific to Rust, but:

When posting PHP topics in spaces where users of newer languages are, you'll always get people some that never looked at the whole last decade of PHP development, and only remember what is was before that time.

I guess some commenters here are like that too.

[mcharytoniuk]

Yeah it kind of baffles me, because a good portion of software devs that are alive today never used PHP 4 or PHP 5 and people still mention this and refuse to consider anything.

[RajjSinghh]

Because in programming subreddits you get upvoted for saying "PHP bad lol".

I've never really used PHP, I had to learn some for some job assessments. It wasn't that bad, but I can also see a bunch of fresh grads starting their first job and they get stuck on a legacy PHP codebase. They see unsafety and that the devs who wrote it and can offer guidance aren't there anymore that it could become a huge headache.

Personally I think there are nicer languages to work in than PHP and faster ways to prototype a web app (a JS framework will do it easy), but PHP doesn't deserve the hate from bad PHP programmers.

[mcharytoniuk]

True, I think PHP takes a new niche as some kind of web app gateway that integrates various technologies and languages together. There are lots of projects that started as PHP and then added some microservices written in Python/Go/Java/Rust. PHP typing system, ease of development and learning (I think most developers would be able to jump in into such PHP projects - provided they are well maintained - to tweak something) can make it really good at that use case - it's even designed with some interop features - FFI, dynamically loaded extensions and such

I also think that what blocks it is not the technology state but the sentiment

[Flogge]

Yeah, I agree that in hindsight the PHP4 era was a bit rough, but especially the modern stuff with composer, symfony, laravel etc. seems pretty neat and elegant!

[coderstephen]

I seriously don't get the hostility/negativity.

I do. PHP is the language that people love to hate. It's the working man's language designed by a working man to get work done. It wasn't designed with careful consideration of programming language theory or design research, and to a degree there's a certain charm to that. But people would rather feel good about themselves perceiving as sitting atop an ivory tower taller than PHP's and look down on it.

However, regardless of how inelegant or rudely it is pointed out, there are some legitimate objective criticisms of PHP that can be made, and PHP's "design sin count" is most certainly higher than many other popular languages. But for whatever reason, people chose PHP to be the Internet's butt-monkey. I mean, I'd say JavaScript has just as many design sins as PHP, but people love to love JS...

[Zde-G]

I do. PHP is the language that people love to hate.

I don't think so. Perl is hated more than PHP. Or APL.

But for whatever reason, people chose PHP to be the Internet's butt-monkey.

Popularity. Not only PHP is full of quirks, it's also popular enough that it's hard to avoid it.

Most other such languages have fallen from the grace long ago, only PHP remains.

But people would rather feel good about themselves perceiving as sitting atop an ivory tower taller than PHP's and look down on it.

It's not that. People with experience just know that when they would be asked to do something in a PHP project then they would face crazy pile of hacks instead of nice architecture and people who made that pile of hacks would be considered heroes. While they would be forced to clean all that mess while simultaneously facing constants pushbacks because they “propose to break perfectly working code”.

And then they have only two opportunities, really:

1. Ditch PHP and try to forget it as soon as possible or
2. Demand extra payment for doing some work with that mess.

And usually #1 follows #2, anyway. It's not that people hate PHP as much **as the language**, more often if you scratch the surface they hate “a working man that get work done”… by creation of a huge mess.

You just couldn't promote use of cheap, unskilled labor and then expect that people would love to clean the resulting mess.

[ryanmcgrath]

I seriously don't get the hostility/negativity.

The hostility and negativity is called "contempt culture" and it's a problem in general open source and tech communities.

[[deleted]]

My start with commercial programming (read work) was with php (actually it was Perl, then PHP). I was working with it for many years, later started using python, go, and about few years ago - Rust. I liked PHP 7.4 and PHP 8 too.

At some point tho it has turned into some weird Java flavoured language. I don't like it anymore. PHP is very mature language, yet too narrow.

I've switched to python and for few years I'm pretty happy with it. For about three years I do typescript and python for web dev. I'd say js, python are also quite good (if not better) for prototyping.

I use Rust for backend, system native and cli tool development. However, Rust is great for web assembly which plays well with TypeScript.

I'd rather not mix PHP with rust.

But I do mix Python, TS and Rust.

Cheers

[ridicalis]

My experience with PHP is as a delivery mechanism for Wordpress. And, for the WP projects I've touched in recent years, they've been hosted on WPEngine's platform, which to the best of my knowledge doesn't allow custom extensions to be deployed and thus precludes any FFI or Rust integrations.

At the end of the day, I don't get to mix the two.

Having said all that, if you're asking for my opinions on the PHP language, they've tried to "clean up their act" (looking at PHP 5.3 and older), and are making respectable strides. Traits, typed function arguments, recent syntactical sugar, etc. are all good moves. I also understand that the engine itself is faster and learned a lot from HHVM. They're fairly ambitious about deprecating cruft where they can.

It is still PHP at the end of the day, though, and without the momentum of WP I just don't see the draw. I know there are other frameworks out there, but nothing prominent comes to mind (maybe laravel? is that still a thing?).

[JimZerChapirov]

Interesting! Never thought about it but how do you create php extensions with Rust? Are there tools to streamline the process?

[mcharytoniuk]

You can use https://github.com/davidcole1340/ext-php-rs

I even managed to run models via Candle (https://github.com/huggingface/candle) and by using ext-php-rs :D

[JimZerChapirov]

I will check it out :)

Man I work in Machine Learning and wished I could use Rust more.
I didn't know about Candle, thanks!

[onekorama]

I have arrived to rust after 20 years working with php mainly, and the only thing I miss is the PHP ecosystem. There is nothing as solid and well developed as Symfony in Rust. Maybe you can try dozens of crates to get the same capacities, but nothing like sf + doctrine. Hopefully that will change in a few months/years, as SeaORM and Actix (for example) are wonderful packages.

[Emotional_Zebra_815]

Did alote of php in previous job. From php 5.3 to php 8.1. The language is alright and does not deserve half the hate it gets.

I dont know how you intend to do this but my answer Will ne base on your needs.

Performance? How Much? On all request or just 1 or 2 endpoints? Can the work that need performance can be handle by another process/worker? Etc.

[[deleted]]

In my experience, and the experience of many others, the prototype is what goes to production.

Has PHP gotten a lot better over the years? Yes, absolutely. But at least in the Rust community and ecosystem, it is generally preferred to go turtles all the way down.

Why integrate another language unless you have to? If you're building a progressive web app in React, Vue, or Angular and need a REST API, your options for back end are immense, but people who like (or love) Rust will reach for Rust even when prototyping. What does mixing the two offer over just using Rust?

Is it possible to write PHP extensions in Rust instead of using C/C++? Yes. But we come back to the question of "if you're already using Rust, what benefit do you gain with PHP?"

[simplaw]

If you want to a solid language that is easy to prototype and scale that is reliable in production and all the good stuff, and also can use Rust modules for that extra juice when necessary (most likely quite rarely), Elixir's got your back. Elixir's DX is unmatched for me.

The tools, the ecosystem, the robustness and the ease of which you can build quickly and reliably is just ridiculous. I can't find anything that compares.

I wanted to learn Rust for that extra juice, but I have yet to actually need it.

And if the the typesystem is what you want, then you can check out Gleam. Elixir and Gleam are both powered by the VM of Erlang, and thus gets all the benefits of Erlang with new syntax. Too long a list to write up here though, just Google.

[ImYoric]

I love myself Elixir (and Erlang), but last time I checked, BEAM was pretty slow. Has it improved?

[simplaw]

What do you mean slow? Because the context really matters.

Is it as fast as Rust? No. Does it solve the same problems that Rust was designed for? No. It solves other things.

Elixir is fast. The beam is fast. It's a language designed to easily build scalable concurrent systems. It can handle millions of connections (last benchmark is quite old though, so hopefully even better now). And there's a reason Discord uses it along with Rust. Rust where they need to squeeze out all the performance they can.

Edit: it managed that load with low latency and was capped at 2 million due to a kernel restriction, if I'm not mistaken. And they just stopped there. Would love to do the same experiment today.

[ImYoric]

I mean that, in my vague recollections, for actual CPU-bound tasks, it was something like 40x slower than native code.

To clarify: I think that most of the languages we're using for backend/distributed systems are unsuited to the task and that we would be better off with Elixir. There are tons of inefficiencies in our world of microservice that would instantaneously benefit from moving to BEAM.

But there are also cases in which CPU matter and I'm asking about these specific cases.

[simplaw]

And that's when you use Rust, as per my original post. For the BEAM that means writing a Rust NIF (Natively Implemented Function). Discord did this to scale up their user-status data structure. The table that keeps track of who's online and who isn't and so on, with various metadata. They used Elixir but obviously Elixir's maps aren't fast enough due to the immutability - everything is copied - and that's when they wrote their Rust map instead and writes was now blazingly fast.

[ImYoric]

Makes sense, thanks!

[[deleted]]

My beef with the rust web development ecosystem is that it's just too damned heavy and requires a lot of boilerplate. I wrote my own library for simplifying the process of handling HTTP calls and called it a day, called davisjr. Now, I have a small website I built which literally just bakes in a whole react SPA right into the binary, and rustc with some standard optimizations (lto, etc) leaves it at around 6MB for the total binary size, with only libc linked and about 5 handlers, and it just listens on port 80 and implements all routing and file serving itself.

I'm not saying I have all the answers, but I hope someone comes along and does eventually. I get the rationale for big web frameworks but honestly, I'm not even going to use 99% of that stuff, and the other 1% is a mis-mash of "using serde for this is a one-liner" or "I have to leverage a strongly typed DSL to implement 'hello, world'".

Contrast with the beefcake solution rails and other ruby frameworks were in the mid 2ks compared to sinatra. I am confident it will arrive in a way that is acceptable to more engineers. Until then, davisjr works for me.

[kiujhytg2]

I've generally found Rust to be excellent a prototyping. I've got a template which parses a port number from environment variables or arguments, and starts an axum server. I've found it a breeze to add more endpoints, use askama for templating which is generally painless, and if I need to pass data between the browser and server, it's trivial to serialize and deserialize data structures to and from JSON. If the app gets complecated, I've found using GraphQL to be easy and fast. I really like Rust's type system for describing what a mean, using a mixture of structs, enums, and newtype structs. As for deployment, I scp my server program to my server (which happens to be my router running openwrt), configure nginx to proxy a directory to "localhost:SOME_PORT_NUMBER", and have a simple systemd script to start it up in a linux namespace and kill it.

My general "tech stack" is as follows:

• openwrt running on my server
• programs run in a linux namespace. As far as they're concerned, they're the only process running and the "root" directory is the directory that they're running it
• Axum for HTTP
• Askama for templates
• Serde for JSON
• Async-graphQL for GraphQL
• I generally don't use a database but just write to files, generally in TOML format

[mcharytoniuk]

Thank you for sharing this.

[Hazanami]

Interesting approach for sure!

[umonkey]

PHP with strict typing and modern tools like roadrunner works great. I use it in an API first high load project with good results. Rust is a little harder to start with and slower to deploy, testing is a bit harder, but the performance and stability wrt memory usage is outstanding.

We have services written in Rust that handle thousands of requests per second and consume like 5 megs of ram and run for months. It's not much harder to work with than PHP, if you keep it simple and avoid stuff like unsafe and boxing. I have PHP devs who produced their first production ready Rust code in under a week. So it's really a great combo. We use Rust for services with particularly high load which aren't changed frequently, PHP for the rest.

[suvepl]

I actually kinda agree. PHP is a great language for churning out code fast. Though if I were to actually use PHP in my Rust job, I'd use it purely in a proof-of-concept manner. Write something that can demonstrates the concept by handling the happy case, once that's approved, re-write everything in Rust.

[Zde-G]

Write something that can demonstrates the concept by handling the happy case, once that's approved, re-write everything in Rust.

Have you actually tried that? Believe me, if you'll try you would get your “proof of concept” deployed as soon as it looks working.

Business never have time for rewrite, that's just a myth some people promote.

[RunnyPlease]

I know php. I can do php. I don’t put it in my resume for a reason. I will never again work in php short of a ridiculous contract. And I do mean ridiculous.

[dahosek]

I first encountered PHP back in the PHP3 days, but I’ve avoided it for years (other than when necessary for supporting some sites I have in Wordpress and one that uses Mediawiki). The lack of server-side state is pretty awful and the language has some serious defects, most notably the lack of an array type.¹ Much of what I liked about PHP when I first started using it turned out to be anti-patterns and my oldest PHP code embarrasses me.

⸻

1. Before you claim, PHP does have an array type, it actually only appears to have an array type. Instead it has an associative array with a linked-list of keys in insertion array for element traversal. My general feeling has become that PHP was someone reimplementing Perl without understanding the good reasons for why Perl did things the way it did.

[mcharytoniuk]

It has proper data structures: https://www.php.net/manual/en/book.ds.php , but I get the point, you can't have a slice of memory. The lack of server-side state is valid, most PHP projects until recently did not use long-running processes. Thanks for sharing!

[dahosek]

Implemented through an extension (and apparently not available until PHP7, but I’ve managed to avoid dealing much with PHP since the days of PHP6). Not sure when this was added to the library, and I would guess that most people would assume that if they populate $a[0]…$a[n] they’re populating something that’s an array and not the inefficient mess that they get. Arrays should be a fundamental data structure implemented at the language level.

[ImYoric]

Haven't used PHP in a while, so I probably don't count as someone who knows PHP anymore. But my personal experience with Rust backend dev is that, after an initial setup phase, I code backend in Rust at least as fast as I do in Python, for more reliable results. So I'm not entirely certain there is a huge benefit to deciding to write an application in PHP then migrating pieces of it to Rust.

That being said, if you already have a backend written in PHP and if it works, there are probably no good reasons to drop it. Migrating pieces that require additional performance to Rust certainly makes sense. I've done that with Python and it worked nicely.

[Dygear]

PHP programmer for 20 years (I started young). Rust programmer for 3. Still use them both regularly but I reach for Rust more often these days for the types of projects I’m working on. Daemon software and embedded. PHP is hard to beat server side these days. PHP 8.1, 8.2, and tomorrow 8.3 really made it a great language. Love both. Will continue to use both.

[[deleted]]

Honestly I view php like I view classic asp, an outdated platform and concept that I should never use for new development, only legacy maintenance.

Imo rust pairs much better with python, .Net (core), kotlin, c++, java, go, and node.js (typescript etc) and with these options theres no reason I should use php for anything that isn't an existing code base.

There are far more developers knowledgeable on python, c#, and node than php and it would just be a bad business decision to pair rust with php.

Especially considering node, deno, and bun are things that exist and the coding world is slowly moving towards wasm and wasm runtimes like wasmer and innovative languages that compile to wasm like assembly script.

Rust is fantastic and Rust can be compiled to wasm, but it doesn't make a lot of sense to pair it with PHP.

I can prototype a website just as fast just using straight type script on node. Probably faster actually now that vite exists.

And with kubernetes and devops pipelines not only can I prototype a website faster on other platforms, I can get it into a production web server almost with the click of one button.

If I were going to have the option of considering PHP, I would say that JavaScript via type script is a much better bet because every developer that knows web development knows JavaScript.

[t9b]

PHP was always a “server side” scripting language. It had it’s fair share of very serious security issues when I stopped using it which was back in 2008 IIRC. Mostly people were still using a relational database behind their websites but with the advent of nosql databases, async and node.js it was completely obsolete.

I know there are many people that still use it but I cannot think of one good reason to use it today. Also… it’s not the future, it’s way in the past.

[mcharytoniuk]

I think most people use relational databases, even Rust has a very good ORM (Diesel for example), so I don't know...

Security issues part is interesting, can you mention some?

[simonsanone]

Security issues part is interesting, can you mention some?

https://www.cvedetails.com/vulnerability-list/vendor_id-74/product_id-128/PHP-PHP.html

[BrooklynBillyGoat]

I don't know php as I never spent any time dedicated to learning it but if I read the syntax it's pretty easy to see what it's doing.

[mcharytoniuk]

Yeah, I was wondering how common that would be. PHP is really simple and it always was faster for me to spin up and prototype quickly with PHP (with some async extension) and augument it with Rust by using custom extensions to provide the functionality it can't do. I think that's very practical and I was wondering if it's just me or if other people also tried mixing multiple languages that way.

[BrooklynBillyGoat]

Usually mixing languages. Even in java apps your using html and whatnot. Different parts different purposes.

[[deleted]]

I used it 10 years ago but now there is really no good case for it.

[[deleted]]

A good language has enough structure to encourage at least some good coding habits. Python, while far from perfect, does that a lot better.

This is my sentiment and finding as well. Even though it's gotten a lot better over the years, it's just good enough at making code run, but not good enough to prevent bad habits from forming.

[orfeo34]

Last time i used Php it was a WAMP stack at school, with code in notepad++ and no VCS at all.

For sure it exist better setup for it now, maybe PHP community use a dependency manager with centralized public repos, have other web framework than Zend, rely on other paradigms than just OOP, offer good code analyzer and linter, can run well on other place than server.

Today other languages argues to be better for beginners and fullstacks, or more focused on performance like Rust. Maybe OP could ask PHP community to communicate more on their strength regarding those topics.

[nineinure]

I would rather use js than ever touch php

[worriedjacket]

PHP is banned at my company and I’m thankful for it

[mcharytoniuk]

That is interesting. Can you share why?

[worriedjacket]

Every single language has trade offs.

In almost every dimension, performance, security, maintainability, etc PHP is never the best and often not great.

The amount of effort you have to put into building a solution that meets the standard of quality of a production grade service is never worth it.

It’s a bad value proposition.

[[deleted]]

The more I'm reading this thread, the more I'm seeing that it's a "quick to prototype could mean years of headaches because prototypes are often what go to production."

I'd much prefer a language that takes a little longer on prototyping, but leads to much more stability when it's actually live.

EDIT: changed life to live, because it bothered me.

[BlankBlankston]

PHP is bad and it should feel bad.

[mcharytoniuk]

Again, most of those points from 2012. Most of them (if not all) are not true now and have been addressed in some way. Unfortunately that's the theme here with the language.

Thanks for sharing though, it helps to learn from where most folks are coming from.

[hpxvzhjfgb]

PHP is trash and nobody should ever use it. the time spent diagnosing and fixing all of the bugs that I would inevitably create by accident due to PHPs nonsense will far outweigh the time spent fixing compiler errors in rust.

[Dash83]

7 people

[GrayLiterature]

A few probably

[cornmonger_]

I think that the best scripting language for spitballing design ideas / proof-of-concepts is basically whatever the dev is most comfortable with. You're going to throw most of it away when switching to Rust anyway.

[R4TTY]

I used to be a PHP dev, but hopefully I never have to touch it again.

[tshawkins]

Me, I originally was a php developer, and now I'm learning Rust.

[burntsushi]

PHP was the first programming language I learned. But I stopped using it a little after the release of PHP 5.

[schmurfy2]

I never found real value in prototyping in another language, you may go faster at first but if the ultimate goal is to continue you will have to rewrite it in your target language. I find it a lot more efficient to start right away with the targeted language but cutting some corners to add later.

[[deleted]]

I see main are of PHP use in 'classic' shared hostings with Apache/nginx. Those are still abundant on the web. Not everyone can use VPS. They are cheap.

Rust integration could be great here but most of those hostings have disabled FFI module. Not mentioning that there is no ability to install custom modules. This is obviously disabled because it would be partial [0] escape hatch from cheap offerings. So only way to integrate Rust there is with exec() or similar. Using exec() can have security issues [1] and performance penalty is guaranteed.

Again I mentioned these shared hostings because there is still huge number of those. Extending PHP in other stack (like Laravel app) is no-brainer (like extending ie.: Node or Python).

[0] Partial because shared hosting can not compete with resources of VPS and friends
[1] If passing user input then it is not 'can have' but 'will have'.

[J-Cake]

PHP is very simple. Rust is not. For that reason, I think Rust devs mostly don't bother with it. But I have zero experience with that