Live data from Hacker News

Moving from Go to PHP Again

dannyvankooten.com

251–260 of 371 posts

Re: Moving from Go to PHP Again

#251

Earlier quoted context omitted.

> for many Go is the only compiled language they ever used That, or it can be read as "in the family of web-friendly languages". The only other "fast" language widely used for the web is Java.

And java is a memory hog quite painful to deploy and tune.

Yes, launching a new server/executable in java is a PITA dur to the JVM warmup (at least it was a few years ago, don't know whether they improved that point or not).

Re: Moving from Go to PHP Again

#252
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…

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…

Apache is a robust piece of software, capable of more than the vast majority of users ever suspect.

Re: Moving from Go to PHP Again

#253
post #229

Earlier quoted context omitted.

You conveniently leave out all the security mess of that design, especially WordPress. The plugin system is pretty much the cause of all the security issues in WordPress. Perhaps end-users should not have the capacity to so easily add third party PHP code, even if it’s “simple.”

Wordpress is written in PHP. Wordpress is not PHP.

Did I say that? Please don't twist my words. I was responding to the OP who was talking about the WordPress plugin system, which allows just about anyone to add third-party PHP code into the system. And those plugins have access to everything in the WordPress stack (and the file system for that user).

And I think you can definitely argue that a low barrier to entry means that it gives beginners a lot of power they don't quite understand.

Which is why I think most people steer towards common web frameworks, because not many people can know all the ways you can create security issues.

Then you get into the complexities of various common web frameworks (Zend, etc) and you have to really wonder if the original OPs argument about simplicity and ease-of-use are worth that trade-off from using something else.

Re: Moving from Go to PHP Again

#254
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…

> Can extend itself as it runs. For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?)

Since it's basically just doing eval(loadFile(...)), any language with eval() can do this, for better or worse. Which is like most of them. Perl, Python, Ruby, and Lua, to name the most common.

Re: Moving from Go to PHP Again

#255

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.

Re: Moving from Go to PHP Again

#256
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…

You conveniently leave out all the security mess of that design, especially WordPress. The plugin system is pretty much the cause of all the security issues in WordPress. Perhaps end-users should not have the capacity to so easily add third party PHP code, even if it’s “simple.”

[deleted]

Re: Moving from Go to PHP Again

#257
post #94

Earlier quoted context omitted.

Of course. That's the only reason to invent languages: to take care of stuff people are not good taking care of, and move the work to the computer, allowing us to work on the level that we're good at taking care of. Else we'd all be using assembly. There's absolutely no pride or glory in doing things nicely and securely that the computer could have automated in the first place. Anything the language allows that it co…

Incompetent people will create incompetent things regardless of the tool. Simpler tools lead to simpler messes while complicated tools lead to complicated messes. I've seen an attitude that people think they can inoculate themselves from inept programming by using obtuse frameworks as if martin-fowler-speak acts as a drill sergeant making disciplined coders out of the herd. But after 20 years of bouncing around start…

Incompetent people will create incompetent things regardless of the tool

It's not binary. It's probabilities. Some environments make it harder to mess up, others make it easier. This is real.

Re: Moving from Go to PHP Again

#258
post #145

Earlier quoted context omitted.

React can't execute arbitrary database queries.

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.

Re: Moving from Go to PHP Again

#259
post #98

I love Go, for many situations, but definitely not for a typical user facing website. The community seems bent on the whole "all you need is net/http", but that just isn't practical in modern web development. People like ORMs, easy to handle html forms, security as a default, easy session/cookie handling etc. In the end, web developers want ease of life. Go is a great language for many things, but if it's going to ta…

This is so true. I love go so much, because deployment is so easy, but using it for end-user web content is a real PITA.

What makes it a PITA?

I use go for building websites and it was the first time web development really made any sense. All the other systems out there require tons of tools, and lock you into doing things their way.

So, what makes GO so much of a pain? Maybe ignorance is bliss for me?

Re: Moving from Go to PHP Again

#260

Earlier quoted context omitted.

And java is a memory hog quite painful to deploy and tune.

Yes, launching a new server/executable in java is a PITA dur to the JVM warmup (at least it was a few years ago, don't know whether they improved that point or not).

Only for those that don't use a JVM with either AOT compilation or JIT caching.
Post reply on HN