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.
Moving from Go to PHP Again
251–260 of 371 posts
Re: Moving from Go to PHP Again
#252Each 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…
Re: Moving from Go to PHP Again
#253Earlier 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.
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
#254Each 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…
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
#255Well 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…
Re: Moving from Go to PHP Again
#256Each 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.”
Re: Moving from Go to PHP Again
#257Earlier 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…
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
#258Earlier 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.
Re: Moving from Go to PHP Again
#259I 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.
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
#260Earlier 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).