Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving from Go to PHP Again

dannyvankooten.com

Post reply on HN
Print view View original

291–300 of 371 posts

Re: Moving from Go to PHP Again

#291

Post by exceptione »

013a wrote: post #289

Go really just isn't designed for the same kind of service that PHP is normally used for. Its best at small API services (and, tangentially, its also pretty great at CLI tools). > They were a little surprised to hear our stack involved Golang and some flat out told us they’d prefer PHP, because that’s what most of our products rely upon. I believe this is the real reason why, and everything else above it is pointless…

You are comparing frameworks with a language here.

I think that if they choose to use a high-quality, modern php framework like Symfony, the technical decision would still make sense in the context of the alternatives you mentioned.

Re: Moving from Go to PHP Again

#292

Post by chiefalchemist »

52-6F-62 wrote: post #278
trixie_ wrote: post #64

Earlier quoted context omitted.

You can create a mess of code, open security holes, and/or be hit with ‘gotchas’ in any web framework. PHP is much less complex than most.

Eh, maybe for something simple. In a complex product (as in, most professional settings or large services/web sites) the PHP I've seen is grossly complex, and not intuitive— especially WordPress deployments. Dev teams have to perform all kinds of gymnastics with the PHP code to get it to do what they want, and it's just a flat out nightmare that I've made sure my boss and colleagues know that I have no desire to work…

> "...especially WordPress deployments."

I've done enough WP to certainly agree with you. However, I don't think it's fair to judge PHP by how WP has abused it.

WP problem is its desire to sacrifice code quality and best practices for market share. That is, many things don't get refactored (into something OOP based) because there might be backwards compatibility issues. Again, this isn't PHP's fault.

Re: Moving from Go to PHP Again

#293

Post by mixedCase »

nprateem wrote: post #258
Aeolun wrote: post #145

Earlier quoted context omitted.

I’m sure you can use the all JS mysql client to connect directly from your client app to your database.

Well yes if you're stupid enough to directly expose your DB to the world then it's technically possible, but barring such idiocy there's arguably more risk of a DB hack through PHP than client side JS in most architectures.

React can do SSR. You can use JSX on the backend for rendering pages just like on PHP.

Re: Moving from Go to PHP Again

#294

Post by 52-6F-62 »

chiefalchemist wrote: post #292
52-6F-62 wrote: post #278

Earlier quoted context omitted.

Eh, maybe for something simple. In a complex product (as in, most professional settings or large services/web sites) the PHP I've seen is grossly complex, and not intuitive— especially WordPress deployments. Dev teams have to perform all kinds of gymnastics with the PHP code to get it to do what they want, and it's just a flat out nightmare that I've made sure my boss and colleagues know that I have no desire to work…

> "...especially WordPress deployments." I've done enough WP to certainly agree with you. However, I don't think it's fair to judge PHP by how WP has abused it. WP problem is its desire to sacrifice code quality and best practices for market share. That is, many things don't get refactored (into something OOP based) because there might be backwards compatibility issues. Again, this isn't PHP's fault.

I'm not all out against PHP. I've used, and still do, on occasion for simple things and prototyping.

That said, I'll never go out of my way to use it for much else—let alone serving and routing something public-facing ever again.

Re: Moving from Go to PHP Again

#295

Post by crimsonalucard »

I'm finding that although golang offers type safety it introduces a new kind of error class to applications typically not encountered in web apps of the python/php/ruby/node class.

Deadlocks and race conditions.

For node, the entire app is a single thread so this just doesn't happen. For python/php/ruby concurrency is abstracted away and handled above the framework layer so the programmer never has to deal with it. You can launch threads in a route handler for these languages but it's not often done and you have nothing like a context object that is basically this abstraction leak that explicitly forces the programmer to constantly be aware of concurrency issues.

Re: Moving from Go to PHP Again

#296

Post by combatentropy »

sebcat wrote: post #69
combatentropy wrote: post #36

Earlier quoted context omitted.

Apache MultiViews makes pretty URLs easy. www.example.com/widgets.php can be reached at: www.example.com/widgets But here's the kicker: www.examples.com/widgets/123 will also route to widgets.php, with "/123" in the $_SERVER['PATH_INFO']. No mod_rewrite needed. www.example.com/widgets/you/can/have/multi-segment/paths goes to widgets.php too, with its PATH_INFO set to "/you/can/have/multi-segment/paths", but I don't u…

Caveat: there are cases where this behavior has resulted in vulnerabilities. e.g., CVE-2018-10661[1]. So if you ever want to implement your own auth module in apache httpd you should be aware of this. [1] https://www.vdoo.com/blog/vdoo-discovers-significant-vulnera...

If I'm reading this right, this is something that sounds a little bit like Apache MultiViews but isn't.

1. It doesn't sound like they were using MultiViews at all but some rewrite rule that rerouted all requests ending in .srv to a shell script in /bin. This isn't how MultiViews works. The file must exist, and it must be in the document root. A request to /foo won't work unless /foo.php (or foo.html, etc.) exists.

2. This rerouting was supposed to happen only for admins, but the authorization failed, due to a different bug, CVE-2018-10661.

3. The attack then depended on a bug in dbus, CVE-2018-10662

4. Finally it depended on a third flaw, CVE-2018-10660, having to do with shell-script injection.

So I don't think any of this should scare away a person from using MultiViews for .php scripts, which makes setting up clean, maintainable routes easier than any other technique I've seen.

Re: Moving from Go to PHP Again

#297

Post by stcredzero »

trixie_ wrote: post #13

Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. PHP files can be deployed independently, swapped out or updated live. No building/compiling of the php files needed. A single layer as opposed to 'modern architecture' where there's client side back/front end layers, api layer, logic, validator, data access, and ORM layers. Can extend itself as it runs. For example Wordpres…

I'm currently developing a facility to do live updating of processes with running game loops in Go. If one were to add in dynamically loadable libraries (working in Linux, last I checked) one could have the same facility for changing a single endpoint in Go. (It could also be implemented with small executables and reverse proxies.)

I think what this demonstrates is that Go isn't a better PHP. Rather, we're at the point where Go could be used to build a better PHP. The most likely paths for this, are to somehow come up with a big group of developers with a penchant for doing this, and/or have some big company fund this.

Re: Moving from Go to PHP Again

#298

Post by sandreas »

waibelp wrote: post #255
sandreas wrote: post #105

Well comparing Go and PHP is kind of difficult, because they are targeting completely different goals. After some years of development, both languages have evolved a lot and they both can be used for many other things, that they haven't been designed for. PHP was a dynamically typed scripting language to build personal homepages (Personal Home Page Tools). Today it is an object oriented, type hinted language that sup…

It's possible to write bad code in every language.

Sure it is... and nearly every language has concepts i like and concepts that i don't like...

The above list is just an indeed subjective list of things i don't like about PHP, although i like PHP in general and it is NOT a PHP rant!

Re: Moving from Go to PHP Again

#299

Post by KerryJones »

52-6F-62 wrote: post #294
chiefalchemist wrote: post #292

Earlier quoted context omitted.

> "...especially WordPress deployments." I've done enough WP to certainly agree with you. However, I don't think it's fair to judge PHP by how WP has abused it. WP problem is its desire to sacrifice code quality and best practices for market share. That is, many things don't get refactored (into something OOP based) because there might be backwards compatibility issues. Again, this isn't PHP's fault.

I'm not all out against PHP. I've used, and still do, on occasion for simple things and prototyping. That said, I'll never go out of my way to use it for much else—let alone serving and routing something public-facing ever again.

Checkout Laravel, it powers some Fortune 100 sites -- it's definitely "large-site" capable.

Re: Moving from Go to PHP Again

#300

Post by KerryJones »

agumonkey wrote: post #180
trixie_ wrote: post #64

Earlier quoted context omitted.

You can create a mess of code, open security holes, and/or be hit with ‘gotchas’ in any web framework. PHP is much less complex than most.

no, seriously, the old dynamic script as program requiring a web server needed to be configured properly to avoid leaks of a thousand faces .. thanks but no thanks I'll be flask-ing

Just use Laravel and its eco-system, it's just as easy or easier to setup than Flask and easily production ready. This is an old-take on PHP and no longer true in 2019.
Post reply on HN